draft-ietf-capwap-protocol-specification-02.txt   draft-ietf-capwap-protocol-specification-03.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: December 23, 2006 M. Montemurro, Editor Intended status: Informational M. Montemurro, Editor
Research In Motion Expires: April 16, 2007 Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
June 21, 2006 October 13, 2006
CAPWAP Protocol Specification CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-02 draft-ietf-capwap-protocol-specification-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2006. This Internet-Draft will expire on April 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized
controller and Wireless Termination Points (WTPs). The general goal
of centralized control architectures is to move access control,
including user authentication and authorization, mobility management
and radio management from the single access point to a centralized
controller.
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF
CAPWAP working group protocol requirements. The CAPWAP protocol is CAPWAP working group protocol requirements. The CAPWAP protocol is
designed to be flexible, allowing it to be used for a variety of designed to be flexible, allowing it to be used for a variety of
wireless technologies. This document describes the base CAPWAP wireless technologies. This document describes the base CAPWAP
protocol, including an extension which supports the IEEE 802.11 protocol. The CAPWAP protocol binding which defines extensions for
wireless LAN protocol. Future extensions will enable support of use with the IEEE 802.11 wireless LAN protocol is available in [11].
additional wireless technologies. Extensions are expected to be defined to enable use of the CAPWAP
protocol with additional wireless technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Conventions used in this document . . . . . . . . . . . 8 1.2. Conventions used in this document . . . . . . . . . . . . 7
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 8
1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 9
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Wireless Binding Definition . . . . . . . . . . . . . . 13 2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 11
2.2. CAPWAP Session Establishment Overview . . . . . . . . . 13 2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 11
2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 15 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 13
2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . 16 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 15
2.3.2. CAPWAP to DTLS Commands . . . . . . . . . . . . . . 23 2.3.2. CAPWAP to DTLS Commands . . . . . . . . . . . . . . . 21
2.3.3. DTLS to CAPWAP Notifications . . . . . . . . . . . . 24 2.3.3. DTLS to CAPWAP Notifications . . . . . . . . . . . . 21
2.3.4. DTLS State Transitions . . . . . . . . . . . . . . . 24 2.3.4. DTLS State Transitions . . . . . . . . . . . . . . . 22
2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 27 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 25
2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . 28 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 26
2.4.2. DTLS Error Handling . . . . . . . . . . . . . . . . 29 2.4.2. DTLS Error Handling . . . . . . . . . . . . . . . . . 27
2.4.3. DTLS Rehandshake Behavior . . . . . . . . . . . . . 30 2.4.3. DTLS Rehandshake Behavior . . . . . . . . . . . . . . 28
2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . . 33 2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . . 31
3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 36 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 34
3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 36 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 34
3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 36 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 34
3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 37 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 35
4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 38 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 36
4.1. CAPWAP Transport Header . . . . . . . . . . . . . . . . 39 4.1. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 37
4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 42 4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 40
4.3. CAPWAP Control Messages . . . . . . . . . . . . . . . . 42 4.3. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 41
4.3.1. Control Message Format . . . . . . . . . . . . . . . 43 4.3.1. Control Message Format . . . . . . . . . . . . . . . 41
4.3.2. Control Message Quality of Service . . . . . . . . . 45 4.3.2. Control Message Quality of Service . . . . . . . . . 44
4.4. CAPWAP Protocol Message Elements . . . . . . . . . . . . 45 4.4. CAPWAP Protocol Message Elements . . . . . . . . . . . . 44
4.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . 48 4.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 47
4.4.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 49 4.4.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 48
4.4.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 50 4.4.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 49
4.4.4. AC Name . . . . . . . . . . . . . . . . . . . . . . 50 4.4.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.5. AC Name with Index . . . . . . . . . . . . . . . . . 50 4.4.5. AC Name with Index . . . . . . . . . . . . . . . . . 50
4.4.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 51 4.4.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 50
4.4.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . 51 4.4.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 50
4.4.8. Add Mobile Station . . . . . . . . . . . . . . . . . 52 4.4.8. Add Station . . . . . . . . . . . . . . . . . . . . . 51
4.4.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 53 4.4.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 52
4.4.10. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 53 4.4.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 52
4.4.11. Data Transfer Data . . . . . . . . . . . . . . . . . 54 4.4.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 53
4.4.12. Data Transfer Mode . . . . . . . . . . . . . . . . . 54 4.4.12. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 54
4.4.13. Decryption Error Report . . . . . . . . . . . . . . 55 4.4.13. Data Transfer Data . . . . . . . . . . . . . . . . . 54
4.4.14. Decryption Error Report Period . . . . . . . . . . . 55 4.4.14. Data Transfer Mode . . . . . . . . . . . . . . . . . 55
4.4.15. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 56 4.4.15. Decryption Error Report . . . . . . . . . . . . . . . 55
4.4.16. Delete Mobile Station . . . . . . . . . . . . . . . 56 4.4.16. Decryption Error Report Period . . . . . . . . . . . 56
4.4.17. Delete Static MAC ACL Entry . . . . . . . . . . . . 57 4.4.17. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 56
4.4.18. Discovery Type . . . . . . . . . . . . . . . . . . . 57 4.4.18. Delete Station . . . . . . . . . . . . . . . . . . . 57
4.4.19. Duplicate IPv4 Address . . . . . . . . . . . . . . . 58 4.4.19. Delete Static MAC ACL Entry . . . . . . . . . . . . . 57
4.4.20. Duplicate IPv6 Address . . . . . . . . . . . . . . . 59 4.4.20. Discovery Type . . . . . . . . . . . . . . . . . . . 58
4.4.21. Idle Timeout . . . . . . . . . . . . . . . . . . . . 59 4.4.21. Duplicate IPv4 Address . . . . . . . . . . . . . . . 58
4.4.22. Image Data . . . . . . . . . . . . . . . . . . . . . 60 4.4.22. Duplicate IPv6 Address . . . . . . . . . . . . . . . 59
4.4.23. Image Filename . . . . . . . . . . . . . . . . . . . 60 4.4.23. Idle Timeout . . . . . . . . . . . . . . . . . . . . 60
4.4.24. Initiate Download . . . . . . . . . . . . . . . . . 61 4.4.24. Image Data . . . . . . . . . . . . . . . . . . . . . 60
4.4.25. Location Data . . . . . . . . . . . . . . . . . . . 61 4.4.25. Image Filename . . . . . . . . . . . . . . . . . . . 61
4.4.26. MTU Discovery Padding . . . . . . . . . . . . . . . 62 4.4.26. Initiate Download . . . . . . . . . . . . . . . . . . 61
4.4.27. Radio Administrative State . . . . . . . . . . . . . 62 4.4.27. Location Data . . . . . . . . . . . . . . . . . . . . 62
4.4.28. Result Code . . . . . . . . . . . . . . . . . . . . 63 4.4.28. MTU Discovery Padding . . . . . . . . . . . . . . . . 62
4.4.29. Session ID . . . . . . . . . . . . . . . . . . . . . 64 4.4.29. Radio Administrative State . . . . . . . . . . . . . 62
4.4.30. Statistics Timer . . . . . . . . . . . . . . . . . . 64 4.4.30. Radio Operational State . . . . . . . . . . . . . . . 63
4.4.31. Vendor Specific Payload . . . . . . . . . . . . . . 64 4.4.31. Result Code . . . . . . . . . . . . . . . . . . . . . 64
4.4.32. WTP Board Data . . . . . . . . . . . . . . . . . . . 65 4.4.32. Session ID . . . . . . . . . . . . . . . . . . . . . 65
4.4.33. WTP Descriptor . . . . . . . . . . . . . . . . . . . 66 4.4.33. Statistics Timer . . . . . . . . . . . . . . . . . . 65
4.4.34. WTP Fallback . . . . . . . . . . . . . . . . . . . . 68 4.4.34. Vendor Specific Payload . . . . . . . . . . . . . . . 66
4.4.35. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . 68 4.4.35. WTP Board Data . . . . . . . . . . . . . . . . . . . 66
4.4.36. WTP IPv4 IP Address . . . . . . . . . . . . . . . . 69 4.4.36. WTP Descriptor . . . . . . . . . . . . . . . . . . . 67
4.4.37. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 69 4.4.37. WTP Fallback . . . . . . . . . . . . . . . . . . . . 69
4.4.38. WTP Radio Information . . . . . . . . . . . . . . . 70 4.4.38. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 70
4.4.39. WTP Manager Control IPv4 Address . . . . . . . . . . 71 4.4.39. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 71
4.4.40. WTP Manager Control IPv6 Address . . . . . . . . . . 71 4.4.40. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 71
4.4.41. WTP Name . . . . . . . . . . . . . . . . . . . . . . 72 4.4.41. WTP Name . . . . . . . . . . . . . . . . . . . . . . 72
4.4.42. WTP Operational Statistics . . . . . . . . . . . . . 72 4.4.42. WTP Operational Statistics . . . . . . . . . . . . . 72
4.4.43. WTP Radio Statistics . . . . . . . . . . . . . . . . 73 4.4.43. WTP Radio Statistics . . . . . . . . . . . . . . . . 73
4.4.44. WTP Reboot Statistics . . . . . . . . . . . . . . . 74 4.4.44. WTP Reboot Statistics . . . . . . . . . . . . . . . . 74
4.4.45. WTP Static IP Address Information . . . . . . . . . 76 4.4.45. WTP Static IP Address Information . . . . . . . . . . 75
4.5. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 77 4.5. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 76
4.5.1. DiscoveryInterval . . . . . . . . . . . . . . . . . 77 4.5.1. DiscoveryInterval . . . . . . . . . . . . . . . . . . 76
4.5.2. DTLSRehandshake . . . . . . . . . . . . . . . . . . 77 4.5.2. DTLSRehandshake . . . . . . . . . . . . . . . . . . . 76
4.5.3. DTLSSessionDelete . . . . . . . . . . . . . . . . . 77 4.5.3. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 77
4.5.4. EchoInterval . . . . . . . . . . . . . . . . . . . . 77 4.5.4. EchoInterval . . . . . . . . . . . . . . . . . . . . 77
4.5.5. KeyLifetime . . . . . . . . . . . . . . . . . . . . 77 4.5.5. KeyLifetime . . . . . . . . . . . . . . . . . . . . . 77
4.5.6. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 78 4.5.6. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 77
4.5.7. NeighborDeadInterval . . . . . . . . . . . . . . . . 78 4.5.7. NeighborDeadInterval . . . . . . . . . . . . . . . . 77
4.5.8. ResponseTimeout . . . . . . . . . . . . . . . . . . 78 4.5.8. ResponseTimeout . . . . . . . . . . . . . . . . . . . 77
4.5.9. RetransmitInterval . . . . . . . . . . . . . . . . . 78 4.5.9. RetransmitInterval . . . . . . . . . . . . . . . . . 78
4.5.10. SilentInterval . . . . . . . . . . . . . . . . . . . 78 4.5.10. SilentInterval . . . . . . . . . . . . . . . . . . . 78
4.5.11. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 78 4.5.11. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 78
4.6. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 79 4.6. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 78
4.6.1. DiscoveryCount . . . . . . . . . . . . . . . . . . . 79 4.6.1. AdminState . . . . . . . . . . . . . . . . . . . . . 78
4.6.2. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 79 4.6.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 78
4.6.3. MaxRetransmit . . . . . . . . . . . . . . . . . . . 79 4.6.3. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 78
4.6.4. RetransmitCount . . . . . . . . . . . . . . . . . . 79 4.6.4. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 78
5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 80 4.6.5. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 79
5.1. Discovery Request Message . . . . . . . . . . . . . . . 80 4.6.6. ReportInterval . . . . . . . . . . . . . . . . . . . 79
5.2. Discovery Response Message . . . . . . . . . . . . . . . 81 4.6.7. RetransmitCount . . . . . . . . . . . . . . . . . . . 79
5.3. Primary Discovery Request Message . . . . . . . . . . . 81 4.6.8. StatisticsTimer . . . . . . . . . . . . . . . . . . . 79
5.4. Primary Discovery Response . . . . . . . . . . . . . . . 82 4.6.9. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 79
6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 83 4.7. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 79
6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 83 4.7.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 79
6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 84 4.7.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 79
7. Control Channel Management . . . . . . . . . . . . . . . . . 85 4.7.3. LastRebootReason . . . . . . . . . . . . . . . . . . 79
7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 85 4.7.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 80
7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 85 4.7.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 80
8. WTP Configuration Management . . . . . . . . . . . . . . . . 86 4.7.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 80
8.1. Configuration Consistency . . . . . . . . . . . . . . . 86 4.7.7. Static ACL Table . . . . . . . . . . . . . . . . . . 80
8.1.1. Configuration Flexibility . . . . . . . . . . . . . 87 4.7.8. Static IP Address . . . . . . . . . . . . . . . . . . 80
8.2. Configuration Status . . . . . . . . . . . . . . . . . . 87 4.7.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 80
8.3. Configuration Status Response . . . . . . . . . . . . . 88 4.7.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 80
8.4. Configuration Update Request . . . . . . . . . . . . . . 88 4.7.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 80
8.5. Configuration Update Response . . . . . . . . . . . . . 89 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 81
8.6. Change State Event Request . . . . . . . . . . . . . . . 90 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 81
8.7. Change State Event Response . . . . . . . . . . . . . . 90 5.2. Discovery Response Message . . . . . . . . . . . . . . . 82
8.8. Clear Configuration Request . . . . . . . . . . . . . . 90 5.3. Primary Discovery Request Message . . . . . . . . . . . . 82
8.9. Clear Configuration Response . . . . . . . . . . . . . . 91 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 83
9. Device Management Operations . . . . . . . . . . . . . . . . 92 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 84
9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 92 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 84
9.2. Image Data Response . . . . . . . . . . . . . . . . . . 93 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 84
9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . 93 7. Control Channel Management . . . . . . . . . . . . . . . . . 86
9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 93 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 86
9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . 93 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 86
9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 94 8. WTP Configuration Management . . . . . . . . . . . . . . . . 87
9.7. Data Transfer Request . . . . . . . . . . . . . . . . . 94 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 87
9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 95 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 88
10. Mobile Session Management . . . . . . . . . . . . . . . . . . 96 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 88
10.1. Mobile Configuration Request . . . . . . . . . . . . . . 96 8.3. Configuration Status Response . . . . . . . . . . . . . . 89
10.2. Mobile Configuration Response . . . . . . . . . . . . . 96 8.4. Configuration Update Request . . . . . . . . . . . . . . 89
11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 97 8.5. Configuration Update Response . . . . . . . . . . . . . . 90
11.1. Split MAC and Local MAC Functionality . . . . . . . . . 97 8.6. Change State Event Request . . . . . . . . . . . . . . . 91
11.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . 97 8.7. Change State Event Response . . . . . . . . . . . . . . . 91
11.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . 99 8.8. Clear Configuration Request . . . . . . . . . . . . . . . 91
11.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 102 8.9. Clear Configuration Response . . . . . . . . . . . . . . 92
11.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . 103 9. Device Management Operations . . . . . . . . . . . . . . . . 93
11.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 103 9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 93
11.5. Quality of Service for IEEE 802.11 Control Messages . . 104 9.2. Image Data Response . . . . . . . . . . . . . . . . . . . 94
11.6. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . 104 9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . . 94
11.6.1. IEEE 802.11 WLAN Configuration Request . . . . . . . 104 9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 94
11.6.2. IEEE 802.11 WLAN Configuration Response . . . . . . 105 9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . . 95
11.7. CAPWAP Data Message Bindings . . . . . . . . . . . . . . 106 9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 95
11.8. CAPWAP Control Message bindings . . . . . . . . . . . . 107 9.7. Data Transfer Request . . . . . . . . . . . . . . . . . . 95
11.8.1. Configuration Status Message . . . . . . . . . . . . 107 9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 96
11.8.2. Configuration Status Response Message . . . . . . . 108 10. Station Session Management . . . . . . . . . . . . . . . . . 97
11.8.3. Configuration Update Request Message . . . . . . . . 108 10.1. Station Configuration Request . . . . . . . . . . . . . . 97
11.8.4. Mobile Config Request . . . . . . . . . . . . . . . 109 10.2. Station Configuration Response . . . . . . . . . . . . . 97
11.8.5. WTP Event Request . . . . . . . . . . . . . . . . . 109 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 98
11.9. IEEE 802.11 Message Element Definitions . . . . . . . . 109 12. Security Considerations . . . . . . . . . . . . . . . . . . . 100
11.9.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . 110 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 100
11.9.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 114 12.1.1. Converting Protected Data into Unprotected Data . . . 101
11.9.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . 115 12.1.2. Converting Unprotected Data into Protected Data
11.9.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . 115 (Insertion) . . . . . . . . . . . . . . . . . . . . . 101
11.9.5. IEEE 802.11 Direct Sequence Control . . . . . . . . 116 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 101
11.9.6. IEEE 802.11 Information Element . . . . . . . . . . 117 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 101
11.9.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . 117 12.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 101
11.9.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . 119 12.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 102
11.9.9. IEEE 802.11 Mobile . . . . . . . . . . . . . . . . . 120 12.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 103
11.9.10. IEEE 802.11 Mobile Session Key . . . . . . . . . . . 121 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104
11.9.11. IEEE 802.11 Multi-Domain Capability . . . . . . . . 122 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 105
11.9.12. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 123 14.1. Normative References . . . . . . . . . . . . . . . . . . 105
11.9.13. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 124 14.2. Informational References . . . . . . . . . . . . . . . . 105
11.9.14. IEEE 802.11 RSNA Error Report From Mobile . . . . . 125 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
11.9.15. IEEE 802.11 Station QoS Profile . . . . . . . . . . 126 Intellectual Property and Copyright Statements . . . . . . . . . 107
11.9.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . 127
11.9.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . 130
11.9.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 131
11.9.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 131
11.9.20. IEEE 802.11 Update Mobile QoS . . . . . . . . . . . 132
11.9.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . 133
11.9.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . 134
11.9.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . 136
11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . 137
11.10. Technology Specific Message Element Values . . . . . . . 138
12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 139
13. Security Considerations . . . . . . . . . . . . . . . . . . . 141
13.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 141
13.1.1. Converting Protected Data into Unprotected Data . . 142
13.1.2. Converting Unprotected Data into Protected Data
(Insertion) . . . . . . . . . . . . . . . . . . . . 142
13.1.3. Deletion of Protected Records . . . . . . . . . . . 142
13.1.4. Insertion of Unprotected Records . . . . . . . . . . 142
13.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 142
13.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . 143
13.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 144
13.5. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 144
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 146
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 147
15.1. Normative References . . . . . . . . . . . . . . . . . . 147
15.2. Informational References . . . . . . . . . . . . . . . . 148
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150
Intellectual Property and Copyright Statements . . . . . . . . . 151
1. Introduction 1. Introduction
The emergence of centralized architectures, in which simple IEEE This document describes the CAPWAP Protocol, a standard,
802.11 WTPs are managed by an Access Controller (AC) suggests that a interoperable protocol which enables an Access Controller (AC) to
standards based, interoperable protocol could radically simplify the manage a collection of Wireless Termination Points (WTPs). The
deployment and management of wireless networks. WTPs require a set CAPWAP protocol is defined to be independent of layer 2 technology.
of dynamic management and control functions related to their primary
task of connecting the wireless and wired mediums. Traditional The emergence of centralized IEEE 802.11 Wireless Local Area Network
protocols for managing WTPs are either manual static configuration (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by
via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs an Access Controller (AC) suggested that a standards based,
are self-contained). This document describes the CAPWAP Protocol, a interoperable protocol could radically simplify the deployment and
standard, interoperable protocol which enables an AC to manage a management of wireless networks. WTPs require a set of dynamic
collection of WTPs. While the protocol is defined to be independent management and control functions related to their primary task of
of layer 2 technology, an IEEE 802.11 binding is provided to support connecting the wireless and wired mediums. Traditional protocols for
IEEE 802.11 wireless LAN networks. managing WTPs are either manual static configuration via HTTP,
proprietary Layer 2 specific or non-existent (if the WTPs are self-
contained). An IEEE 802.11 binding is defined in [11] to support use
of the CAPWAP protocol with IEEE 802.11 WLAN networks.
CAPWAP assumes a network configuration consisting of multiple WTPs CAPWAP assumes a network configuration consisting of multiple WTPs
communicating via the Internet Protocol (IP) to an AC. WTPs are communicating via the Internet Protocol (IP) to an AC. WTPs are
viewed as remote RF interfaces controlled by the AC. The CAPWAP viewed as remote RF interfaces controlled by the AC. The CAPWAP
protocol supports two modes of operation: Split and Local MAC. In protocol supports two modes of operation: Split and Local MAC. In
Split MAC mode all L2 wireless data and management frames are Split MAC mode all L2 wireless data and management frames are
encapsulated via the CAPWAP protocol and exchanged between the AC and encapsulated via the CAPWAP protocol and exchanged between the AC and
the WTP. In the example of 802.11, as shown in Figure 1, the 802.11 the WTP. As shown in Figure 1, the wireless frames received from a
frames received from a mobile node (STA) are directly encapsulated by mobile device, which is referred to in this specification as a
the WTP and forwarded to the AC. Station (or STA for short), are directly encapsulated by the WTP and
forwarded to the AC.
+-+ 802.11 frames +-+ +-+ wireless frames +-+
| |--------------------------------| | | |--------------------------------| |
| | +-+ | | | | +-+ | |
| |--------------| |---------------| | | |--------------| |---------------| |
| | 802.11 PHY/ | | CAPWAP | | | |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA WTP AC STA WTP AC
Figure 1: Representative CAPWAP Architecture for Split MAC Figure 1: Representative CAPWAP Architecture for Split MAC
The Local MAC mode of operation allows for the data frames to be The Local MAC mode of operation allows for the data frames to be
either locally bridged, or tunneled as 802.3 frames. The latter either locally bridged, or tunneled as 802.3 frames. The latter
implies that the WTP performs the 802 bridging function. In either implies that the WTP performs the 802 bridging function. In either
case the L2 wireless management frames are processed locally by the case the L2 wireless management frames are processed locally by the
WTP, and then forwarded to the AC. Figure 2 provides an example WTP, and then forwarded to the AC. Figure 2 shows the Local MAC
using the IEEE 802.11 binding, where a station transmits an 802.11 mode, in which a station transmits a wireless frame which is
frame, which is encapsulated as 802.3 and forwarded to the AC. encapsulated in an 802.3 frame and forwarded to the AC.
+-+ 802.11 frames +-+ 802.3 frames +-+ +-+wireless frames +-+ 802.3 frames +-+
| |---------------| |--------------| | | |----------------| |--------------| |
| | | | | | | | | | | |
| |---------------| |--------------| | | |----------------| |--------------| |
| | 802.11 PHY/ | | CAPWAP | | | |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA WTP AC STA WTP AC
Figure 2: Representative CAPWAP Architecture for Local MAC Figure 2: Representative CAPWAP Architecture for Local MAC
Provisioning WTPs with security credentials, and managing which WTPs Provisioning WTPs with security credentials, and managing which WTPs
are authorized to provide service are traditionally handled by are authorized to provide service are traditionally handled by
proprietary solutions. Allowing these functions to be performed from proprietary solutions. Allowing these functions to be performed from
a centralized AC in an interoperable fashion increases manageability a centralized AC in an interoperable fashion increases manageability
skipping to change at page 8, line 41 skipping to change at page 7, line 41
higher efficiency by applying the capabilities of network higher efficiency by applying the capabilities of network
processing silicon to the wireless network, as in wired LANs. processing silicon to the wireless network, as in wired LANs.
2. To enable shifting of the higher level protocol processing from 2. To enable shifting of the higher level protocol processing from
the WTP. This leaves the time critical applications of wireless the WTP. This leaves the time critical applications of wireless
control and access in the WTP, making efficient use of the control and access in the WTP, making efficient use of the
computing power available in WTPs which are the subject to severe computing power available in WTPs which are the subject to severe
cost pressure. cost pressure.
3. To provide a generic encapsulation and transport mechanism, 3. To provide a generic encapsulation and transport mechanism,
enabling the CAPWAP protocol to be applied to other access point enabling the CAPWAP protocol to be applied to many access point
types in the future, via a specific wireless binding. types in the future, via a specific wireless binding.
The CAPWAP protocol concerns itself solely with the interface between The CAPWAP protocol concerns itself solely with the interface between
the WTP and the AC. Inter-AC, or mobile node (STA) to AC the WTP and the AC. Inter-AC, or station to AC communication is
communication is strictly outside the scope of this document. strictly outside the scope of this document.
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
1.3. Contributing Authors 1.3. Contributing Authors
This section lists and acknowledges the authors of significant text This section lists and acknowledges the authors of significant text
and concepts included in this specification. [Note: This section and concepts included in this specification. [Note: This section
needs work to accurately reflect the contribution of each author and needs work to accurately reflect the contribution of each author and
this work will be done in revision 01 of this document.] this work will be done a future revision of this document.]
The CAPWAP Working Group selected the Lightweight Access Point The CAPWAP Working Group selected the Lightweight Access Point
Protocol (LWAPP) [add reference, when available]to be used as the Protocol (LWAPP) [add reference, when available]to be used as the
basis of the CAPWAP protocol specification. The following people are basis of the CAPWAP protocol specification. The following people are
authors of the LWAPP document: authors of the LWAPP document:
Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134
Phone: +1 408-853-5513, Email: bob.ohara@cisco.com Phone: +1 408-853-5513, Email: bob.ohara@cisco.com
Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134
skipping to change at page 10, line 21 skipping to change at page 9, line 21
Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 408-754-1213, Email: subbu@arubanetworks.com Phone: +1 408-754-1213, Email: subbu@arubanetworks.com
1.4. Acknowledgements 1.4. Acknowledgements
The authors thank Michael Vakulenko for contributing text that The authors thank Michael Vakulenko for contributing text that
describes how CAPWAP can be used over a layer 3 (IP/UDP) network. describes how CAPWAP can be used over a layer 3 (IP/UDP) network.
The authors thank Russ Housley and Charles Clancy for their The authors thank Russ Housley and Charles Clancy for their
assistance in provide a security review of the LWAPP specification. assistance in provide a security review of the LWAPP specification.
Charles' review can be found at [16]. Charles' review can be found at [9].
1.5. Terminology 1.5. Terminology
Access Controller (AC): The network entity that provides WTP access
to the network infrastructure in the data plane, control plane,
management plane, or a combination therein.
Station (STA): A device that contains an IEEE 802.11 conformant Station (STA): A device that contains an IEEE 802.11 conformant
medium access control (MAC) and physical layer (PHY) interface to the medium access control (MAC) and physical layer (PHY) interface to the
wireless medium (WM). wireless medium (WM).
Basic Service Set (BSS): A set of stations controlled by a single Wireless Termination Point (WTP): The physical or network entity that
coordination function. contains an RF antenna and wireless PHY to transmit and receive
station traffic for wireless access networks.
Portal: The logical point at which medium access control (MAC)
service data units (MSDUs) from a non-IEEE 802.11 local area network
(LAN) enter the distribution system (DS) of an extended service set
(ESS).
Distribution System Service (DSS): The set of services provided by
the distribution system (DS) that enable the medium access control
(MAC) layer to transport MAC service data units (MSDUs) between
stations that are not in direct communication with each other over a
single instance of the wireless medium (WM). These services include
the transport of MSDUs between the access points (APs) of basic
service sets (BSSs) within an extended service set (ESS), transport
of MSDUs between portals and BSSs within an ESS, and transport of
MSDUs between stations in the same BSS in cases where the MSDU has a
multicast or broadcast destination address, or where the destination
is an individual address, but the station sending the MSDU chooses to
involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs.
Integration: The service that enables delivery of medium access
control (MAC) service data units (MSDUs) between the distribution
system (DS) and an existing, non-IEEE 802.11 local area network (via
a portal).
Distribution: The service that, by using association information, This Document uses additional terminology defined in [8].
delivers medium access control (MAC) service data units (MSDUs)
within the distribution system (DS).
2. Protocol Overview 2. Protocol Overview
The CAPWAP protocol is a generic protocol defining AC and WTP control The CAPWAP protocol is a generic protocol defining AC and WTP control
and data plane communication via a CAPWAP protocol transport and data plane communication via a CAPWAP protocol transport
mechanism. CAPWAP control messages, and optionally CAPWAP data mechanism. CAPWAP control messages, and optionally CAPWAP data
messages, are secured using Datagram Transport Layer Security (DTLS) messages, are secured using Datagram Transport Layer Security (DTLS)
[15]. DTLS is a standards-track IETF protocol based upon TLS. The [7]. DTLS is a standards-track IETF protocol based upon TLS. The
underlying security-related protocol mechanisms of TLS have been underlying security-related protocol mechanisms of TLS have been
successfully deployed for many years. successfully deployed for many years.
The CAPWAP protocol Transport layer carries two types of payload, The CAPWAP protocol Transport layer carries two types of payload,
CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data
messages encapsulate forwarded wireless frames. CAPWAP protocol messages encapsulate forwarded wireless frames. CAPWAP protocol
Control messages are management messages exchanged between a WTP and Control messages are management messages exchanged between a WTP and
an AC. The CAPWAP Data and Control packets are sent over separate an AC. The CAPWAP Data and Control packets are sent over separate
UDP ports. Since both data and control frames can exceed the PMTU, UDP ports. Since both data and control frames can exceed the PMTU,
the payload of a CAPWAP data or control message can be fragmented. the payload of a CAPWAP data or control message can be fragmented.
skipping to change at page 12, line 35 skipping to change at page 10, line 35
Discovery Request message, causing any Access Controller (AC) Discovery Request message, causing any Access Controller (AC)
receiving the message to respond with a Discovery Response message. receiving the message to respond with a Discovery Response message.
From the Discovery Response messages received, a WTP will select an From the Discovery Response messages received, a WTP will select an
AC with which to establish a secure DTLS session. CAPWAP protocol AC with which to establish a secure DTLS session. CAPWAP protocol
messages will be fragmented to the maximum length discovered to be messages will be fragmented to the maximum length discovered to be
supported by the network. supported by the network.
Once the WTP and the AC have completed DTLS session establishment, a Once the WTP and the AC have completed DTLS session establishment, a
configuration exchange occurs in which both devices to agree on configuration exchange occurs in which both devices to agree on
version information. During this exchange the WTP may receive version information. During this exchange the WTP may receive
provisioning settings. For the IEEE 802.11 binding, this information provisioning settings. The WTP is then enabled for operation.
typically includes a name (IEEE 802.11 Service Set Identifier, SSID)
security parameters, the data rates to be advertised and the
associated radio channel(s) to be used. The WTP is then enabled for
operation.
When the WTP and AC have completed the version and provision exchange When the WTP and AC have completed the version and provision exchange
and the WTP is enabled, the CAPWAP protocol is used to encapsulate and the WTP is enabled, the CAPWAP protocol is used to encapsulate
the wireless data frames sent between the WTP and AC. The CAPWAP the wireless data frames sent between the WTP and AC. The CAPWAP
protocol will fragment the L2 frames if the size of the encapsulated protocol will fragment the L2 frames if the size of the encapsulated
wireless user data (Data) or protocol control (Management) frames wireless user data (Data) or protocol control (Management) frames
causes the resulting CAPWAP protocol packet to exceed the MTU causes the resulting CAPWAP protocol packet to exceed the MTU
supported between the WTP and AC. Fragmented CAPWAP packets are supported between the WTP and AC. Fragmented CAPWAP packets are
reassembled to reconstitute the original encapsulated payload. reassembled to reconstitute the original encapsulated payload.
The CAPWAP protocol provides for the delivery of commands from the AC The CAPWAP protocol provides for the delivery of commands from the AC
to the WTP for the management of mobile units (STAs) that are to the WTP for the management of stations that are communicating with
communicating with the WTP. This may include the creation of local the WTP. This may include the creation of local data structures in
data structures in the WTP for the mobile units and the collection of the WTP for the stations and the collection of statistical
statistical information about the communication between the WTP and information about the communication between the WTP and the stations.
the mobile units. The CAPWAP protocol provides a mechanism for the The CAPWAP protocol provides a mechanism for the AC to obtain
AC to obtain statistical information collected by the WTP. statistical information collected by the WTP.
The CAPWAP protocol provides for a keep alive feature that preserves The CAPWAP protocol provides for a keep alive feature that preserves
the communication channel between the WTP and AC. If the AC fails to the communication channel between the WTP and AC. If the AC fails to
appear alive, the WTP will try to discover a new AC. appear alive, the WTP will try to discover a new AC.
2.1. Wireless Binding Definition 2.1. Wireless Binding Definition
The CAPWAP protocol is independent of a specific WTP radio The CAPWAP protocol is independent of a specific WTP radio
technology. Elements of the CAPWAP protocol are designed to technology. Elements of the CAPWAP protocol are designed to
accommodate the specific needs of each wireless technology in a accommodate the specific needs of each wireless technology in a
standard way. Implementation of the CAPWAP protocol for a particular standard way. Implementation of the CAPWAP protocol for a particular
wireless technology must follow the binding requirements defined for wireless technology must follow the binding requirements defined for
that technology. This specification includes a binding for the IEEE that technology.
802.11 standard(see Section 11).
When defining a binding for other wireless technologies, the authors When defining a binding for wireless technologies, the authors MUST
MUST include any necessary definitions for technology-specific include any necessary definitions for technology-specific messages
messages and all technology-specific message elements for those and all technology-specific message elements for those messages. At
messages. At a minimum, a binding MUST provide the definition for a a minimum, a binding MUST provide the definition for a binding-
binding-specific Statistics message element, carried in the WTP Event specific Statistics message element, carried in the WTP Event Request
Request message, and a Mobile message element, carried in the Mobile message, a message element carried in the Station Configure Request
Configure Request. If technology specific message elements are to configure STA information on the WTP, and a WTP Radio Information
required for any of the existing CAPWAP messages defined in this message element carried in the Discovery Request, Primary Discovery
specification, they MUST also be defined in the technology binding Request and and Join Request messages, indicating the binding
document. specific radio types supported at the WTP. If technology specific
message elements are required for any of the existing CAPWAP messages
defined in this specification, they MUST also be defined in the
technology binding document.
The naming of binding-specific message elements MUST begin with the The naming of binding-specific message elements MUST begin with the
name of the technology type, e.g., the binding for IEEE 802.11, name of the technology type, e.g., the binding for IEEE 802.11,
provided in this specification, begins with "IEEE 802.11"." provided in [11], begins with "IEEE 802.11"."
2.2. CAPWAP Session Establishment Overview 2.2. CAPWAP Session Establishment Overview
This section describes the session establishment process message This section describes the session establishment process message
exchanges in the ideal case. The annotated ladder diagram shows the exchanges in the ideal case. The annotated ladder diagram shows the
AC on the right, the WTP on the left, and assumes the use of AC on the right, the WTP on the left, and assumes the use of
certificates for DTLS authentication. The CAPWAP Protocol State certificates for DTLS authentication. The CAPWAP Protocol State
Machine is described in detail in Section 2.3. Machine is described in detail in Section 2.3.
============ ============ ============ ============
skipping to change at page 18, line 31 skipping to change at page 16, line 31
WTP: The WTP enters this state when the SilentInterval timer (see WTP: The WTP enters this state when the SilentInterval timer (see
Section 4.5) expires. Section 4.5) expires.
AC: This is a no-op. AC: This is a no-op.
Discovery to Join (e): This transition occurs when the WTP sends a Discovery to Join (e): This transition occurs when the WTP sends a
ClientHello message to the AC, confirming that it wishes to be ClientHello message to the AC, confirming that it wishes to be
provided services by the AC. provided services by the AC.
WTP: The WTP selects the best AC based either on information it WTP: The WTP selects the best AC based either on information
gathered during the Discovery Phase or on its configuration. it gathered during the Discovery Phase or on its configuration.
It then sends a JoinRequest message to its preferred AC, sets It then sends a JoinRequest message to its preferred AC, sets
the WaitJoin timer, and awaits the Join Response Message. the WaitJoin timer, and awaits the Join Response Message.
AC: This is a no-op for the AC. AC: This is a no-op for the AC.
Join to Discovery (f): This state transition is used to return the Join to Discovery (f): This state transition is used to return the
WTP to the Discovery state when an unresponsive AC is encountered. WTP to the Discovery state when an unresponsive AC is encountered.
WTP: The WTP re-enters the Discovery state when the WaitJoin timer WTP: The WTP re-enters the Discovery state when the WaitJoin
expires. timer expires.
AC: This is a no-op. AC: This is a no-op.
Join to Configure (g): This state transition is used by the WTP and Join to Configure (g): This state transition is used by the WTP and
the AC to exchange configuration information. the AC to exchange configuration information.
WTP: The WTP enters the Configure state when it successfully WTP: The WTP enters the Configure state when it successfully
completes the Join operation. If it determines that its completes the Join operation. If it determines that its
version number and the version number advertised by the AC are version number and the version number advertised by the AC are
the same, the WTP transmits the Configuration Status message compatible, the WTP transmits the Configuration Status message
(see Section 8.2) to the AC with a snapshot of its current (see Section 8.2) to the AC with a snapshot of its current
configuration. The WTP also starts the ResponseTimeout timer configuration. The WTP also starts the ResponseTimeout timer
(see ). (Section 4.5) If the version numbers are not the same, (see Section 4.5). If the version numbers are not compatible,
the WTP will immediately transition to Image Data state (see the WTP will immediately transition to Image Data state (see
transition (i)). transition (i)). If the AC determines that a new firmware
image should be installed on the WTP, the AC initiates a
firmware download by sending an Image Data Request Message with
an Initiate Download message element to the WTP
AC: This state transition occurs immediately after the AC AC: This state transition occurs immediately after the AC
transmits the Join Response message to the WTP. If the AC transmits the Join Response message to the WTP. If the AC
receives the Configuration Status message from the WTP, the AC receives the Configuration Status message from the WTP, the AC
must transmit a Configuration Status Response message(see must transmit a Configuration Status Response message(see
Section 8.3) to the WTP, and may include specific message Section 8.3) to the WTP, and may include specific message
elements to override the WTP's configuration. If the AC elements to override the WTP's configuration. If the AC
instead receives the Image Data Request from the WTP, it instead receives the Image Data Request from the WTP, it
immediately transitions to the Image Data state (see transition immediately transitions to the Image Data state (see transition
(i)). (i)).
Join to Reset (h): This state transition occurs when the WaitJoin Join to Reset (h): This state transition occurs when the WaitJoin
Timer expires. Timer expires.
WTP: The state transition occurs when the WTP WaitJoin timer WTP: The state transition occurs when the WTP WaitJoin timer
expires, or upon DTLS negotiation failure. expires, or upon DTLS negotiation failure.
AC: Thise state transition occurs when the AC WaitJoin timer AC: Thise state transition occurs when the AC WaitJoin timer
expires, or or upon DTLS negotiation failure. expires, or or upon DTLS negotiation failure.
Configure to Image Data (i): This state transition is used by the WTP Configure to Image Data (i): This state transition is used by the
and the AC to download executable firmware. WTP and the AC to download executable firmware.
WTP: The WTP enters the Image Data state when it successfully WTP: The WTP enters the Image Data state when it successfully
comletes DTLS session establishment, and determines that its comletes DTLS session establishment, and determines that its
version number and the version number advertised by the AC are version number and the version number advertised by the AC are
different. The WTP transmits the Image Data Request (see different. The WTP transmits the Image Data Request (see
Section 9.1) message requesting that a download of the AC's Section 9.1) message requesting that a download of the AC's
latest firmware be initiated. latest firmware be initiated.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP. The AC must transmit an Data Request message from the WTP. The AC must transmit an
Image Data Response message (see Section 9.2) to the WTP, which Image Data Response message (see Section 9.2) to the WTP, which
includes a portion of the firmware. includes a portion of the firmware.
Image Data to Image Data (j): The Image Data state is used by WTP and Image Data to Image Data (j): The Image Data state is used by WTP
the AC during the firmware download phase. and the AC during the firmware download phase.
WTP: The WTP enters the Image Data state when it receives an Image WTP: The WTP enters the Image Data state when it receives an
Data Response message indicating that the AC has more data to Image Data Response message indicating that the AC has more
send. data to send.
AC: This state transition occurs when the AC receives the Image AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP while already in the Image Data Request message from the WTP while already in the Image
Data state, and it detects that the firmware download has not Data state, and it detects that the firmware download has not
completed. completed.
Configure to Reset (k): This state transition is used to reset the Configure to Reset (k): This state transition is used to reset the
connection to the AC prior to restarting the WTP with a new connection to the AC prior to restarting the WTP with a new
configuration. configuration.
skipping to change at page 21, line 32 skipping to change at page 19, line 37
WTP Event: The WTP generates a WTP Event Request message to WTP Event: The WTP generates a WTP Event Request message to
send information to the AC (see Section 9.5). The WTP send information to the AC (see Section 9.5). The WTP
receives a WTP Event Response message from the AC (see receives a WTP Event Response message from the AC (see
Section 9.6). Section 9.6).
Data Transfer: The WTP generates a Data Transfer Request Data Transfer: The WTP generates a Data Transfer Request
message to the AC (see Section 9.7). The WTP receives a message to the AC (see Section 9.7). The WTP receives a
Data Transfer Response message from the AC (see Data Transfer Response message from the AC (see
Section 9.8). Section 9.8).
WLAN Configuration Request: The WTP receives a WLAN Station Configuration Request: The WTP receives a Station
Configuration Request message (see Section 11.6.1), to which Config Request message (see Section 10.1), to which it MUST
it MUST respond with a WLAN Configuration Response message respond with a Station Config Response message (see
(see Section 11.6.2). Section 10.2).
Mobile Configuration Request: The WTP receives a Mobile Config
Request message (see Section 10.1), to which it MUST respond
with a Mobile Config Response message (see Section 10.2).
AC: This is the AC's normal state of operation: AC: This is the AC's normal state of operation:
Configuration Update: The AC sends a Configuration Update Configuration Update: The AC sends a Configuration Update
Request message (see Section 8.4) to the WTP to update its Request message (see Section 8.4) to the WTP to update its
configuration. The AC receives a Configuration Update configuration. The AC receives a Configuration Update
Response message (see Section 8.5) from the WTP. Response message (see Section 8.5) from the WTP.
Change State Event: The AC receives a Change State Event Change State Event: The AC receives a Change State Event
Request message (see Section 8.6), to which it MUST respond Request message (see Section 8.6), to which it MUST respond
with the Change State Event Response message (see with the Change State Event Response message (see
Section 8.7). Section 8.7).
Echo: The AC sends an Echo Request message Section 7.1 or Echo: The AC sends an Echo Request message Section 7.1 or
receives the corresponding Echo Response message, see receives the corresponding Echo Response message, see
Section 7.2 from the WTP. Section 7.2 from the WTP.
Clear Config Response: The AC receives a Clear Configuration Clear Config Response: The AC receives a Clear Configuration
Response message (see Section 8.9). Response message (see Section 8.9).
WLAN Config: The AC sends a WLAN Configuration Request message Station Config: The AC sends a Station Configuration Request
(see Section 11.6.1) or receives the corresponding WLAN
Configuration Response message (see Section 11.6.2) from the
WTP.
Mobile Config: The AC sends a Mobile Configuration Request
message (see Section 10.1) or receives the corresponding message (see Section 10.1) or receives the corresponding
Mobile Configuration Response message (see Section 10.2) Station Configuration Response message (see Section 10.2)
from the WTP. from the WTP.
Data Transfer: The AC receives a Data Transfer Request message Data Transfer: The AC receives a Data Transfer Request message
from the AC (see Section 9.7) and MUST generate a from the AC (see Section 9.7) and MUST generate a
corresponding Data Transfer Response message (see corresponding Data Transfer Response message (see
Section 9.8). Section 9.8).
WTP Event: The AC receives a WTP Event Request message from the WTP Event: The AC receives a WTP Event Request message from
AC (see Section 9.5) and MUST generate a corresponding WTP the AC (see Section 9.5) and MUST generate a corresponding
Event Response message (see Section 9.6). WTP Event Response message (see Section 9.6).
Run to Reset(o): This state transition is used when the AC or WTP Run to Reset(o): This state transition is used when the AC or WTP
wish to tear down the connection. This may occur as part of wish to tear down the connection. This may occur as part of
normal operation, or due to error conditions. normal operation, or due to error conditions.
WTP: The WTP enters the Reset state when it initiates orderly WTP: The WTP enters the Reset state when it initiates orderly
termination of the DTLS connection, or when the underlying termination of the DTLS connection, or when the underlying
reliable transport is unable to transmit a message within the reliable transport is unable to transmit a message within the
RetransmitInterval timer, see Section 4.5 The WTP also enters RetransmitInterval timer, see Section 4.5. The WTP also enters
the Reset state upon receiving a DTLS session termination the Reset state upon receiving a DTLS session termination
message (DTLS alert) from the AC. The WTP sends a DTLSReset message (DTLS alert) from the AC. The WTP sends a DTLSShutdown
command to the DTLS state machine. command to the DTLS state machine.
AC: The AC enters the Idle state when it initiates orderly AC: The AC enters the Idle state when it initiates orderly
termination of the DTLS connection, or when the underlying termination of the DTLS connection, or when the underlying
reliable transport is unable to transmit a message within the reliable transport is unable to transmit a message within the
RetransmitInterval timer (see Section 4.5), and the maximum RetransmitInterval timer (see Section 4.5), and the maximum
number of RetransmitCount counter has reached the MaxRetransmit number of RetransmitCount counter has reached the MaxRetransmit
variable (see Section 4.6). The AC also enters the Reset state variable (see Section 4.6). The AC also enters the Reset state
upon receiving a DTLS session termination message from the WTP. upon receiving a DTLS session termination message from the WTP.
Reset to Idle (p): This state transition occurs when the state Reset to Idle (p): This state transition occurs when the state
machine is restarted following a system restart, an unrecoverable machine is restarted following a system restart, an unrecoverable
error on the AC-WTP connection, or orderly session teardown. error on the AC-WTP connection, or orderly session teardown.
WTP: The WTP clears any state associated with any AC and enters WTP: The WTP clears any state associated with any AC and enters
the Idle state. the Idle state.
AC: The AC clears any state associated with the WTP and enters the AC: The AC clears any state associated with the WTP and enters
idle state. the idle state.
Run to Image Data (s): This state transition occurs when the AC Run to Image Data (s): This state transition occurs when the AC
transmits an Image Data Request to the WTP, with the Initiate transmits an Image Data Request to the WTP, with the Initiate
Download message element. The means by which the AC decides to Download message element. The means by which the AC decides to
download firmware is undefined, but could occur through an download firmware is undefined, but could occur through an
administrative action. administrative action.
WTP: The WTP enters this state when it receives an an Image Data WTP: The WTP enters this state when it receives an an Image Data
Request to the WTP, with the Initiate Download message element. Request to the WTP, with the Initiate Download message element.
The WTP responds by transmitting an Image Data Request with the The WTP responds by transmitting an Image Data Request with the
skipping to change at page 25, line 17 skipping to change at page 23, line 10
WTP: The state ransition is triggered by receipt of the DTLSStart WTP: The state ransition is triggered by receipt of the DTLSStart
command from the CAPWAP state machine, and causes the WTP to command from the CAPWAP state machine, and causes the WTP to
send a DTLS ClientHello to the AC. send a DTLS ClientHello to the AC.
AC: The state transition is triggered by receipt of the DTLSStart AC: The state transition is triggered by receipt of the DTLSStart
command from the CAPWAP state machine. The AC starts the command from the CAPWAP state machine. The AC starts the
WaitJoin timer and awaits reception of a DTLS ClientHello WaitJoin timer and awaits reception of a DTLS ClientHello
message message
Init to Authenticate/Authorize (Y) This transition indicates that the Init to Authenticate/Authorize (Y) This transition indicates that
DTLS handshake is in progress. the DTLS handshake is in progress.
WTP: The WTP executes this state transition upon receipt of a WTP: The WTP executes this state transition upon receipt of a
valid ServerHello. valid ServerHello.
AC: The AC executes this transition upon receipt of a certificate AC: The AC executes this transition upon receipt of a certificate
payload (if configured for public key authentication) or upon payload (if configured for public key authentication) or upon
receipt of the ClientKeyExchange payload if configured for receipt of the ClientKeyExchange payload if configured for
preshared keys. preshared keys.
Init to Idle(X) This state transition occurs upon timeout of the Init to Idle(X) This state transition occurs upon timeout of the
skipping to change at page 26, line 13 skipping to change at page 24, line 10
of all credential payloads. of all credential payloads.
Authenticate/Authorize to Shutdown (V) This state transition Authenticate/Authorize to Shutdown (V) This state transition
indicates a failure of the DTLS handshake. indicates a failure of the DTLS handshake.
WTP: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the WTP: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the
CAPWAP state machine, depending on the exact cause of the CAPWAP state machine, depending on the exact cause of the
error. May send a DTLS notification to the AC to indicate error. May send a DTLS notification to the AC to indicate
failure. failure.
AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the CAPWAP AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the
state machine, depending on the exact cause of the error. May CAPWAP state machine, depending on the exact cause of the
send a DTLS Notification to the AC to indicate failure. error. May send a DTLS Notification to the AC to indicate
failure.
Authenticate/Authorize to Run (U) This state transition occurs upon Authenticate/Authorize to Run (U) This state transition occurs upon
successful completion of the DTLS handshake. successful completion of the DTLS handshake.
WTP: Send a DTLSEstablished notification to the CAPWAP state WTP: Send a DTLSEstablished notification to the CAPWAP state
machine. machine.
AC: Send a DTLSEstablished notification to the CAPWAP state AC: Send a DTLSEstablished notification to the CAPWAP state
machine. machine.
Run to Rekey (T) This state transition occurs when a DTLS rehandshake Run to Rekey (T) This state transition occurs when a DTLS
is in progress; this is initiated when either (a) the DTLS state rehandshake is in progress; this is initiated when either (a) the
machine receives the DTLSRehandshake command from CAPWAP, or (b) a DTLS state machine receives the DTLSRehandshake command from
DTLS rehandshake message is received from the peer.. CAPWAP, or (b) a DTLS rehandshake message is received from the
peer..
WTP: If CAPWAP issued a DTLSRehandshake command, initiate WTP: If CAPWAP issued a DTLSRehandshake command, initiate
rehandshake with the peer; note that control traffic may rehandshake with the peer; note that control traffic may
continue to flow using existing secure association. If the continue to flow using existing secure association. If the
rehandshake is initiated by the peer, send a DTLSRehandshake rehandshake is initiated by the peer, send a DTLSRehandshake
notification to CAPWAP. notification to CAPWAP.
AC: If CAPWAP issued a DTLSRehandshake command, initiate AC: If CAPWAP issued a DTLSRehandshake command, initiate
rehandshake with the peer; note that control traffic may rehandshake with the peer; note that control traffic may
continue to flow using existing secure association. If the continue to flow using existing secure association. If the
rehandshake is initiated by the peer, send a DTLSRehandshake rehandshake is initiated by the peer, send a DTLSRehandshake
notification to CAPWAP. notification to CAPWAP.
Run to Shutdown (S) This state transition indicates a shutdown of the Run to Shutdown (S) This state transition indicates a shutdown of
DTLS channel. the DTLS channel.
WTP: This state transition occurs when the CAPWAP state machine WTP: This state transition occurs when the CAPWAP state machine
sends a DTLSShutdown command, or when the the AC terminates the sends a DTLSShutdown command, or when the the AC terminates the
DTLS session. DTLS session.
AC: This state transition occurs when CAPWAP state machine sends a AC: This state transition occurs when CAPWAP state machine sends
DTLSShutdown command, or when the WTP terminates the DTLS a DTLSShutdown command, or when the WTP terminates the DTLS
session. session.
Rekey to Run (R) This state transition indicates the successful Rekey to Run (R) This state transition indicates the successful
completion of a DTLS rehandshake. completion of a DTLS rehandshake.
WTP: This state transition occurs when the WTP receives the DTLS WTP: This state transition occurs when the WTP receives the DTLS
Finished message from the AC, completing the DTLS re-handshake. Finished message from the AC, completing the DTLS re-handshake.
AC: This state transition occurs when the AC sends a DTLS Finished AC: This state transition occurs when the AC sends a DTLS
message to the WTP, completing the DTLS re-handshake. Finished message to the WTP, completing the DTLS re-handshake.
Rekey to Shutdown (Q) This state transition indicates the failure of Rekey to Shutdown (Q) This state transition indicates the failure of
the DTLS rekey operation. the DTLS rekey operation.
WTP: This state transition occurs when there is a failure in the WTP: This state transition occurs when there is a failure in the
rehandshake negotiation with the AC. rehandshake negotiation with the AC.
AC: This state transition occurs when there is a failure in the AC: This state transition occurs when there is a failure in the
rehandshake negotiation with the WTP. rehandshake negotiation with the WTP.
Shutdown to Idle (P) This state transition occurs upon transmission Shutdown to Idle (P) This state transition occurs upon transmission
of a DTLS Session termination message, or upon receipt of a DTLS of a DTLS Session termination message, or upon receipt of a DTLS
session termination message. session termination message.
WTP: This state transition occurs after the WTP transmits the DTLS WTP: This state transition occurs after the WTP transmits the
session termination message. If the WTP receives a DTLS DTLS session termination message. If the WTP receives a DTLS
session termination message, it sends the DTLSPeerDisconnect session termination message, it sends the DTLSPeerDisconnect
notification to CAPWAP and moves to the Idle state. notification to CAPWAP and moves to the Idle state.
AC: This state transition occurs after the AC transmits the DTLS AC: This state transition occurs after the AC transmits the DTLS
session termination message. If the AC receives a DTLS session session termination message. If the AC receives a DTLS session
termination message, it sends the DTLSPeerDisconnect termination message, it sends the DTLSPeerDisconnect
notification to CAPWAP and moves to the Idle state. notification to CAPWAP and moves to the Idle state.
2.4. Use of DTLS in the CAPWAP Protocol 2.4. Use of DTLS in the CAPWAP Protocol
skipping to change at page 33, line 37 skipping to change at page 31, line 37
2.4.4. DTLS EndPoint Authentication 2.4.4. DTLS EndPoint Authentication
DTLS supports endpoint authentication with certificates or preshared DTLS supports endpoint authentication with certificates or preshared
keys. The TLS algorithm suites for each endpoint authentication keys. The TLS algorithm suites for each endpoint authentication
method are described below. method are described below.
2.4.4.1. Authenticating with Certificates 2.4.4.1. Authenticating with Certificates
Note that only block ciphers are currently recommended for use with Note that only block ciphers are currently recommended for use with
DTLS. To understand the reasoning behind this, see [26]. However, DTLS. To understand the reasoning behind this, see [13]. However,
support for AES counter mode encryption is currently progressing in support for AES counter mode encryption is currently progressing in
the TLS working group, and once protocol identifiers are available, the TLS working group, and once protocol identifiers are available,
they will be added below. At present, the following algorithms MUST they will be added below. At present, the following algorithms MUST
be supported when using certificates for CAPWAP authentication: be supported when using certificates for CAPWAP authentication:
o TLS_RSA_WITH_AES_128_CBC_SHA o TLS_RSA_WITH_AES_128_CBC_SHA
o TLS_RSA_WITH_3DES_EDE_CBC_SHA o TLS_RSA_WITH_3DES_EDE_CBC_SHA
The following algorithms SHOULD be supported when using certificates: The following algorithms SHOULD be supported when using certificates:
skipping to change at page 34, line 14 skipping to change at page 32, line 14
The following algorithms MAY be supported when using certificates: The following algorithms MAY be supported when using certificates:
o TLS_RSA_WITH_AES_256_CBC_SHA o TLS_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_RSA_WITH_AES_256_CBC_SHA o TLS_DH_RSA_WITH_AES_256_CBC_SHA
2.4.4.2. Authenticating with Preshared Keys 2.4.4.2. Authenticating with Preshared Keys
Pre-shared keys present significant challenges from a security Pre-shared keys present significant challenges from a security
perspective, and for that reason, their use is strongly discouraged. perspective, and for that reason, their use is strongly discouraged.
However, [14] defines several different methods for authenticating However, [6] defines several different methods for authenticating
with preshared keys, and we focus on the following two: with preshared keys, and we focus on the following two:
o PSK key exchange algorithm - simplest method, ciphersuites use o PSK key exchange algorithm - simplest method, ciphersuites use
only symmetric key algorithms only symmetric key algorithms
o DHE_PSK key exchange algorithm - use a PSK to authenticate a o DHE_PSK key exchange algorithm - use a PSK to authenticate a
Diffie-Hellman exchange. These ciphersuites give some additional Diffie-Hellman exchange. These ciphersuites give some additional
protection against dictionary attacks and also provide Perfect protection against dictionary attacks and also provide Perfect
Forward Secrecy (PFS). Forward Secrecy (PFS).
skipping to change at page 34, line 51 skipping to change at page 33, line 8
The following algorithms MAY be supported when using preshared keys: The following algorithms MAY be supported when using preshared keys:
o TLS_PSK_WITH_AES_256_CBC_SHA o TLS_PSK_WITH_AES_256_CBC_SHA
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
2.4.4.3. Certificate Usage 2.4.4.3. Certificate Usage
When using certificates, both authentication and authorization must When using certificates, both authentication and authorization must
be considered. Section 13.3 provides recommendations on how to be considered. Section 12.3 provides recommendations on how to
authenticate a certificate and bind that to a CAPWAP entity. This authenticate a certificate and bind that to a CAPWAP entity. This
section deals with certificate authorization. section deals with certificate authorization.
Certificate authorization by the AC and WTP is required so that only Certificate authorization by the AC and WTP is required so that only
an AC may perform the functions of an AC and that only a WTP may an AC may perform the functions of an AC and that only a WTP may
perform the functions of a WTP. This restriction of functions to the perform the functions of a WTP. This restriction of functions to the
AC or WTP requires that the certificates used by the AC MUST be AC or WTP requires that the certificates used by the AC MUST be
distinguishable from the certificate used by the WTP. To accomplish distinguishable from the certificate used by the WTP. To accomplish
this differentiation, the x.509 certificates MUST include the this differentiation, the x.509 certificates MUST include the
Extended Key Usage (EKU)certificate extension [11]. Extended Key Usage (EKU)certificate extension [4].
The EKU field indicates one or more purposes for which a certificate The EKU field indicates one or more purposes for which a certificate
may be used. It is an essential part in authorization. Its syntax may be used. It is an essential part in authorization. Its syntax
is as follows: is as follows:
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER KeyPurposeId ::= OBJECT IDENTIFIER
Here we define two KeyPurposeId values, one for the WTP and one for Here we define two KeyPurposeId values, one for the WTP and one for
skipping to change at page 39, line 14 skipping to change at page 37, line 14
Control Header: The CAPWAP protocol includes a signalling component, Control Header: The CAPWAP protocol includes a signalling component,
known as the CAPWAP control protocol. All CAPWAP control packets known as the CAPWAP control protocol. All CAPWAP control packets
include a Control Header, which is defined in Section 4.3.1. include a Control Header, which is defined in Section 4.3.1.
Message Elements: A CAPWAP Control packet includes one or more Message Elements: A CAPWAP Control packet includes one or more
message elements, which are found immediately following the message elements, which are found immediately following the
control header. These message elements are in a Type/Length/value control header. These message elements are in a Type/Length/value
style header, defined in Section 4.4. style header, defined in Section 4.4.
4.1. CAPWAP Transport Header 4.1. CAPWAP Header
All CAPWAP protocol messages are encapsulated using a common header All CAPWAP protocol messages are encapsulated using a common header
format, regardless of the CAPWAP control or CAPWAP Data transport format, regardless of the CAPWAP control or CAPWAP Data transport
used to carry the messages. However, certain flags are not used to carry the messages. However, certain flags are not
applicable for a given transport. Refer to the specific transport applicable for a given transport. Refer to the specific transport
section in order to determine which flags are valid. section in order to determine which flags are valid.
Note that the optional fields defined in this section MUST be present Note that the optional fields defined in this section MUST be present
in the precise order shown below. in the precise order shown below.
skipping to change at page 40, line 11 skipping to change at page 38, line 11
HLEN: A 5 bit field containing the length of the CAPWAP transport HLEN: A 5 bit field containing the length of the CAPWAP transport
header in 4 byte words (Similar to IP header length). This length header in 4 byte words (Similar to IP header length). This length
includes the optional headers. includes the optional headers.
WBID: A 5 bit field which is the wireless binding identifier. The WBID: A 5 bit field which is the wireless binding identifier. The
identifier will indicate the type of wireless packet type identifier will indicate the type of wireless packet type
associated with the radio. The following values are defined: associated with the radio. The following values are defined:
1 - IEEE 802.11 1 - IEEE 802.11
2 - IEEE 802.16
3 - EPCGlobal
T: The Type 'T' bit indicates the format of the frame being T: The Type 'T' bit indicates the format of the frame being
transported in the payload (see Section 11.7). When this bit is transported in the payload. When this bit is set to one (1), the
set to one (1), the payload has the native frame format indicated payload has the native frame format indicated by the WBID field.
by the WBID field. When this bit is zero (0) the payload is an When this bit is zero (0) the payload is an IEEE 802.3 frame.
IEEE 802.3 frame.
F: The Fragment 'F' bit indicates whether this packet is a fragment. F: The Fragment 'F' bit indicates whether this packet is a fragment.
When this bit is one (1), the packet is a fragment and MUST be When this bit is one (1), the packet is a fragment and MUST be
combined with the other corresponding fragments to reassemble the combined with the other corresponding fragments to reassemble the
complete information exchanged between the WTP and AC. complete information exchanged between the WTP and AC.
L: The Last 'L' bit is valid only if the 'F' bit is set and indicates L: The Last 'L' bit is valid only if the 'F' bit is set and indicates
whether the packet contains the last fragment of a fragmented whether the packet contains the last fragment of a fragmented
exchange between WTP and AC. When this bit is 1, the packet is exchange between WTP and AC. When this bit is 1, the packet is
the last fragment. When this bit is 0, the packet is not the last the last fragment. When this bit is 0, the packet is not the last
skipping to change at page 40, line 39 skipping to change at page 38, line 42
wireless specific information field is present in the header. A wireless specific information field is present in the header. A
value of one (1) is used to represent the fact that the optional value of one (1) is used to represent the fact that the optional
header is present. header is present.
M: The M bit is used to indicate that the Radio MAC Address optional M: The M bit is used to indicate that the Radio MAC Address optional
header is present. This is used to communicate the MAC address of header is present. This is used to communicate the MAC address of
the receiving radio when the native wireless packet. This field the receiving radio when the native wireless packet. This field
MUST NOT be set to one in packets sent by the AC to the WTP. MUST NOT be set to one in packets sent by the AC to the WTP.
Flags: A set of reserved bits for future flags in the CAPWAP header. Flags: A set of reserved bits for future flags in the CAPWAP header.
All implementations complying with version zero of this protocol All implementations complying with this protocol MUST set to zero
MUST set these bits to zero. any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support.
Fragment ID: An 16 bit field whose value is assigned to each group of Fragment ID: An 16 bit field whose value is assigned to each group
fragments making up a complete set. The fragment ID space is of fragments making up a complete set. The fragment ID space is
managed individually for every WTP/AC pair. The value of Fragment managed individually for every WTP/AC pair. The value of Fragment
ID is incremented with each new set of fragments. The Fragment ID ID is incremented with each new set of fragments. The Fragment ID
wraps to zero after the maximum value has been used to identify a wraps to zero after the maximum value has been used to identify a
set of fragments. set of fragments.
Fragment Offset: A 13 bit field that indicates where in the payload Fragment Offset: A 13 bit field that indicates where in the payload
will this fragment belong during re-assembly. This field is valid will this fragment belong during re-assembly. This field is valid
when the 'F' bit is set to 1. The fragment offset is measured in when the 'F' bit is set to 1. The fragment offset is measured in
units of 8 octets (64 bits). The first fragment has offset zero. units of 8 octets (64 bits). The first fragment has offset zero.
Note the CAPWAP protocol does not allow for overlapping fragments. Note the CAPWAP protocol does not allow for overlapping fragments.
For instance, fragment 0 would include offset 0 with a payload For instance, fragment 0 would include offset 0 with a payload
length of 1000, while fragment 1 include offset 900 with a payload length of 1000, while fragment 1 include offset 900 with a payload
length of 600. length of 600.
Reserved: The 3-bit Reserved field is reserved and set to 0 in this Reserved: The 3-bit field is reserved for future use. All
version of the CAPWAP protocol. implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support.
Radio MAC Address: This optional field contains the MAC address of Radio MAC Address: This optional field contains the MAC address of
the radio receiving the packet. This is useful in packets sent the radio receiving the packet. This is useful in packets sent
from the WTP to the AC, when the native wireless frame format is from the WTP to the AC, when the native wireless frame format is
converted to 802.3 by the WTP. This field is only present if the converted to 802.3 by the WTP. This field is only present if the
'M' bit is set. Given the HLEN field assumes 4 byte alignment, 'M' bit is set. Given the HLEN field assumes 4 byte alignment,
this field MUST be padded with zeroes (0x00) if it is not 4 byte this field MUST be padded with zeroes (0x00) if it is not 4 byte
aligned. aligned.
The field contains the basic format: The field contains the basic format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address | Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The number of bytes in the MAC Address field. The length Length: The number of bytes in the MAC Address field. The length
field is present since new IEEE technologies (e.g., 802.16) are field is present since some technologies (e.g., IEEE 802.16)
now using 64 bits MAC addresses. are now using 64 bit MAC addresses.
MAC Address: The MAC Address of the receiving radio. MAC Address: The MAC Address of the receiving radio.
Wireless Specific Information: This optional field contains Wireless Specific Information: This optional field contains
technology specific information that may be used to carry per technology specific information that may be used to carry per
packet wireless information. This field is only present if the packet wireless information. This field is only present if the
'W' bit is set. Given the HLEN field assumes 4 byte alignment, 'W' bit is set. Given the HLEN field assumes 4 byte alignment,
this field MUST be padded with zeroes (0x00) if it is not 4 byte this field MUST be padded with zeroes (0x00) if it is not 4 byte
aligned. aligned.
skipping to change at page 42, line 4 skipping to change at page 40, line 10
this field MUST be padded with zeroes (0x00) if it is not 4 byte this field MUST be padded with zeroes (0x00) if it is not 4 byte
aligned. aligned.
The field contains the basic format: The field contains the basic format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wireless ID | Length | Data | Wireless ID | Length | Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wireless ID: The wireless binding identifier. The following Wireless ID: The wireless binding identifier. The following
values are defined: values are defined:
1 - : IEEE 802.11 1 - IEEE 802.11
2 - IEEE 802.16
3 - EPCGlobal
Length: The length of the data field Length: The length of the data field
Data: Wireless specific information, whose details are defined in Data: Wireless specific information, defined by the wireless
the technology specific bindings section (see Section 11.7). specific binding.
Payload: This field contains the header for a CAPWAP Data Message or Payload: This field contains the header for a CAPWAP Data Message or
CAPWAP Control Message, followed by the data associated with that CAPWAP Control Message, followed by the data associated with that
message. message.
4.2. CAPWAP Data Messages 4.2. CAPWAP Data Messages
A CAPWAP protocol data message encapsulates a forwarded wireless A CAPWAP protocol data message encapsulates a forwarded wireless
frame. The CAPWAP protocol defines two different modes of frame. The CAPWAP protocol defines two different modes of
encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3
skipping to change at page 43, line 8 skipping to change at page 41, line 14
4.3. CAPWAP Control Messages 4.3. CAPWAP Control Messages
The CAPWAP Control protocol provides a control channel between the The CAPWAP Control protocol provides a control channel between the
WTP and the AC. Control messages are divided into the following WTP and the AC. Control messages are divided into the following
distinct message types: distinct message types:
Discovery: CAPWAP Discovery messages are used to identify potential Discovery: CAPWAP Discovery messages are used to identify potential
ACs, their load and capabilities. ACs, their load and capabilities.
WTP Configuration: The WTP Configuration messages are used by the AC Join: CAPWAP Join messages are used to for a WTP to request service
to push a specific configuration to the WTP it has a control from an AC, and for the AC to respond to the WTP.
channel with. Messages that deal with the retrieval of statistics
from the WTP also fall in this category.
Mobile Session Management: Mobile session management messages are Control Channel Management: CAPWAP control channel management
used by the AC to push specific mobile station policies to the messages are used to maintain the control channel.
WTP.
Firmware Management: Messages in this category are used by the AC to WTP Configuration Management: The WTP Configuration messages are
push a new firmware image to the WTP. used by the AC to push a specific configuration to the WTP.
Messages which provide retrieval of statistics from the WTP also
fall in this category.
Binding Specific Management Frames: Messages in this category are Station Session Management: Station session management messages are
used by the AC and the WTP to exchange protocol-specific used by the AC to push specific Station policies to the WTP.
management frame. These frames may or may not be used to change
the link state of a Mobile device.
Discovery, WTP Configuration and Mobile Session Management messages Device Management Operations: Device management operations are used
MUST be implemented. Firmware Management MAY be implemented. to request and deliver a firmware image to the WTP.
In addition, technology specific bindings (see Section 11.7 may Binding Specific CAPWAP Management Frames: Messages in this category
introduce new control channel commands. are used by the AC and the WTP to exchange protocol-specific
CAPWAP management messages. These messages may or may not be used
to change the link state of a station.
Discovery, Join, Control Message Management, WTP Configuration
Management and Station Session Management CAPWAP control messages
MUST be implemented. Device Operations Management messages MAY be
implemented.
CAPWAP control messages sent from the WTP to the AC indicate that the
WTP is operational, providing an implicit keep-alive mechanism for
the WTP. The Control Channel Management Echo Request and Echo
Response messages provide an explicit keep-alive mechanism when other
CAPWAP control messages are not exchanged.
4.3.1. Control Message Format 4.3.1. Control Message Format
All CAPWAP control messages are sent encapsulated within the CAPWAP All CAPWAP control messages are sent encapsulated within the CAPWAP
header (see Section 4.1). Immediately following the CAPWAP header, header (see Section 4.1). Immediately following the CAPWAP header,
is the control header, which has the following format: is the control header, which has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 44, line 43 skipping to change at page 43, line 31
Image Data Request 15 Image Data Request 15
Image Data Response 16 Image Data Response 16
Reset Request 17 Reset Request 17
Reset Response 18 Reset Response 18
Primary Discovery Request 19 Primary Discovery Request 19
Primary Discovery Response 20 Primary Discovery Response 20
Data Transfer Request 21 Data Transfer Request 21
Data Transfer Response 22 Data Transfer Response 22
Clear Configuration Request 23 Clear Configuration Request 23
Clear Configuration Response 24 Clear Configuration Response 24
Mobile Configuration Request 25 Station Configuration Request 25
Mobile Configuration Response 26 Station Configuration Response 26
4.3.1.2. Sequence Number 4.3.1.2. Sequence Number
The Sequence Number Field is an identifier value to match request and The Sequence Number Field is an identifier value to match request and
response packet exchanges. When a CAPWAP packet with a request response packet exchanges. When a CAPWAP packet with a request
message type is received, the value of the sequence number field is message type is received, the value of the sequence number field is
copied into the corresponding response packet. copied into the corresponding response packet.
When a CAPWAP control message is sent, its internal sequence number When a CAPWAP control message is sent, its internal sequence number
counter is monotonically incremented, ensuring that no two requests counter is monotonically incremented, ensuring that no two requests
skipping to change at page 46, line 9 skipping to change at page 44, line 48
messages. Every message element is identified by the Type field, messages. Every message element is identified by the Type field,
whose numbering space is defined below. The total length of the whose numbering space is defined below. The total length of the
message elements is indicated in the Message Element Length field. message elements is indicated in the Message Element Length field.
All of the message element definitions in this document use a diagram All of the message element definitions in this document use a diagram
similar to the one below in order to depict its format. Note that in similar to the one below in order to depict its format. Note that in
order to simplify this specification, these diagrams do not include order to simplify this specification, these diagrams do not include
the header fields (Type and Length). The header field values are the header fields (Type and Length). The header field values are
defined in the Message element descriptions. defined in the Message element descriptions.
Note that unless otherwise specified, a control message that lists a
set of supported (or expected) message elements MUST not expect the
message elements to be in any specific order. The sender may order
the message elements as convenient. Furthermore, unless specifically
noted, any individual message element may exist one or more times
within a given control message.
Additional message elements may be defined in separate IETF Additional message elements may be defined in separate IETF
documents. documents.
The format of a message element uses the TLV format shown here: The format of a message element uses the TLV format shown here:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Value ... | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+
Where Type (16 bit) identifies the character of the information Where Type (16 bit) identifies the character of the information
carried in the Value field and Length (16 bits) indicates the number carried in the Value field and Length (16 bits) indicates the number
of bytes in the Value field. Type field values are allocated as of bytes in the Value field. Type field values are allocated as
follows: follows:
Usage Type Values Usage Type Values
CAPWAP Protocol Message Elements 1-1023 CAPWAP Protocol Message Elements 1-1023
IEEE 802.11 Message Elements 1024-2047 IEEE 802.11 Message Elements 1024-2047
Reserved for Future Use 2048 - 65024 IEEE 802.16 Message Elements 2048 - 3071
EPCGlobal Message Elements 3072 - 4095
Reserved for Future Use 4096 - 65024
The table below lists the CAPWAP protocol Message Elements and their The table below lists the CAPWAP protocol Message Elements and their
Type values. Type values.
CAPWAP Message Element Type Value CAPWAP Message Element Type Value
AC Descriptor 1 AC Descriptor 1
AC IPv4 List 2 AC IPv4 List 2
AC IPv6 List 3 AC IPv6 List 3
AC Name 4 AC Name 4
AC Name with Index 5 AC Name with Index 5
AC Timestamp 6 AC Timestamp 6
Add MAC ACL Entry 7 Add MAC ACL Entry 7
Add Mobile Station 8 Add Station 8
Add Static MAC ACL Entry 9 Add Static MAC ACL Entry 9
CAPWAP Timers 10 CAPWAP Control IPV4 Address 10
Data Transfer Data 11 CAPWAP Control IPV6 Address 11
Data Transfer Mode 12 CAPWAP Timers 12
Decryption Error Report 13 Data Transfer Data 13
Decryption Error Report Period 14 Data Transfer Mode 14
Delete MAC ACL Entry 15 Decryption Error Report 15
Delete Mobile Station 16 Decryption Error Report Period 16
Delete Static MAC ACL Entry 17 Delete MAC ACL Entry 17
Discovery Type 18 Delete Station 18
Duplicate IPv4 Address 19 Delete Static MAC ACL Entry 19
Duplicate IPv6 Address 20 Discovery Type 20
Idle Timeout 21 Duplicate IPv4 Address 21
Image Data 22 Duplicate IPv6 Address 22
Image Filename 23 Idle Timeout 23
Initiate Download 24 Image Data 24
Location Data 25 Image Filename 25
MTU Discovery Padding 26 Initiate Download 26
Radio Administrative State 27 Location Data 27
Result Code 28 MTU Discovery Padding 28
Session ID 29 Radio Administrative State 29
Statistics Timer 30 Radio Operational State 30
Vendor Specific Payload 31 Result Code 31
WTP Board Data 32 Session ID 32
WTP Descriptor 33 Statistics Timer 33
WTP Fallback 34 Vendor Specific Payload 34
WTP Frame Tunnel Mode 35 WTP Board Data 35
WTP IPv4 IP Address 36 WTP Descriptor 36
WTP MAC Type 37 WTP Fallback 37
WTP Manager Control IPv4 Address 38 WTP Frame Tunnel Mode 38
WTP Manager Control IPv6 Address 39 WTP IPv4 IP Address 39
WTP Name 40 WTP MAC Type 40
WTP Operational Statistics 41 WTP Name 41
WTP Radio Information 42 WTP Operational Statistics 42
WTP Radio Statistics 43 WTP Radio Statistics 43
WTP Reboot Statistics 44 WTP Reboot Statistics 44
WTP Static IP Address Information 45 WTP Static IP Address Information 45
4.4.1. AC Descriptor 4.4.1. AC Descriptor
The AC payload message element is used by the AC to communicate it's The AC payload message element is used by the AC to communicate it's
current state. The value contains the following fields. current state. The value contains the following fields.
0 1 2 3 0 1 2 3
skipping to change at page 48, line 34 skipping to change at page 47, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=5 | Length | | Type=5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1 for AC Descriptor Type: 1 for AC Descriptor
Length: 18 Length: >= 12
Stations: The number of mobile stations currently associated with Stations: The number of stations currently associated with the AC
the AC
Limit: The maximum number of stations supported by the AC Limit: The maximum number of stations supported by the AC
Active WTPs: The number of WTPs currently attached to the AC Active WTPs: The number of WTPs currently attached to the AC
Max WTPs: The maximum number of WTPs supported by the AC Max WTPs: The maximum number of WTPs supported by the AC
Security: A 8 bit bit mask specifying the authentication credential Security: A 8 bit bit mask specifying the authentication credential
type supported by the AC. The following values are supported (see type supported by the AC. The following values are supported (see
Section 2.4.4): Section 2.4.4):
skipping to change at page 49, line 6 skipping to change at page 48, line 4
Active WTPs: The number of WTPs currently attached to the AC Active WTPs: The number of WTPs currently attached to the AC
Max WTPs: The maximum number of WTPs supported by the AC Max WTPs: The maximum number of WTPs supported by the AC
Security: A 8 bit bit mask specifying the authentication credential Security: A 8 bit bit mask specifying the authentication credential
type supported by the AC. The following values are supported (see type supported by the AC. The following values are supported (see
Section 2.4.4): Section 2.4.4):
1 - X.509 Certificate Based 1 - X.509 Certificate Based
2 - Pre-Shared Secret 2 - Pre-Shared Secret
R-MAC Field: The AC supports the optional Radio MAC Address field in R-MAC Field: The AC supports the optional Radio MAC Address field
the CAPWAP transport Header (see Section 4.1). in the CAPWAP transport Header (see Section 4.1).
Wireless Field: The AC supports the optional Wireless Specific Wireless Field: The AC supports the optional Wireless Specific
Information field in the CAPWAP transport Header (see Information field in the CAPWAP Header (see Section 4.1).
Section 4.1).
Reserved: MUST be set to zero Reserved: All implementations complying with this protocol MUST set
to zero any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support.
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" Network Management Private Enterprise Codes"
Type: Vendor specific encoding of AC information. The following Type: Vendor specific encoding of AC information. The following
values are supported. The Hardware and Software Version values values are supported. The Hardware and Software Version values
MUST be included. MUST be included.
4 - Hardware Version: The AC's hardware version number. 4 - Hardware Version: The AC's hardware version number.
5 - Software Version: The AC's Firmware version number. 5 - Software Version: The AC's Firmware version number.
Length: Length of vendor specific encoding of AC information. Length: Length of vendor specific encoding of AC information.
Value: Vendor specific encoding of AC information. Value: Vendor specific encoding of AC information.
4.4.2. AC IPv4 List 4.4.2. AC IPv4 List
The AC List message element is used to configure a WTP with the The AC IPv4 List message element is used to configure a WTP with the
latest list of ACs in a cluster. latest list of ACs available for the WTP to join.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] | | AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for AC List Type: 2 for AC List
Length: 4 Length: 4
The AC IP Address: An array of 32-bit integers containing an AC's The AC IP Address: An array of 32-bit integers containing an AC's
IPv4 Address. IPv4 Address.
4.4.3. AC IPv6 List 4.4.3. AC IPv6 List
The AC List message element is used to configure a WTP with the The AC IPv6 List message element is used to configure a WTP with the
latest list of ACs in a cluster. latest list of ACs available for the WTP to join.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] | | AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] | | AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] | | AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 50, line 31 skipping to change at page 49, line 31
Type: 3 for AC IPV6 List Type: 3 for AC IPV6 List
Length: 16 Length: 16
The AC IP Address: An array of 32-bit integers containing an AC's The AC IP Address: An array of 32-bit integers containing an AC's
IPv6 Address. IPv6 Address.
4.4.4. AC Name 4.4.4. AC Name
The AC name message element contains an ASCII representation of the The AC name message element contains an UTF-8 representation of the
AC's identity. The value is a variable length byte string. The AC's identity. The value is a variable length byte string. The
string is NOT zero terminated. string is NOT zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Name ... | Name ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 4 for AC Name Type: 4 for AC Name
Length: > 0 Length: > 0
Name: A variable length ASCII string containing the AC's name Name: A variable length UTF-8 encoded string containing the AC's
name
4.4.5. AC Name with Index 4.4.5. AC Name with Index
The AC Name with Index message element is sent by the AC to the WTP The AC Name with Index message element is sent by the AC to the WTP
to configure preferred ACs. The number of instances where this to configure preferred ACs. The number of instances where this
message element would be present is equal to the number of ACs message element would be present is equal to the number of ACs
configured on the WTP. configured on the WTP.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
skipping to change at page 51, line 20 skipping to change at page 50, line 25
| Index | AC Name... | Index | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 for AC Name with Index Type: 5 for AC Name with Index
Length: > 2 Length: > 2
Index: The index of the preferred server (e.g., 1=primary, Index: The index of the preferred server (e.g., 1=primary,
2=secondary). 2=secondary).
AC Name: A variable length ASCII string containing the AC's name. AC Name: A variable length UTF-8 encoded string containing the AC's
name.
4.4.6. AC Timestamp 4.4.6. AC Timestamp
The AC Timestamp message element is sent by the AC to synchronize the The AC Timestamp message element is sent by the AC to synchronize the
WTP's clock. WTP's clock.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Timestamp Type: 6 for AC Timestamp
Length: 4 Length: 4
Timestamp: The AC's current time, allowing all of the WTPs to be Timestamp: The AC's current time, allowing all of the WTPs to be
time synchronized in the format defined by Network Time Protocol time synchronized in the format defined by Network Time Protocol
(NTP) in RFC 1305 [10]. (NTP) in RFC 1305 [3].
4.4.7. Add MAC ACL Entry 4.4.7. Add MAC ACL Entry
The Add MAC Access Control List (ACL) Entry message element is used The Add MAC Access Control List (ACL) Entry message element is used
by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP
no longer provides any service to the MAC addresses provided in the no longer provides any service to the MAC addresses provided in the
message. The MAC Addresses provided in this message element are not message. The MAC Addresses provided in this message element are not
expected to be saved in non-volatile memory on the WTP. expected to be saved in non-volatile memory on the WTP.
0 1 2 3 0 1 2 3
skipping to change at page 52, line 21 skipping to change at page 51, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 7 for Add MAC ACL Entry Type: 7 for Add MAC ACL Entry
Length: >= 7 Length: >= 7
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to add to the ACL. MAC Address: An array of MAC Addresses to add to the ACL.
4.4.8. Add Mobile Station 4.4.8. Add Station
The Add Mobile Station message element is used by the AC to inform a The Add Station message element is used by the AC to inform a WTP
WTP that it should forward traffic for a particular mobile station. that it should forward traffic for a particular station. The Add
The Add Mobile Station message element will be accompanied by Station message element will be accompanied by technology specific
technology specific binding information element which may include binding information element which may include security parameters.
security parameters. Consequently, the security parameters must be Consequently, the security parameters must be applied by the WTP for
applied by the WTP for the particular mobile. the particular station.
Once a mobile station's policy has been pushed to the WTP through Once a station's policy has been pushed to the WTP through this
this message element, an AC may change any policies by simply sending message element, an AC may change any policies by simply sending a
a modified Add Mobile Station message element. When a WTP receives modified Add Station message element. When a WTP receives an Add
an Add Mobile Station message element for an existing mobile station, Station message element for an existing station, it must override any
it must override any existing state it may have for the mobile existing state it may have for the station in question. The latest
station in question. The latest Add Mobile Station message element Add Station message element data overrides any previously received
data overrides any previously received messages. messages.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | MAC Address | | Radio ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | VLAN Name... | MAC Address | VLAN Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 8 for Add Mobile Type: 8 for Add Station
Length: >= 7 Length: >= 7
Radio ID: An 8-bit value representing the radio Radio ID: An 8-bit value representing the radio
MAC Address: The mobile station's MAC Address MAC Address: The station's MAC Address
VLAN Name: An optional variable string containing the VLAN Name on VLAN Name: An optional variable length UTF-8 encoded string
which the WTP is to locally bridge user data. Note this field is containing the VLAN Name on which the WTP is to locally bridge
only valid with WTPs configured in Local MAC mode. user data. Note this field is only valid with WTPs configured in
Local MAC mode.
4.4.9. Add Static MAC ACL Entry 4.4.9. Add Static MAC ACL Entry
The Add Static MAC ACL Entry message element is used by an AC to add The Add Static MAC ACL Entry message element is used by an AC to add
a permanent ACL entry on a WTP, ensuring that the WTP no longer a permanent ACL entry on a WTP, ensuring that the WTP no longer
provides any service to the MAC addresses provided in the message. provides any service to the MAC addresses provided in the message.
The MAC Addresses provided in this message element are expected to be The MAC Addresses provided in this message element are expected to be
saved in non-volative memory on the WTP. saved in non-volative memory on the WTP.
0 1 2 3 0 1 2 3
skipping to change at page 53, line 36 skipping to change at page 52, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 9 for Add Static MAC ACL Entry Type: 9 for Add Static MAC ACL Entry
Length: >= 7 Length: >= 7
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to add to the permanent ACL. MAC Address: An array of MAC Addresses to add to the permanent ACL.
4.4.10. CAPWAP Timers 4.4.10. CAPWAP Control IPv4 Address
The CAPWAP Control IPv4 Address message element is sent by the AC to
the WTP during the discovery process and is used by the AC to provide
the interfaces available on the AC, and the current number of WTPs
connected. In the event that multiple CAPWAP Control IPV4 Address
message elements are returned, the WTP is expected to perform load
balancing across the multiple interfaces.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Control IPv4 Address
Length: 6
IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface.
4.4.11. CAPWAP Control IPv6 Address
The CAPWAP Control IPv6 Address message element is sent by the AC to
the WTP during the discovery process and is used by the AC to provide
the interfaces available on the AC, and the current number of WTPs
connected. This message element is useful for the WTP to perform
load balancing across multiple interfaces.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for CAPWAP Control IPv6 Address
Length: 18
IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface.
4.4.12. CAPWAP Timers
The CAPWAP Timers message element is used by an AC to configure The CAPWAP Timers message element is used by an AC to configure
CAPWAP timers on a WTP. CAPWAP timers on a WTP.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request | | Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Timers Type: 12 for CAPWAP Timers
Length: 2 Length: 2
Discovery: The number of seconds between CAPWAP Discovery packets, Discovery: The number of seconds between CAPWAP Discovery packets,
when the WTP is in the discovery mode. when the WTP is in the discovery mode.
Echo Request: The number of seconds between WTP Echo Request CAPWAP Echo Request: The number of seconds between WTP Echo Request CAPWAP
messages. messages. The default value for this message element can be found
in Section 4.5.4.
4.4.11. Data Transfer Data 4.4.13. Data Transfer Data
The Data Transfer Data message element is used by the WTP to provide The Data Transfer Data message element is used by the WTP to provide
information to the AC for debugging purposes. information to the AC for debugging purposes.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Length | Data .... | Data Type | Data Length | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for Data Transfer Data Type: 13 for Data Transfer Data
Length: >= 3 Length: >= 3
Data Type: An 8-bit value the type of information being sent. The Data Type: An 8-bit value the type of information being sent. The
following values are supported: following values are supported:
1 - WTP Crash Data 1 - WTP Crash Data
2 - WTP Memory Dump 2 - WTP Memory Dump
Data Length: Length of data field. Data Length: Length of data field.
Data: Debug information. Data: Debug information.
4.4.12. Data Transfer Mode 4.4.14. Data Transfer Mode
The Data Transfer Mode message element is used by the WTP to indicate The Data Transfer Mode message element is used by the WTP to indicate
the type of data transfer information it is sending to the AC for the type of data transfer information it is sending to the AC for
debugging purposes. debugging purposes.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Data Type | | Data Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 12 for Data Transfer Mode
Type: 14 for Data Transfer Mode
Length: 1 Length: 1
Data Type: An 8-bit value the type of information being requested. Data Type: An 8-bit value the type of information being requested.
The following values are supported: The following values are supported:
1 - WTP Crash Data 1 - WTP Crash Data
2 - WTP Memory Dump 2 - WTP Memory Dump
4.4.13. Decryption Error Report 4.4.15. Decryption Error Report
The Decryption Error Report message element value is used by the WTP The Decryption Error Report message element value is used by the WTP
to inform the AC of decryption errors that have occurred since the to inform the AC of decryption errors that have occurred since the
last report. Note that this error reporting mechanism is not used if last report. Note that this error reporting mechanism is not used if
encryption and decryption services are provided via the AC. encryption and decryption services are provided via the AC.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID |Num Of Entries | Mobile MAC Address | | Radio ID |Num Of Entries | Station MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile MAC Address[] | | Station MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 13 for Decryption Error Report Type: 15 for Decryption Error Report
Length: >= 8 Length: >= 8
Radio ID: The Radio Identifier, which typically refers to an Radio ID: The Radio Identifier, which typically refers to an
interface index on the WTP interface index on the WTP
Num Of Entries: An 8-bit unsigned integer indicating the number of Num Of Entries: An 8-bit unsigned integer indicating the number of
mobile MAC addresses. station MAC addresses.
Mobile MAC Address: An array of mobile station MAC addresses that Station MAC Address: An array of station MAC addresses that have
have caused decryption errors. caused decryption errors.
4.4.14. Decryption Error Report Period 4.4.16. Decryption Error Report Period
The Decryption Error Report Period message element value is used by The Decryption Error Report Period message element value is used by
the AC to inform the WTP how frequently it should send decryption the AC to inform the WTP how frequently it should send decryption
error report messages. error report messages.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Report Interval | | Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 14 for Decryption Error Report Period Type: 16 for Decryption Error Report Period
Length: 3 Length: 3
Radio ID: The Radio Identifier, typically refers to some interface Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP index on the WTP
Report Interval: A 16-bit unsigned integer indicating the time, in Report Interval: A 16-bit unsigned integer indicating the time, in
seconds seconds. The default value for this message element can be found
in Section 4.6.6.
4.4.15. Delete MAC ACL Entry 4.4.17. Delete MAC ACL Entry
The Delete MAC ACL Entry message element is used by an AC to delete a The Delete MAC ACL Entry message element is used by an AC to delete a
MAC ACL entry on a WTP, ensuring that the WTP provides service to the MAC ACL entry on a WTP, ensuring that the WTP provides service to the
MAC addresses provided in the message. MAC addresses provided in the message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] | | MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 17 for Delete MAC ACL Entry
Type: 15 for Delete MAC ACL Entry
Length: >= 7 Length: >= 7
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to delete from the ACL. MAC Address: An array of MAC Addresses to delete from the ACL.
4.4.16. Delete Mobile Station 4.4.18. Delete Station
The Delete Mobile station message element is used by the AC to inform
an WTP that it should no longer provide service to a particular
mobile station. The WTP must terminate service immediately upon
receiving this message element.
The transmission of a Delete Mobile Station message element could The Delete Station message element is used by the AC to inform an WTP
occur for various reasons, including for administrative reasons, as a that it should no longer provide service to a particular station.
result of the fact that the mobile has roamed to another WTP, etc. The WTP must terminate service immediately upon receiving this
message element.
Once access has been terminated for a given station, any future The transmission of a Delete Station message element could occur for
packets received from the mobile station must result in a various reasons, including for administrative reasons, as a result of
deauthenticate message, as specified in [6]. the fact that the station has roamed to another WTP, etc.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | MAC Address | | Radio ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for Delete Mobile Station Type: 18 for Delete Station
Length: 7 Length: 7
Radio ID: An 8-bit value representing the radio Radio ID: An 8-bit value representing the radio
MAC Address: The mobile station's MAC Address MAC Address: The station's MAC Address
4.4.17. Delete Static MAC ACL Entry 4.4.19. Delete Static MAC ACL Entry
The Delete Static MAC ACL Entry message element is used by an AC to The Delete Static MAC ACL Entry message element is used by an AC to
delete a previously added static MAC ACL entry on a WTP, ensuring delete a previously added static MAC ACL entry on a WTP, ensuring
that the WTP provides service to the MAC addresses provided in the that the WTP provides service to the MAC addresses provided in the
message. message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] | | MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 17 for Delete Static MAC ACL Entry Type: 19 for Delete Static MAC ACL Entry
Length: >= 7 Length: >= 7
Num of Entries: The number of MAC Addresses in the array. Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to delete from the static MAC MAC Address: An array of MAC Addresses to delete from the static
ACL entry. MAC ACL entry.
4.4.18. Discovery Type 4.4.20. Discovery Type
The Discovery Type message element is used by the WTP to indicate how The Discovery Type message element is used by the WTP to indicate how
it has come to know about the existence of the AC, to which it is it has come to know about the existence of the AC, to which it is
sending the Discovery Request message. sending the Discovery Request message.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Discovery Type| | Discovery Type|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 18 for Discovery Type Type: 20 for Discovery Type
Length: 1 Length: 1
Discovery Type: An 8-bit value indicating how the WTP discovered the Discovery Type: An 8-bit value indicating how the WTP discovered
AC . The following values are supported: the AC . The following values are supported:
0 - Unknown 0 - Unknown
1 - Static Configuration 1 - Static Configuration
2 - DHCP 2 - DHCP
3 - DNS 3 - DNS
4 - AC Referral 4 - AC Referral
4.4.19. Duplicate IPv4 Address 4.4.21. Duplicate IPv4 Address
The Duplicate IPv4 Address message element is used by a WTP to inform The Duplicate IPv4 Address message element is used by a WTP to inform
an AC that it has detected another IP device using the same IP an AC that it has detected another IP device using the same IP
address it is currently using. address it is currently using.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 19 for Duplicate IPv4 Address Type: 21 for Duplicate IPv4 Address
Length: 10 Length: 10
IP Address: The IP Address currently used by the WTP. IP Address: The IP Address currently used by the WTP.
MAC Address: The MAC Address of the offending device. MAC Address: The MAC Address of the offending device.
4.4.20. Duplicate IPv6 Address 4.4.22. Duplicate IPv6 Address
The Duplicate IPv6 Address message element is used by a WTP to inform The Duplicate IPv6 Address message element is used by a WTP to inform
an AC that it has detected another host using the same IP address it an AC that it has detected another host using the same IP address it
is currently using. is currently using.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 59, line 30 skipping to change at page 59, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 20 for Duplicate IPv6 Address Type: 22 for Duplicate IPv6 Address
Length: 22 Length: 22
IP Address: The IP Address currently used by the WTP. IP Address: The IP Address currently used by the WTP.
MAC Address: The MAC Address of the offending device. MAC Address: The MAC Address of the offending device.
4.4.21. Idle Timeout 4.4.23. Idle Timeout
The Idle Timeout message element is sent by the AC to the WTP to The Idle Timeout message element is sent by the AC to the WTP to
provide it with the idle timeout that it should enforce on its active provide it with the idle timeout that it should enforce on its active
mobile station entries. station entries. The value applies for all radios on the WTP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout | | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 20 for Idle Timeout
Type: 23 for Idle Timeout
Length: 4 Length: 4
Timeout: The current idle timeout to be enforced by the WTP. Timeout: The current idle timeout to be enforced by the WTP. The
default value for this message element can be found in
Section 4.6.3.
4.4.22. Image Data 4.4.24. Image Data
The image data message element is present in the Image Data Request The image data message element is present in the Image Data Request
message sent by the AC and contains the following fields. message sent by the AC and contains the following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Checksum | Image Data | | Opcode | Checksum | Image Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Image Data ... | | Image Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22 for Image Data Type: 24 for Image Data
Length: >= 4 (allows 0 length element if last data unit is 1024 Length: >= 4 (allows 0 length element if last data unit is 1024
bytes) bytes)
Opcode: An 8-bit value representing the transfer opcode. The Opcode: An 8-bit value representing the transfer opcode. The
following values are supported: following values are supported:
3 - Image data is included 3 - Image data is included
5 - An error occurred. Transfer is aborted 5 - An error occurred. Transfer is aborted
Checksum: A 16-bit value containing a checksum of the image data Checksum: A 16-bit value containing a checksum of the image data
that follows that follows
Image Data: The Image Data field contains 1024 characters, unless Image Data: The Image Data field contains 1024 characters, unless
the payload being sent is the last one (end of file). If the last the payload being sent is the last one (end of file). If the last
block was 1024 in length, an Image Data with a zero length payload block was 1024 in length, an Image Data with a zero length payload
is sent. is sent.
skipping to change at page 60, line 43 skipping to change at page 61, line 14
5 - An error occurred. Transfer is aborted 5 - An error occurred. Transfer is aborted
Checksum: A 16-bit value containing a checksum of the image data Checksum: A 16-bit value containing a checksum of the image data
that follows that follows
Image Data: The Image Data field contains 1024 characters, unless Image Data: The Image Data field contains 1024 characters, unless
the payload being sent is the last one (end of file). If the last the payload being sent is the last one (end of file). If the last
block was 1024 in length, an Image Data with a zero length payload block was 1024 in length, an Image Data with a zero length payload
is sent. is sent.
4.4.23. Image Filename 4.4.25. Image Filename
The image filename message element is sent by the WTP to the AC and The image filename message element is sent by the WTP to the AC and
is used to initiate the firmware download process. This message is used to initiate the firmware download process. This message
element contains the image filename, which the AC subsequently element contains the image filename, which the AC subsequently
transfers to the WTP via the Image Data message element. The value transfers to the WTP via the Image Data message element. The value
is a variable length byte string, which is NOT zero terminated. is a variable length UTF-8 encoded string, which is NOT zero
terminated.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filename ... | | Filename ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 23 for Image Filename Type: 25 for Image Filename
Length: >= 1 Length: >= 1
Filename: A variable length string containing the filename to Filename: A variable length UTF-8 encoded string containing the
download. filename to download.
4.4.24. Initiate Download 4.4.26. Initiate Download
The Initiate Download message element is used by the AC to inform the The Initiate Download message element is used by the AC to inform the
WTP that it should initiate a firmware upgrade. This is performed by WTP that it should initiate a firmware upgrade. This is performed by
having the WTP initiate its own Image Data Request, with the Image having the WTP initiate its own Image Data Request, with the Image
Download message element. This message element does not contain any Download message element. This message element does not contain any
data. data.
Type: 24 for Initiate Download Type: 24 for Initiate Download
Length: 0 Length: 0
4.4.25. Location Data 4.4.27. Location Data
The Location Data message elementis a variable length byte string The Location Data message element is a variable length byte UTF-8
containing user defined location information (e.g. "Next to encoded string containing user defined location information (e.g.
Fridge"). This information is configurable by the network "Next to Fridge"). This information is configurable by the network
administrator, and allows for the WTP location to be determined administrator, and allows for the WTP location to be determined
through this field. The string is not zero terminated. through this field. The string is not zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
| Location ... | Location ...
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
Type: 25 for Location Data Type: 27 for Location Data
Length: > 0 Length: > 0
Timeout: A non-zero terminated string containing the WTP location. Location: A non-zero terminated UTF-8 encoded string containing the
WTP location.
4.4.26. MTU Discovery Padding 4.4.28. MTU Discovery Padding
The MTU Discovery Padding message element is used as padding to The MTU Discovery Padding message element is used as padding to
perform MTU discovery, and MUST contain octets of value 0xFF, of any perform MTU discovery, and MUST contain octets of value 0xFF, of any
length length
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Padding... | Padding...
+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-
Type: 26 for MTU Discovery Padding Type: 28 for MTU Discovery Padding
Length: variable Length: variable
Timeout: A variable length pad. Pad: A variable length pad.
4.4.27. Radio Administrative State 4.4.29. Radio Administrative State
The radio administrative state message element is used to communicate The radio administrative state message element is used to communicate
the state of a particular radio. The value contains the following the state of a particular radio. The configuration of the Radio
Administrative State is sent by the AC to change the state of the
WTP, which saves the value to ensure its effect remains across WTP
resets. The WTP communicates this message element during the
configuration phase to ensure that AC has the WTP radio's current
administrative state settings. The value contains the following
fields. fields.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State | Cause | | Radio ID | Admin State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 27 for Administrative State Type: 29 for Administrative State
Length: 2 Length: 2
Radio ID: An 8-bit value representing the radio to configure. The Radio ID: An 8-bit value representing the radio to configure. The
Radio ID field may also include the value of 0xff, which is used Radio ID field may also include the value of 0xff, which is used
to identify the WTP itself. Therefore, if an AC wishes to change to identify the WTP itself. Therefore, if an AC wishes to change
the administrative state of a WTP, it would include 0xff in the the administrative state of a WTP, it would include 0xff in the
Radio ID field. Radio ID field.
Admin State: An 8-bit value representing the administrative state of Admin State: An 8-bit value representing the administrative state
the radio. The following values are supported: of the radio. The default value for the Admin State field is
listed in section Section 4.6.1. The following values are
supported:
1 - Enabled 1 - Enabled
2 - Disabled 2 - Disabled
Cause: In the event of a radio being inoperable, the cause field Cause: In the event of a radio being inoperable, the cause field
would contain the reason the radio is out of service. The would contain the reason the radio is out of service. The
following values are supported: following values are supported:
0 - Normal 0 - Normal
1 - Radio Failure 1 - Radio Failure
skipping to change at page 63, line 18 skipping to change at page 63, line 44
following values are supported: following values are supported:
0 - Normal 0 - Normal
1 - Radio Failure 1 - Radio Failure
2 - Software Failure 2 - Software Failure
3 - Radar Detection 3 - Radar Detection
4.4.28. Result Code 4.4.30. Radio Operational State
The Radio Operational State message element is sent by the WTP to the
AC to communicate a change in the operational state of a radio. For
instance, if the WTP were to detect that a hardware failure existed
with a radio, which caused the radio to be taken offline, the WTP
would indicate this event to the AC via the message element. The AC
MAY also send this message element to change the operational state of
a specific radio. Note that the operational state setting is not
saved on the WTP, and therefore does not remain across WTP resets.
The value contains two fields, as shown.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for Radio Operational State
Length: 3
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP. A value of 0xFF is invalid, as it is not
possible to change the WTP's operational state.
State: An 8-bit boolean value representing the state of the radio.
A value of one disables the radio, while a value of two enables
it.
Cause: In the event of a radio being inoperable, the cause field
would contain the reason the radio is out of service. The
following values are supported:
0 - Normal
1 - Radio Failure
2 - Software Failure
3 - Administratively Set
4.4.31. Result Code
The Result Code message element value is a 32-bit integer value, The Result Code message element value is a 32-bit integer value,
indicating the result of the request operation corresponding to the indicating the result of the request operation corresponding to the
sequence number in the message. sequence number in the message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 31 for Result Code
Type: 28 for Result Code
Length: 4 Length: 4
Result Code: The following values are defined: Result Code: The following values are defined:
0 Success 0 Success
1 Failure (AC List message element MUST be present) 1 Failure (AC List message element MUST be present)
2 Success (NAT detected) 2 Success (NAT detected)
skipping to change at page 64, line 4 skipping to change at page 65, line 23
2 Success (NAT detected) 2 Success (NAT detected)
3 Failure (unspecified) 3 Failure (unspecified)
4 Failure (Join Failure, Resource Depletion) 4 Failure (Join Failure, Resource Depletion)
5 Failure (Join Failure, Unknown Source) 5 Failure (Join Failure, Unknown Source)
6 Failure (Join Failure, Incorrect Data) 6 Failure (Join Failure, Incorrect Data)
7 Failure (Join Failure, Session ID already in use) 7 Failure (Join Failure, Session ID already in use)
4.4.29. Session ID 8 Failure (Join Failure, WTP Hardware not supported)
9 Failure (Unable to Reset)
4.4.32. Session ID
The session ID message element value contains a randomly generated The session ID message element value contains a randomly generated
unsigned 32-bit integer. unsigned 32-bit integer.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 29 for Session ID Type: 32 for Session ID
Length: 4 Length: 4
Session ID: A 32-bit random session identifier Session ID: A 32-bit random session identifier
4.4.30. Statistics Timer 4.4.33. Statistics Timer
The statistics timer message element value is used by the AC to The statistics timer message element value is used by the AC to
inform the WTP of the frequency which it expects to receive updated inform the WTP of the frequency which it expects to receive updated
statistics. statistics.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer | | Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for Statistics Timer Type: 33 for Statistics Timer
Length: 2 Length: 2
Statistics Timer: A 16-bit unsigned integer indicating the time, in Statistics Timer: A 16-bit unsigned integer indicating the time, in
seconds seconds. The default value for this timer can be found in section
Section 4.6.8.
4.4.31. Vendor Specific Payload 4.4.34. Vendor Specific Payload
The Vendor Specific Payload is used to communicate vendor specific The Vendor Specific Payload is used to communicate vendor specific
information between the WTP and the AC. The value contains the information between the WTP and the AC. The value contains the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... | | Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 31 for Vendor Specific Type: 34 for Vendor Specific
Length: >= 7 Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" [19] Network Management Private Enterprise Codes" [12]
Element ID: A 16-bit Element Identifier which is managed by the Element ID: A 16-bit Element Identifier which is managed by the
vendor. vendor.
Value: The value associated with the vendor specific element. Value: The value associated with the vendor specific element.
4.4.32. WTP Board Data 4.4.35. WTP Board Data
The WTP Board Data message element is sent by the WTP to the AC and The WTP Board Data message element is sent by the WTP to the AC and
contains information about the hardware present. contains information about the hardware present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Length | | Type=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length | | Type=1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional additional vendor specific WTP board data TLVs | Optional additional vendor specific WTP board data TLVs
Type: 32 for WTP Board Data Type: 35 for WTP Board Data
Length: >=14 Length: >=14
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" Network Management Private Enterprise Codes"
Type: The following values are supported: Type: The following values are supported:
0 - WTP Model Number: The WTP Model Number MUST be included in 0 - WTP Model Number: The WTP Model Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included in 1 - WTP Serial Number: The WTP Serial Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
skipping to change at page 66, line 15 skipping to change at page 67, line 35
Network Management Private Enterprise Codes" Network Management Private Enterprise Codes"
Type: The following values are supported: Type: The following values are supported:
0 - WTP Model Number: The WTP Model Number MUST be included in 0 - WTP Model Number: The WTP Model Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included in 1 - WTP Serial Number: The WTP Serial Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
2 - Board ID: A hardware identifier, which MAY be included in the 2 - Board ID: A hardware identifier, which MAY be included in
WTP Board Data mesage element. the WTP Board Data mesage element.
3 - Board Revision A revision number of the board, which MAY be 3 - Board Revision A revision number of the board, which MAY be
included in the WTP Board Data message element. included in the WTP Board Data message element.
4.4.33. WTP Descriptor 4.4.36. WTP Descriptor
The WTP descriptor message element is used by a WTP to communicate The WTP descriptor message element is used by a WTP to communicate
it's current hardware/firmware configuration. The value contains the it's current hardware/firmware configuration. The value contains the
following fields. following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Encryption Capabilities | | Max Radios | Radios in use | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 67, line 4 skipping to change at page 68, line 28
| Type=1 | Length | | Type=1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Length | | Type=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 33 for WTP Descriptor
Type: 36 for WTP Descriptor
Length: >= 31 Length: >= 31
Max Radios: An 8-bit value representing the number of radios (where Max Radios: An 8-bit value representing the number of radios (where
each radio is identified via the RID field) supported by the WTP each radio is identified via the Radio ID, or RID, field)
supported by the WTP
Radios in use: An 8-bit value representing the number of radios Radios in use: An 8-bit value representing the number of radios
present in the WTP present in the WTP
Encryption Capabilities: This 16-bit field is used by the WTP to Encryption Capabilities: This 16-bit field is used by the WTP to
communicate it's capabilities to the AC. Since most WTP's support communicate it's capabilities to the AC. A WTP that does not have
link layer encryption, the AC may make use of these services. any encryption capabilities sets this field to zero (0). Refer to
There are binding dependent encryption capabilities. A WTP that the specific wireless binding for further specification of the
does not have any encryption capabilities would set this field to Encryption Capabilities field.
zero (0). Refer to the specific binding for further specification
of the Encryption Capabilities field.
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" Network Management Private Enterprise Codes"
Type: The following values are supported. The Hardware Version, Type: The following values are supported. The Hardware Version,
Software Version, and Boot Version values MUST be included. Software Version, and Boot Version values MUST be included.
0 - WTP Model Number: The WTP Model Number MUST be included in 0 - WTP Model Number: The WTP Model Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included in 1 - WTP Serial Number: The WTP Serial Number MUST be included in
the WTP Board Data message element. the WTP Board Data message element.
2 - Board ID: A hardware identifier, which MAY be included in the 2 - Board ID: A hardware identifier, which MAY be included in
WTP Board Data mesage element. the WTP Board Data mesage element.
3 - Board Revision A revision number of the board, which MAY be 3 - Board Revision A revision number of the board, which MAY be
included in the WTP Board Data message element. included in the WTP Board Data message element.
4 - Hardware Version: The WTP's hardware version number. 4 - Hardware Version: The WTP's hardware version number.
5 - Software Version: The WTP's Firmware version number. 5 - Software Version: The WTP's Firmware version number.
6 - Boot Version: The WTP's boot loader's version number. 6 - Boot Version: The WTP's boot loader's version number.
Length: Length of vendor specific encoding of WTP information. Length: Length of vendor specific encoding of WTP information.
Value: Vendor specific encoding of WTP information. Value: Vendor specific data of WTP information encoded in the UTF-8
format.
4.4.34. WTP Fallback 4.4.37. WTP Fallback
The WTP Fallback message element is sent by the AC to the WTP to The WTP Fallback message element is sent by the AC to the WTP to
enable or disable automatic CAPWAP fallback in the event that a WTP enable or disable automatic CAPWAP fallback in the event that a WTP
detects its preferred AC, and is not currently connected to it. detects its preferred AC, and is not currently connected to it.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Mode | | Mode |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 34 for WTP Fallback Type: 37 for WTP Fallback
Length: 1 Length: 1
Mode: The 8-bit value indicates the status of automatic CAPWAP Mode: The 8-bit value indicates the status of automatic CAPWAP
fallback on the WTP. A value of zero disables fallback, while a fallback on the WTP. When enabled, if the WTP detects that its
value of one enables it. When enabled, if the WTP detects that primary AC is available, and it is not connected to it, it SHOULD
its primary AC is available, and it is not connected to it, it automatically disconnect from its current AC and reconnect to its
SHOULD automatically disconnect from its current AC and reconnect primary. If disabled, the WTP will only reconnect to its primary
to its primary. If disabled, the WTP will only reconnect to its through manual intervention (e.g., through the Reset Request
primary through manual intervention (e.g., through the Reset command). The default value for this field can be found in
Request command). section Section 4.6.9. The following values are supported:
4.4.35. WTP Frame Tunnel Mode 1 - Enabled
2 - Disabled
4.4.38. WTP Frame Tunnel Mode
The WTP Frame Tunnel Mode message element allows the WTP to The WTP Frame Tunnel Mode message element allows the WTP to
communicate the tunneling modes of operation which it supports to the communicate the tunneling modes of operation which it supports to the
AC. A WTP that advertises support for all types allows the AC to AC. A WTP that advertises support for all types allows the AC to
select which type will be used, based on its local policy. select which type will be used, based on its local policy.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Tunnel Mode | | Tunnel Mode |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 35 for WTP Frame Tunnel Mode Type: 38 for WTP Frame Tunnel Mode
Length: 1 Length: 1
Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling
modes for mobile station data which are supported by the WTP. The modes for station data which are supported by the WTP. The
following values are supported: following values are supported:
1 - Local Bridging: When Local Bridging is used, the WTP does not 1 - Local Bridging: When Local Bridging is used, the WTP does
tunnel user traffic to the AC; all user traffic is locally not tunnel user traffic to the AC; all user traffic is locally
bridged. This value MUST NOT be used when the WTP MAC Type is bridged. This value MUST NOT be used when the WTP MAC Type is
set to Split-MAC. set to Split-MAC.
2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode requires 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode
the WTP and AC to encapsulate all user payload as native IEEE requires the WTP and AC to encapsulate all user payload as
802.3 frames (see Section 4.2). All user traffic is tunneled native IEEE 802.3 frames (see Section 4.2). All user traffic
to the AC. This value MUST NOT be used when the WTP MAC Type is tunneled to the AC. This value MUST NOT be used when the
is set to Split-MAC. WTP MAC Type is set to Split-MAC.
4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires
the WTP and AC to encapsulate all user payloads as native the WTP and AC to encapsulate all user payloads as native
wireless frames, as defined by the wireless binding (see for wireless frames, as defined by the wireless binding (see for
example Section 4.2). example Section 4.2).
7 - All: The WTP is capable of supporting all frame tunnel modes. 7 - All: The WTP is capable of supporting all frame tunnel
modes.
4.4.36. WTP IPv4 IP Address 4.4.39. WTP IPv4 IP Address
The WTP IPv4 address is used to perform NAT detection. The WTP IPv4 address is used to perform NAT detection.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP IPv4 IP Address | | WTP IPv4 IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 36 for WTP IPv4 IP Address Type: 39 for WTP IPv4 IP Address
Length: 4 Length: 4
WTP IPv4 IP Address: The IPv4 address from which the WTP is sending WTP IPv4 IP Address: The IPv4 address from which the WTP is sending
packets. This field is used for NAT detection. packets. This field is used for NAT detection.
4.4.37. WTP MAC Type 4.4.40. WTP MAC Type
The WTP MAC-Type message element allows the WTP to communicate its The WTP MAC-Type message element allows the WTP to communicate its
mode of operation to the AC. A WTP that advertises support for both mode of operation to the AC. A WTP that advertises support for both
modes allows the AC to select the mode to use, based on local policy. modes allows the AC to select the mode to use, based on local policy.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MAC Type | | MAC Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 37 for WTP MAC Type
Type: 40 for WTP MAC Type
Length: 1 Length: 1
MAC Type: The MAC mode of operation supported by the WTP. The MAC Type: The MAC mode of operation supported by the WTP. The
following values are supported following values are supported
0 - Local-MAC: Local-MAC is the default mode that MUST be 0 - Local-MAC: Local-MAC is the default mode that MUST be
supported by all WTPs. supported by all WTPs.
1 - Split-MAC: Split-MAC support is optional, and allows the AC 1 - Split-MAC: Split-MAC support is optional, and allows the AC
to receive and process native wireless frames. to receive and process native wireless frames.
2 - Both: WTP is capable of supporting both Local-MAC and Split- 2 - Both: WTP is capable of supporting both Local-MAC and Split-
MAC. MAC.
4.4.38. WTP Radio Information
The WTP radios information message element is used to communicate the
radio information in a specific slot. The Discovery Request MUST
include one such message element per radio in the WTP. The Radio-
Type field is used by the AC in order to determine which technology
specific binding is to be used with the WTP.
The value contains two fields, as shown.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Radio Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio Type |
+-+-+-+-+-+-+-+-+
Type: 38 for WTP Radio Information
Length: 5
Radio ID: The Radio Identifier, which typically refers to an
interface index on the WTP
Radio Type: The type of radio present. Note this bitfield can be
used to specify support for more than a single type of PHY/MAC.
The following values are supported:
1 - 802.11b: An IEEE 802.11b radio.
2 - 802.11a: An IEEE 802.11a radio.
4 - 802.11g: An IEEE 802.11g radio.
8 - 802.11n: An IEEE 802.11n radio.
0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types
indicated are supported in the WTP.
4.4.39. WTP Manager Control IPv4 Address
The WTP Manager Control IPv4 Address message element is sent by the
AC to the WTP during the discovery process and is used by the AC to
provide the interfaces available on the AC, and the current number of
WTPs connected. In the event that multiple WTP Manager Control IPV4
Address message elements are returned, the WTP is expected to perform
load balancing across the multiple interfaces.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Manager Control IPv4 Address
Length: 6
IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface.
4.4.40. WTP Manager Control IPv6 Address
The WTP Manager Control IPv6 Address message element is sent by the
AC to the WTP during the discovery process and is used by the AC to
provide the interfaces available on the AC, and the current number of
WTPs connected. This message element is useful for the WTP to
perform load balancing across multiple interfaces.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 40 for WTP Manager Control IPv6 Address
Length: 18
IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface.
4.4.41. WTP Name 4.4.41. WTP Name
The WTP Name message element is a variable length bye string. The The WTP Name message element is a variable length byte UTF-8 encoded
string is not zero terminated. string. The string is not zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
| WTP Name ... | WTP Name ...
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
Type: 41 for WTP Name Type: 41 for WTP Name
Length: variable Length: variable
WTP Name: A non-zero terminated string containing the WTP name. WTP Name: A non-zero terminated UTF-8 encoded string containing the
WTP name.
4.4.42. WTP Operational Statistics 4.4.42. WTP Operational Statistics
The WTP Operational Statistics message element is sent by the WTP to The WTP Operational Statistics message element is sent by the WTP to
the AC to provide statistics related to the operation of the WTP. the AC to provide statistics related to the operation of the WTP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Tx Queue Level | Wireless Link Frames per Sec | | Radio ID | Tx Queue Level | Wireless Link Frames per Sec |
skipping to change at page 73, line 20 skipping to change at page 72, line 48
Radio ID: The radio ID of the radio to which the statistics apply. Radio ID: The radio ID of the radio to which the statistics apply.
Wireless Transmit Queue Level: The percentage of Wireless Transmit Wireless Transmit Queue Level: The percentage of Wireless Transmit
queue utilization, calaculated as the sum of utilized transmit queue utilization, calaculated as the sum of utilized transmit
queue lengths divided by the sum of maximum transmit queue queue lengths divided by the sum of maximum transmit queue
lengths, multiplied by 100. The Wireless Transmit Queue Level is lengths, multiplied by 100. The Wireless Transmit Queue Level is
representative of congestion conditions over wireless interfaces representative of congestion conditions over wireless interfaces
between the WTP and wireless terminals. between the WTP and wireless terminals.
Wireless Link Frames per Sec: The number of frames transmitted or Wireless Link Frames per Sec: The number of frames transmitted or
received per second by the WTP over the sir interface. received per second by the WTP over the air interface.
4.4.43. WTP Radio Statistics 4.4.43. WTP Radio Statistics
The WTP Radio Statistics message element is sent by the WTP to the AC The WTP Radio Statistics message element is sent by the WTP to the AC
to communicate statistics on radio behavior and reasons why the WTP to communicate statistics on radio behavior and reasons why the WTP
radio has been reset. radio has been reset.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 74, line 18 skipping to change at page 73, line 44
0 - Statistic Not Supported 0 - Statistic Not Supported
1 - Software Failure 1 - Software Failure
2 - Hardware Failure 2 - Hardware Failure
3 - Other Failure 3 - Other Failure
255 - Unknown (e.g., WTP doesn't keep track of info) 255 - Unknown (e.g., WTP doesn't keep track of info)
Reset Count: The number of times that that the radio has been reset. Reset Count: The number of times that that the radio has been
reset.
SW Failure Count: The number of times that the radio has failed due SW Failure Count: The number of times that the radio has failed due
to software related reasons. to software related reasons.
HW Failure Count: The number of times that the radio has failed due HW Failure Count: The number of times that the radio has failed due
to hardware related reasons. to hardware related reasons.
Other Failure Count: The number of times that the radio has failed Other Failure Count: The number of times that the radio has failed
due to known reasons, other than software or hardware failure. due to known reasons, other than software or hardware failure.
Unknown Failure Count: The number of times that the radio has failed Unknown Failure Count: The number of times that the radio has
for unknown reasons. failed for unknown reasons.
Config Update Count: The number of times that the radio Config Update Count: The number of times that the radio
configuration has been updated. configuration has been updated.
Channel Change Count: The number of times that the radio channel has Channel Change Count: The number of times that the radio channel
been changed. has been changed.
Band Change Count: The number of times that the radio has changed Band Change Count: The number of times that the radio has changed
frequency bands. frequency bands.
Current Noise Floor: A signed integer which indicates the noise Current Noise Floor: A signed integer which indicates the noise
floor of the radio receiver in units of dBm. floor of the radio receiver in units of dBm.
4.4.44. WTP Reboot Statistics 4.4.44. WTP Reboot Statistics
The WTP Reboot Statistics message element is sent by the WTP to the The WTP Reboot Statistics message element is sent by the WTP to the
skipping to change at page 76, line 41 skipping to change at page 76, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway | | Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static | | Static |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 45 for WTP Static IP Address Information Type: 45 for WTP Static IP Address Information
Length: 13 Length: 13
IP Address: The IP Address to assign to the WTP. This field is only IP Address: The IP Address to assign to the WTP. This field is
valid if the static field is set to one. only valid if the static field is set to one.
Netmask: The IP Netmask. This field is only valid if the static Netmask: The IP Netmask. This field is only valid if the static
field is set to one. field is set to one.
Gateway: The IP address of the gateway. This field is only valid if Gateway: The IP address of the gateway. This field is only valid
the static field is set to one. if the static field is set to one.
Netmask: The IP Netmask. This field is only valid if the static Netmask: The IP Netmask. This field is only valid if the static
field is set to one. field is set to one.
Static: An 8-bit boolean stating whether the WTP should use a static Static: An 8-bit boolean stating whether the WTP should use a
IP address or not. A value of zero disables the static IP static IP address or not. A value of zero disables the static IP
address, while a value of one enables it. address, while a value of one enables it.
4.5. CAPWAP Protocol Timers 4.5. CAPWAP Protocol Timers
A WTP or AC that implements CAPWAP discovery MUST implement the A WTP or AC that implements CAPWAP discovery MUST implement the
following timers. following timers.
4.5.1. DiscoveryInterval 4.5.1. DiscoveryInterval
The minimum time, in seconds, that a WTP MUST wait after receiving a The minimum time, in seconds, that a WTP MUST wait after receiving a
skipping to change at page 79, line 9 skipping to change at page 78, line 32
The maximum time, in seconds, a WTP MUST wait without having received The maximum time, in seconds, a WTP MUST wait without having received
a DTLS Handshake message from an AC. This timer must be greater than a DTLS Handshake message from an AC. This timer must be greater than
30 seconds. 30 seconds.
Default: 60 Default: 60
4.6. CAPWAP Protocol Variables 4.6. CAPWAP Protocol Variables
A WTP or AC that implements CAPWAP discovery MUST allow for the A WTP or AC that implements CAPWAP discovery MUST allow for the
following variables to be configured by system management; default following variables to be configured by system management; default
values are specified so as to make it unnecessary to configure any of values are specified, making explicit configuration unnecessary in
these variables in many cases. many cases. If the default values are explicitly overriden by the
AC, the WTP MUST save the values sent by the AC.
4.6.1. DiscoveryCount 4.6.1. AdminState
The default Administrative State value is enabled (1).
4.6.2. DiscoveryCount
The number of discoveries transmitted by a WTP to a single AC. This The number of discoveries transmitted by a WTP to a single AC. This
is a monotonically increasing counter. is a monotonically increasing counter.
4.6.2. MaxDiscoveries 4.6.3. IdleTimeout
The default Idle Timeout is 300 seconds.
4.6.4. MaxDiscoveries
The maximum number of discovery requests that will be sent after a The maximum number of discovery requests that will be sent after a
WTP boots. WTP boots.
Default: 10 Default: 10
4.6.3. MaxRetransmit 4.6.5. MaxRetransmit
The maximum number of retransmissions for a given CAPWAP packet The maximum number of retransmissions for a given CAPWAP packet
before the link layer considers the peer dead. before the link layer considers the peer dead.
Default: 5 Default: 5
4.6.4. RetransmitCount 4.6.6. ReportInterval
The default Report Interval is 120 seconds.
4.6.7. RetransmitCount
The number of retransmissions for a given CAPWAP packet. This is a The number of retransmissions for a given CAPWAP packet. This is a
monotonically increasing counter. monotonically increasing counter.
4.6.8. StatisticsTimer
The default Statistics Interval is 120 seconds.
4.6.9. WTPFallBack
The default WTP Fallback value is enabled (1).
4.7. WTP Saved Variables
In addition to the values defined in Section 4.6, the following
values SHOULD be saved on the WTP in non-volatile memory. CAPWAP
wireless bindings may define additional values that SHOULD be stored
on the WTP.
4.7.1. AdminRebootCount
The number of times the WTP has rebooted administratively, defined in
Section 4.4.44.
4.7.2. FrameEncapType
For WTPs that support multiple Frame Encapsulation Types, it is
useful to save the value configured by the AC. The Frame
Encapsulation Type is defined in Section 4.4.38.
4.7.3. LastRebootReason
The reason why the WTP last rebooted, defined in Section 4.4.44.
4.7.4. MacType
For WTPs that support multiple MAC Types, it is usefule to save the
value configured by the AC. The MAC Type is defined in
Section 4.4.40.
4.7.5. PreferredACs
The preferred ACs, with the index, defined in Section 4.4.5.
4.7.6. RebootCount
The number of times the WTP has rebooted, defined in Section 4.4.44.
4.7.7. Static ACL Table
The static ACL table saved on the WTP, as configured by the Add
Static MAC ACL Entry message element, see Section 4.4.9.
4.7.8. Static IP Address
The static IP Address assigned to the WTP, as configured by the
message element, see Section 4.4.45.
4.7.9. WTPLinkFailureCount
The number of times the link to the AC has failed, see
Section 4.4.44.
4.7.10. WTPLocation
The WTP Location, defined in Section 4.4.27.
4.7.11. WTPName
The WTP Name, defined in Section 4.4.41.
5. CAPWAP Discovery Operations 5. CAPWAP Discovery Operations
The Discovery messages are used by a WTP to determine which ACs are The Discovery messages are used by a WTP to determine which ACs are
available to provide service, and the capabilities and load of the available to provide service, and the capabilities and load of the
ACs. ACs.
5.1. Discovery Request Message 5.1. Discovery Request Message
The Discovery Request message is used by the WTP to automatically The Discovery Request message is used by the WTP to automatically
discover potential ACs available in the network. The Discovery discover potential ACs available in the network. The Discovery
skipping to change at page 81, line 6 skipping to change at page 82, line 6
The Discovery Request message may be sent as a unicast, broadcast or The Discovery Request message may be sent as a unicast, broadcast or
multicast message. multicast message.
Upon receiving a Discovery Request message, the AC will respond with Upon receiving a Discovery Request message, the AC will respond with
a Discovery Response message sent to the address in the source a Discovery Response message sent to the address in the source
address of the received discovery request message. address of the received discovery request message.
The following message elements MUST be included in the Discovery The following message elements MUST be included in the Discovery
Request message: Request message:
o Discovery Type, see Section 4.4.18 o Discovery Type, see Section 4.4.20
o WTP Descriptor, see Section 4.4.33
o WTP Frame Tunnel Mode, see Section 4.4.35 o WTP Descriptor, see Section 4.4.36
o WTP MAC Type, see Section 4.4.37 o WTP Frame Tunnel Mode, see Section 4.4.38
o WTP Radio Information, see Section 4.4.38 o WTP MAC Type, see Section 4.4.40
5.2. Discovery Response Message 5.2. Discovery Response Message
The Discovery Response message provides a mechanism for an AC to The Discovery Response message provides a mechanism for an AC to
advertise its services to requesting WTPs. advertise its services to requesting WTPs.
The Discovery Response message is sent by an AC after receiving a The Discovery Response message is sent by an AC after receiving a
Discovery Request message from a WTP. Discovery Request message from a WTP.
When a WTP receives a Discovery Response message, it MUST wait for an When a WTP receives a Discovery Response message, it MUST wait for an
skipping to change at page 81, line 38 skipping to change at page 82, line 36
sent a Discovery Response message and send a DTLS Handshake to that sent a Discovery Response message and send a DTLS Handshake to that
AC. AC.
The following message elements MUST be included in the Discovery The following message elements MUST be included in the Discovery
Response Message: Response Message:
o AC Descriptor, see Section 4.4.1 o AC Descriptor, see Section 4.4.1
o AC Name, see Section 4.4.4 o AC Name, see Section 4.4.4
o WTP Manager Control IPv4 Address, see Section 4.4.39 o CAPWAP Control IPv4 Address, see Section 4.4.10
o WTP Manager Control IPv6 Address, see Section 4.4.40 o CAPWAP Control IPv6 Address, see Section 4.4.11
5.3. Primary Discovery Request Message 5.3. Primary Discovery Request Message
The Primary Discovery Request message is sent by the WTP to determine The Primary Discovery Request message is sent by the WTP to determine
whether its preferred (or primary) AC is available. whether its preferred (or primary) AC is available.
A Primary Discovery Request message is sent by a WTP when it has a A Primary Discovery Request message is sent by a WTP when it has a
primary AC configured, and is connected to another AC. This primary AC configured, and is connected to another AC. This
generally occurs as a result of a failover, and is used by the WTP as generally occurs as a result of a failover, and is used by the WTP as
a means to discover when its primary AC becomes available. As a a means to discover when its primary AC becomes available. As a
skipping to change at page 82, line 16 skipping to change at page 83, line 15
The frequency of the Primary Discovery Request messages should be no The frequency of the Primary Discovery Request messages should be no
more often than the sending of the Echo Request message. more often than the sending of the Echo Request message.
Upon receipt of a Discovery Request message, the AC responds with a Upon receipt of a Discovery Request message, the AC responds with a
Primary Discovery Response message sent to the address in the source Primary Discovery Response message sent to the address in the source
address of the received Primary Discovery Request message. address of the received Primary Discovery Request message.
The following message elements MUST be included in the Primary The following message elements MUST be included in the Primary
Discovery Request message. Discovery Request message.
o Discovery Type, see Section 4.4.18 o Discovery Type, see Section 4.4.20
o WTP Descriptor, see Section 4.4.33
o WTP Frame Tunnel Mode, see Section 4.4.35 o WTP Descriptor, see Section 4.4.36
o WTP MAC Type, see Section 4.4.37 o WTP Frame Tunnel Mode, see Section 4.4.38
o WTP Radio Information, see Section 4.4.38 A WTP Radio Information o WTP MAC Type, see Section 4.4.40
message element MUST be present for every radio in the WTP.
5.4. Primary Discovery Response 5.4. Primary Discovery Response
The Primary Discovery Response message enables an AC to advertise its The Primary Discovery Response message enables an AC to advertise its
availability and services to requesting WTPs that are configured to availability and services to requesting WTPs that are configured to
have the AC as its primary AC. have the AC as its primary AC.
The Primary Discovery Response message is sent by an AC after The Primary Discovery Response message is sent by an AC after
receiving a Primary Discovery Request message. receiving a Primary Discovery Request message.
skipping to change at page 82, line 48 skipping to change at page 83, line 44
the configuration of the WTP Fallback Status message element on the the configuration of the WTP Fallback Status message element on the
WTP. WTP.
The following message elements MUST be included in the Primary The following message elements MUST be included in the Primary
Discovery Response message. Discovery Response message.
o AC Descriptor, see Section 4.4.1 o AC Descriptor, see Section 4.4.1
o AC Name, see Section 4.4.4 o AC Name, see Section 4.4.4
o WTP Manager Control IPv4 Address, see Section 4.4.39 o CAPWAP Control IPv4 Address, see Section 4.4.10
o WTP Manager Control IPv6 Address, see Section 4.4.40 o CAPWAP Control IPv6 Address, see Section 4.4.11
6. CAPWAP Join Operations 6. CAPWAP Join Operations
The Join Request message is used by a WTP to request service from an The Join Request message is used by a WTP to request service from an
AC after a DTLS connection is established to that AC. The Join AC after a DTLS connection is established to that AC. The Join
Response message is used by the the AC to indicate that it will or Response message is used by the the AC to indicate that it will or
will not provide service. will not provide service.
6.1. Join Request 6.1. Join Request
The Join Request message is used by a WTP to inform an AC that it The Join Request message is used by a WTP to inform an AC that it
wishes to provide services through the AC. A Join Request message is wishes to provide services through the AC. A Join Request message is
sent by a WTP after receiving one or more Discovery Responses, and sent by a WTP after (optionally) receiving one or more Discovery
completion of DTLS session establishment. When an AC receives a Join Responses, and completion of DTLS session establishment. When an AC
Request message it responds with a Join Response message. receives a Join Request message it responds with a Join Response
message.
Upon completion of the DTLS handshake (synonymous with DTLS "session Upon completion of the DTLS handshake (synonymous with DTLS "session
establishment"), the WTP sends the Join Request message to the AC. establishment"), the WTP sends the Join Request message to the AC.
Upon receipt of the Join Request Message, the AC generates a Join Upon receipt of the Join Request Message, the AC generates a Join
Response message and sends it to the WTP, indicating success or Response message and sends it to the WTP, indicating success or
failure. failure.
Upon transmission of the Join Request message, the WTP sets the If the AC rejects the Join Request, it sends a Join Response message
WaitJoin timer. If the Join Response message has not been received with a failure indication then enters the CAPWAP reset state,
prior to expiration, the WTP aborts the Join process and transitions resulting in shutdown of the DTLS session.
back to the Discovery state, see Section 2.3.1). Upon receipt of the
Join Response message, the WaitJoin timer is deactivated.
If the AC rejects the Join Request, it sends a Join Response with a
failure indication then enters the CAPWAP reset state, resulting in
shutdown of the DTLS session.
Upon determining which AC to join, the WTP creates session state
containing the AC address and session ID, creates the Join Request
message, sets the WaitJoin timer for the session and sends the Join
Request message to the AC.
If an invalid (i.e. malformed) Join Request message is received, the If an invalid (i.e. malformed) Join Request message is received, the
message MUST be silently discarded by the AC. No response is sent to message MUST be silently discarded by the AC. No response is sent to
the WTP. The AC SHOULD log this event. the WTP. The AC SHOULD log this event.
The following message elements MUST be included in the Join Request The following message elements MUST be included in the Join Request
message. message.
o Location Data, see Section 4.4.25 o Location Data, see Section 4.4.27
o Session ID, see Section 4.4.29 o Session ID, see Section 4.4.32
o WTP Descriptor, see Section 4.4.33
o WTP IPv4 IP Address, see Section 4.4.36 o WTP Descriptor, see Section 4.4.36
o WTP Name, see Section 4.4.41 o WTP IPv4 IP Address, see Section 4.4.39
o WTP Radio Information, see Section 4.4.38 A WTP Radio Information o WTP Name, see Section 4.4.41
message element MUST be present for every radio in the WTP.
6.2. Join Response 6.2. Join Response
The Join Response message is sent by the AC to indicate to a WTP that The Join Response message is sent by the AC to indicate to a WTP that
it is capable and willing to provide service to it. it is capable and willing to provide service to it.
After determining that a WTP should join the AC, the AC creates Upon receipt of the DTLSClientHello, the AC creates session state
session state containing the WTP address, port and session ID, sets containing the WTP address, port and session ID, sets the WaitJoin
the WaitJoin timer for the session, sends the Join Response message timer for the session, sends the Join Response message to the WTP.
to the WTP.
The WTP, receiving a Join Response message checks for success or The WTP, receiving a Join Response message checks for success or
failure. If the message indicates success, the WTP clears the failure. If the message indicates success, the WTP clears the
WaitJoin timer for the session and proceeds to the Configure or Image WaitJoin timer for the session and proceeds to the Configure state.
Data state. Otherwise, the WTP enters the CAPWAP reset state, Otherwise, the WTP enters the CAPWAP reset state, resulting in
resulting in shutdown of the DTLS session. shutdown of the DTLS session.
If the WaitJoin Timer expires prior to reception of the Join Response If the WaitJoin Timer expires prior to reception of the Join Response
message, the WTP MUST terminate the handshake, deallocate associated message, the WTP MUST terminate the handshake, deallocate associated
session state and transition to the Discover state. session state and transition to the Discover state.
If an invalid (malformed) Join Response message is received, the WTP If an invalid (malformed) Join Response message is received, the WTP
SHOULD log an informative message detailing the error. This error SHOULD log an informative message detailing the error. This error
MUST be treated in the same manner as AC non-responsiveness. In this MUST be treated in the same manner as AC non-responsiveness. In this
way, the WaitJoin timer will eventually expire, in which case the WTP way, the WaitJoin timer will eventually expire, in which case the WTP
may (if it is so configured) attempt to join with an alternative AC. may (if it is so configured) attempt to join with an alternative AC.
The following message elements MAY be included in the Join Response The following message elements MAY be included in the Join Response
message. message.
o AC IPv4 List, see Section 4.4.2 o AC IPv4 List, see Section 4.4.2
o AC IPv6 List, see Section 4.4.3 o AC IPv6 List, see Section 4.4.3
o Result Code, see Section 4.4.28 o Result Code, see Section 4.4.31
o Session ID, see Section 4.4.29 o Session ID, see Section 4.4.32
The following message element MUST be included in the Join Response
message.
o AC Descriptor, see Section 4.4.1
7. Control Channel Management 7. Control Channel Management
The Control Channel Management messages are used by the WTP and AC to The Control Channel Management messages are used by the WTP and AC to
maintain a control communication channel. CAPWAP control messages, maintain a control communication channel. CAPWAP control messages,
such as the WTP Event Request message sent from the WTP to the AC such as the WTP Event Request message sent from the WTP to the AC
indicate to the AC that the WTP is operational. When such control indicate to the AC that the WTP is operational. When such control
messages are not being sent, the Echo Request and Echo Response messages are not being sent, the Echo Request and Echo Response
messages are used to maintain the control communication channel. messages are used to maintain the control communication channel.
skipping to change at page 87, line 45 skipping to change at page 88, line 45
Administrative State message Elements. There is one such message Administrative State message Elements. There is one such message
element for the WTP, and one message element per radio in the WTP. element for the WTP, and one message element per radio in the WTP.
The following message elements MUST be included in the Configuration The following message elements MUST be included in the Configuration
Status message. Status message.
o AC Name, see Section 4.4.4 o AC Name, see Section 4.4.4
o AC Name with Index, see Section 4.4.5 o AC Name with Index, see Section 4.4.5
o Radio Administrative State, see Section 4.4.27 o Radio Administrative State, see Section 4.4.29
o Statistics Timer, see Section 4.4.30
o WTP Board Data, see Section 4.4.32 o Statistics Timer, see Section 4.4.33
o WTP Radio Information, see Section 4.4.38 A WTP Radio Information o WTP Board Data, see Section 4.4.35
message element MUST be present for every radio in the WTP.
o WTP Reboot Statistics, see Section 4.4.44 o WTP Reboot Statistics, see Section 4.4.44
The following message elements MAY be included in the Configuration
Status message.
o WTP Static IP Address Information, see Section 4.4.45 o WTP Static IP Address Information, see Section 4.4.45
8.3. Configuration Status Response 8.3. Configuration Status Response
The Configuration Status Response message is sent by an AC and The Configuration Status Response message is sent by an AC and
provides a mechanism for the AC to override a WTP's requested provides a mechanism for the AC to override a WTP's requested
configuration. configuration.
Configuration Status Response messages are sent by an AC after Configuration Status Response messages are sent by an AC after
receiving a Configure Request message. receiving a Configure Request message.
The Configuration Status Response message carries binding specific The Configuration Status Response message carries binding specific
message elements. Refer to the appropriate binding for the message elements. Refer to the appropriate binding for the
definition of this structure. definition of this structure.
When a WTP receives a Configuration Status Response message it acts When a WTP receives a Configuration Status Response message it acts
upon the content of the message, as appropriate. If the upon the content of the message, as appropriate. If the
Configuration Status Response message includes a Radio Administrative Configuration Status Response message includes a Radio Operational
State message element that causes a change in the operational state State message element that causes a change in the operational state
of one of the Radio, the WTP will transmit a Change State Event to of one of the Radio, the WTP will transmit a Change State Event to
the AC, as an acknowledgement of the change in state. the AC, as an acknowledgement of the change in state.
The following message elements MUST be included in the Configuration The following message elements MUST be included in the Configuration
Status Response message. Status Response message.
o AC IPv4 List, see Section 4.4.2 o AC IPv4 List, see Section 4.4.2
o AC IPv6 List, see Section 4.4.3 o AC IPv6 List, see Section 4.4.3
o CAPWAP Timers, see Section 4.4.10 o CAPWAP Timers, see Section 4.4.12
o Radio Administrative Event, see Section 4.4.27 o Radio Operational Event, see Section 4.4.30
o Decryption Error Report Period, see Section 4.4.14 o Decryption Error Report Period, see Section 4.4.16
o Idle Timeout, see Section 4.4.21 o Idle Timeout, see Section 4.4.23
o WTP Fallback, see Section 4.4.34 o WTP Fallback, see Section 4.4.37
8.4. Configuration Update Request 8.4. Configuration Update Request
Configuration Update Request messages are sent by the AC to provision Configuration Update Request messages are sent by the AC to provision
the WTP while in the Run state. This is used to modify the the WTP while in the Run state. This is used to modify the
configuration of the WTP while it is operational. configuration of the WTP while it is operational.
When an AC receives a Configuration Update Request message it will When an AC receives a Configuration Update Request message it will
respond with a Configuration Update Response message, with the respond with a Configuration Update Response message, with the
appropriate Result Code. appropriate Result Code.
skipping to change at page 89, line 18 skipping to change at page 90, line 20
Configuration Update message. Configuration Update message.
o AC Name with Index, see Section 4.4.5 o AC Name with Index, see Section 4.4.5
o AC Timestamp, see Section 4.4.6 o AC Timestamp, see Section 4.4.6
o Add MAC ACL Entry, see Section 4.4.7 o Add MAC ACL Entry, see Section 4.4.7
o Add Static MAC ACL Entry, see Section 4.4.9 o Add Static MAC ACL Entry, see Section 4.4.9
o CAPWAP Timers, see Section 4.4.10 o CAPWAP Timers, see Section 4.4.12
o Decryption Error Report Period, see Section 4.4.14 o Decryption Error Report Period, see Section 4.4.16
o Delete MAC ACL Entry, see Section 4.4.15 o Delete MAC ACL Entry, see Section 4.4.17
o Delete Static MAC ACL Entry, see Section 4.4.17 o Delete Static MAC ACL Entry, see Section 4.4.19
o Idle Timeout, see Section 4.4.21 o Idle Timeout, see Section 4.4.23
o Location Data, see Section 4.4.25 o Location Data, see Section 4.4.27
o Radio Administrative State, see Section 4.4.27 o Radio Operational State, see Section 4.4.30
o Statistics Timer, see Section 4.4.30 o Statistics Timer, see Section 4.4.33
o WTP Fallback, see Section 4.4.34 o WTP Fallback, see Section 4.4.37
o WTP Name, see Section 4.4.41 o WTP Name, see Section 4.4.41
8.5. Configuration Update Response 8.5. Configuration Update Response
The Configuration Update Response message is the acknowledgement The Configuration Update Response message is the acknowledgement
message for the Configuration Update Request message. message for the Configuration Update Request message.
The Configuration Update Response message is sent by a WTP after The Configuration Update Response message is sent by a WTP after
receiving a Configuration Update Request message. receiving a Configuration Update Request message.
When an AC receives a Configuration Update Response message the When an AC receives a Configuration Update Response message the
result code indicates if the WTP successfully accepted the result code indicates if the WTP successfully accepted the
configuration. configuration.
The following message element MUST be present in the Configuration The following message element MUST be present in the Configuration
Update message. Update message.
Result Code, see Section 4.4.28 Result Code, see Section 4.4.31
8.6. Change State Event Request 8.6. Change State Event Request
The Change State Event Request message is used by the WTP to inform The Change State Event Request message is used by the WTP to inform
the AC of a change in the operational state. the AC of a change in the one of the WTP radio's operational state.
The Change State Event Request message is sent by the WTP when it The Change State Event Request message MUST sent by the WTP when it
receives a Configuration Response message that includes a Change receives a Configuration Response message that includes a Radio
State Event message element. It is also sent when the WTP detects an Operational State message element. It is also sent when the WTP
operational failure with a radio. The Change State Event Request detects an operational failure with a radio. The Change State Event
message may be sent in either the Configure or Run state (see Request message may be sent in either the Configure or Run state (see
Section 2.3. Section 2.3.
When an AC receives a Change State Event Request message it will When an AC receives a Change State Event Request message it will
respond with a Change State Event Response message and make any respond with a Change State Event Response message and make any
necessary modifications to internal WTP data structures. necessary modifications to internal WTP data structures.
The following message elements MUST be present in the Change State The following message elements MUST be present in the Change State
Event Request message. Event Request message.
o Radio Administrative State message element, see Section 4.4.27 o Radio Operational State message element, see Section 4.4.30
8.7. Change State Event Response 8.7. Change State Event Response
The Change State Event Response message acknowledges the Change State The Change State Event Response message acknowledges the Change State
Event Request message. Event Request message.
A Change State Event Response message is sent by an AC in response to A Change State Event Response message is sent by an AC in response to
a Change State Event Request message. a Change State Event Request message.
The Change State Event Response message carries no message elements. The Change State Event Response message carries no message elements.
skipping to change at page 91, line 18 skipping to change at page 92, line 19
its configuration to the manufacturing default configuration. its configuration to the manufacturing default configuration.
8.9. Clear Configuration Response 8.9. Clear Configuration Response
The Clear Configuration Response message is sent by the WTP after The Clear Configuration Response message is sent by the WTP after
receiving a Clear Configuration Request message and resetting its receiving a Clear Configuration Request message and resetting its
configuration parameters back to the manufacturing default values. configuration parameters back to the manufacturing default values.
The Clear Configuration Request message carries the message elements. The Clear Configuration Request message carries the message elements.
o Result Code, see Section 4.4.28 o Result Code, see Section 4.4.31
9. Device Management Operations 9. Device Management Operations
This section defines CAPWAP operations responsible for debugging, This section defines CAPWAP operations responsible for debugging,
gathering statistics, logging, and firmware management. gathering statistics, logging, and firmware management.
9.1. Image Data Request 9.1. Image Data Request
The Image Data Request message is used to update firmware on the WTP. The Image Data Request message is used to update firmware on the WTP.
This message and its companion response message are used by the AC to This message and its companion response message are used by the AC to
skipping to change at page 92, line 47 skipping to change at page 93, line 47
Regardless of how the download was initiated, once the AC receives an Regardless of how the download was initiated, once the AC receives an
Image Data Request with the Image Filename message element, it begins Image Data Request with the Image Filename message element, it begins
the transfer process by transmitting its own request with the Image the transfer process by transmitting its own request with the Image
Data message element. This continues until the whole firmware image Data message element. This continues until the whole firmware image
has been transfered. has been transfered.
The following message elements MAY be included in the Image Data The following message elements MAY be included in the Image Data
Request Message. Request Message.
o Image Data, see Section 4.4.22 o Image Data, see Section 4.4.24
o Image Filename, see Section 4.4.23 o Image Filename, see Section 4.4.25
o Initiate Download, see Section 4.4.24 o Initiate Download, see Section 4.4.26
9.2. Image Data Response 9.2. Image Data Response
The Image Data Response message acknowledges the Image Data Request The Image Data Response message acknowledges the Image Data Request
message. message.
An Image Data Response message is sent in response to a received An Image Data Response message is sent in response to a received
Image Data Request message. Its purpose is to acknowledge the Image Data Request message. Its purpose is to acknowledge the
receipt of the Image Data Request message. receipt of the Image Data Request message.
skipping to change at page 93, line 28 skipping to change at page 94, line 28
9.3. Reset Request 9.3. Reset Request
The Reset Request message is used to cause a WTP to reboot. The Reset Request message is used to cause a WTP to reboot.
A Reset Request message is sent by an AC to cause a WTP to A Reset Request message is sent by an AC to cause a WTP to
reinitialize its operation. reinitialize its operation.
The Reset Request carries no message elements. The Reset Request carries no message elements.
When a WTP receives a Reset Request it will respond with a Reset When a WTP receives a Reset Request it will respond with a Reset
Response and then reinitialize itself. Response indicating success and then reinitialize itself. In the
event the WTP is unable to reset, including a hardware reset, it can
respond with a Reset Response whose Result-Code message element
indicates failure.
9.4. Reset Response 9.4. Reset Response
The Reset Response message acknowledges the Reset Request message. The Reset Response message acknowledges the Reset Request message.
A Reset Response message is sent by the WTP after receiving a Reset A Reset Response message is sent by the WTP after receiving a Reset
Request message. Request message.
The Reset Response message carries no message elements. Its purpose The following message elements MAY be included in the Image Data
is to acknowledge the receipt of the Reset Request message. Request Message.
When an AC receives a Reset Response message, it is notified that the o Result Code, see Section 4.4.31
WTP will reinitialize its operation.
When an AC receives a successful Reset Response message, it is
notified that the WTP will reinitialize its operation. An AC that
receives a Reset Response indicating failure may opt to no longer
provide service to the WTP in question.
9.5. WTP Event Request 9.5. WTP Event Request
WTP Event Request message is used by a WTP to send information to its WTP Event Request message is used by a WTP to send information to its
AC. The WTP Event Request message may be sent periodically, or sent AC. The WTP Event Request message may be sent periodically, or sent
in response to an asynchronous event on the WTP. For example, a WTP in response to an asynchronous event on the WTP. For example, a WTP
MAY collect statistics and use the WTP Event Request message to MAY collect statistics and use the WTP Event Request message to
transmit the statistics to the AC. transmit the statistics to the AC.
When an AC receives a WTP Event Request message it will respond with When an AC receives a WTP Event Request message it will respond with
a WTP Event Response message. a WTP Event Response message.
The WTP Event Request message MUST contain one of the message The WTP Event Request message MUST contain one of the message
elements listed below, or a message element that is defined for a elements listed below, or a message element that is defined for a
specific wireless technology. specific wireless technology.
o Decryption Error Report, see Section 4.4.13 o Decryption Error Report, see Section 4.4.15
o Duplicate IPv4 Address, see Section 4.4.19 o Duplicate IPv4 Address, see Section 4.4.21
o Duplicate IPv6 Address, see Section 4.4.20 o Duplicate IPv6 Address, see Section 4.4.22
o WTP Operational Statistics, see Section 4.4.42 o WTP Operational Statistics, see Section 4.4.42
o WTP Radio Statistics, see Section 4.4.43 o WTP Radio Statistics, see Section 4.4.43
o WTP Reboot Statistics, see Section 4.4.44 o WTP Reboot Statistics, see Section 4.4.44
9.6. WTP Event Response 9.6. WTP Event Response
The WTP Event Response message acknowledges receipt of the WTP Event The WTP Event Response message acknowledges receipt of the WTP Event
skipping to change at page 94, line 50 skipping to change at page 96, line 12
debugger function in the WTP also uses the Data Transfer Request debugger function in the WTP also uses the Data Transfer Request
message to send console output to the AC for debugging purposes. message to send console output to the AC for debugging purposes.
When the AC receives a Data Transfer Request message it responds to When the AC receives a Data Transfer Request message it responds to
the WTP ith a Data Transfer Response message. The AC MAY log the the WTP ith a Data Transfer Response message. The AC MAY log the
information received. information received.
The Data Transfer Request message MUST contain one of the message The Data Transfer Request message MUST contain one of the message
elements listed below. elements listed below.
o Data Transfer Data, see Section 4.4.11 o Data Transfer Data, see Section 4.4.13
o Data Transfer Mode, see Section 4.4.12
o Data Transfer Mode, see Section 4.4.14
9.8. Data Transfer Response 9.8. Data Transfer Response
The Data Transfer Response message acknowledges the Data Transfer The Data Transfer Response message acknowledges the Data Transfer
Request message. Request message.
A Data Transfer Response message is sent in response to a received A Data Transfer Response message is sent in response to a received
Data Transfer Request message. Its purpose is to acknowledge receipt Data Transfer Request message. Its purpose is to acknowledge receipt
of the Data Transfer Request message. of the Data Transfer Request message.
The Data Transfer Response message carries no message elements. The Data Transfer Response message carries no message elements.
Upon receipt of a Data Transfer Response message, the WTP transmits Upon receipt of a Data Transfer Response message, the WTP transmits
more information, if more information is available. more information, if more information is available.
10. Mobile Session Management 10. Station Session Management
Messages in this section are used by the AC to create, modify or Messages in this section are used by the AC to create, modify or
delete mobile station session state on the WTPs. delete station session state on the WTPs.
10.1. Mobile Configuration Request 10.1. Station Configuration Request
The Mobile Configuration Request message is used to create, modify or The Station Configuration Request message is used to create, modify
delete mobile session state on a WTP. The message is sent by the AC or delete station session state on a WTP. The message is sent by the
to the WTP, and may contain one or more message elements. The AC to the WTP, and may contain one or more message elements. The
message elements for this CAPWAP control message include information message elements for this CAPWAP control message include information
that is generally highly technology specific. Refer to the that is generally highly technology specific. Refer to the
appropriate binding section or document for the definitions of the appropriate binding section or document for the definitions of the
messages elements that may be used in this control message. messages elements that may be used in this control message.
The following CAPWAP Control message elements MAY be included in the The following CAPWAP Control message elements MAY be included in the
Mobile Configuration Request message. Station Configuration Request message.
o Add Mobile Station, see Section 4.4.8 o Add Station, see Section 4.4.8
o Delete Mobile Station, see Section 4.4.16 o Delete Station, see Section 4.4.18
10.2. Mobile Configuration Response 10.2. Station Configuration Response
The Mobile Configuration Response message is used to acknowledge a The Station Configuration Response message is used to acknowledge a
previously received Mobile Configuration Request message. The previously received Station Configuration Request message. The
following message element MUST be present in the Mobile Configuration following message element MUST be present in the Station
Response message. Configuration Response message.
o Result Code, see Section 4.4.28 o Result Code, see Section 4.4.31
The Result Code message element indicates that the requested The Result Code message element indicates that the requested
configuration was successfully applied, or that an error related to configuration was successfully applied, or that an error related to
processing of the Mobile Configuration Request message occurred on processing of the Station Configuration Request message occurred on
the WTP. the WTP.
11. IEEE 802.11 Binding 11. NAT Considerations
This section defines the extensions required for the CAPWAP protocol
to be used with the IEEE 802.11 protocol.
11.1. Split MAC and Local MAC Functionality
The CAPWAP protocol, when used with IEEE 802.11 devices, requires a
specific behavior from the WTP and the AC, to support the required
IEEE 802.11 protocol functions.
For both the Split and Local MAC approaches, the CAPWAP functions, as
defined in the taxonomy specification [Add reference], reside in the
AC.
11.1.1. Split MAC
This section shows the division of labor between the WTP and the AC
in a Split MAC architecture. Figure 4 shows the clear separation of
functionality among CAPWAP components.
Function Location
Distribution Service AC
Integration Service AC
Beacon Generation WTP
Probe Response Generation WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP/AC
Assoc/Disassoc/Reassoc AC
802.11e
Classifying AC
Scheduling WTP/AC
Queuing WTP
802.11i
802.1X/EAP AC
RSNA Key Management AC
802.11 Encryption/Decryption WTP/AC
Figure 4: Mapping of 802.11 Functions for Split MAC Architecture
The Distribution and Integration services reside on the AC, and
therefore all user data is tunneled between the WTP and the AC. As
noted above, all real-time IEEE 802.11 services, including the beacon
and probe response frames, are handled on the WTP.
All remaining IEEE 802.11 MAC management frames are supported on the
AC, including the Association Request which allows the AC to be
involved in the access policy enforcement portion of the IEEE 802.11
protocol. The IEEE 802.1X and IEEE 802.11i key management function
are also located on the AC. This implies that the AAA client also
resides on the AC.
While the admission control component of IEEE 802.11e resides on the
AC, the real time scheduling and queuing functions are on the WTP.
Note this does not exclude the AC from providing additional policing
and scheduling functionality.
Note that in the following figure, the use of '( - )' indicates that
processing of the frames is done on the WTP.
Client WTP AC
Beacon
<-----------------------------
Probe Request
----------------------------( - )------------------------->
Probe Response
<-----------------------------
802.11 AUTH/Association
<--------------------------------------------------------->
Mobile Config Request[Add Mobile (Clear Text, 802.1X)]
<------------------------->
802.1X Authentication & 802.11i Key Exchange
<--------------------------------------------------------->
Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)]
<------------------------->
802.11 Action Frames
<--------------------------------------------------------->
802.11 DATA (1)
<---------------------------( - )------------------------->
Figure 5: Split MAC Message Flow
Figure 5 provides an illustration of the division of labor in a Split
MAC architecture. In this example, a WLAN has been created that is
configured for IEEE 802.11i, using AES-CCMP for privacy. The
following process occurs:
o The WTP generates the IEEE 802.11 beacon frames, using information
provided to it through the Add WLAN (see Section Section 11.9.1)
message element.
o The WTP processes the probe request and responds with a
corresponding probe response. The probe request is then forwarded
to the AC for optional processing.
o The WTP forwards the IEEEE 802.11 Authentication and Association
frames to the AC, which is responsible for responding to the
client.
o Once the association is complete, the AC transmits an CAPWAP Add
Mobile Station request to the WTP (see Section Section 4.4.8. In
the above example, the WLAN is configured for IEEE 802.1X, and
therefore the '802.1X only' policy bit is enabled.
o If the WTP is providing encryption/decryption services, once the
client has completed the IEEE 802.11i key exchange, the AC
transmits another Add Mobile request to the WTP, stating the
security policy to enforce for the client (in this case AES-CCMP),
as well as the encryption key to use. If encryption/decryption is
handled in the AC, the IEEE 802.11 Add Mobile Station request
would not include the RSN Information Element.
o The WTP forwards any 802.11 Action frames received to the AC.
o All client data frames are tunneled between the WTP and the AC.
Note that the WTP is responsible for encrypting and decrypting
frames, if it was indicated in the Add Mobile request.
11.1.2. Local MAC
This section shows the division of labor between the WTP and the AC
in a Local MAC architecture. Figure 6 shows the clear separation of
functionality among CAPWAP components.
Function Location
Distribution Service WTP
Integration Service WTP
Beacon Generation WTP
Probe Response Generation WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc WTP
802.11e
Classifying WTP
Scheduling WTP
Queuing WTP
802.11i
802.1X/EAP AC
RSNA Key Management AC
802.11 Encryption/Decryption WTP
Figure 6: Mapping of 802.11 Functions for Local AP Architecture
Given the Distribution and Integration Services exist on the WTP,
client data frames are not forwarded to the AC, with the exception
listed in the following paragraphs.
While the MAC is terminated on the WTP, it is necessary for the AC to
be aware of mobility events within the WTPs. As a consequence, the
WTP MUST forward the IEEE 802.11 Association Requests to the AC. The
AC MAY reply with a failed Association Response if it deems it
necessary, and upon receipt of a failed Association Response from the
AC, the WTP must send a Disassociation frame to the mobile station.
The IEEE 802.1X and RSNA Key Management function resides in the AC.
Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management
frames to the AC and forward the associated responses to the station.
This implies that the AAA client also resides on the AC.
Note that in the following figure, the use of '( - )' indicates that
processing of the frames is done on the WTP.
Client WTP AC
Beacon
<-----------------------------
Probe
<---------------------------->
802.11 AUTH
<-----------------------------
802.11 Association
<---------------------------( - )------------------------->
Mobile Config Request[Add Mobile (Clear Text, 802.1X)]
<------------------------->
802.1X Authentication & 802.11i Key Exchange
<--------------------------------------------------------->
802.11 Action Frames
<--------------------------------------------------------->
Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)]
<------------------------->
802.11 DATA
<----------------------------->
Figure 7: Local MAC Message Flow
Figure 7 provides an illustration of the division of labor in a Local
MAC architecture. In this example, a WLAN has been created that is
configured for IEEE 802.11i, using AES-CCMP for privacy. The
following process occurs:
o The WTP generates the IEEE 802.11 beacon frames, using information
provided to it through the Add WLAN (see Section 11.9.1) message
element.
o The WTP processes the probe request and responds with a
corresponding probe response.
o The WTP forwards the IEEE 802.11 Authentication and Association
frames to the AC.
o Once the association is complete, the AC transmits an CAPWAP Add
Mobile Station message element to the WTP (see Section
Section 4.4.8. In the above example, the WLAN is configured for
IEEE 802.1X, and therefore the '802.1X only' policy bit is
enabled.
o The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange
messages to the AC for processing.
o The AC transmits another Add Mobile Station message element to the
WTP, stating the security policy to enforce for the client (in
this case AES-CCMP), as well as the encryption key to use. The
Add Mobile Station message element MAY include a VLAN name, which
when present is used by the WTP to identify the VLAN on which the
user's data frames are to be bridged.
o The WTP forwards any IEEE 802.11 Action frames received to the AC.
o The WTP may locally bridge client data frames (and provide the
necessary encryption and decryption services). The WTP may also
tunnel client data frames to the AC, using 802.3 frame tunnel mode
or 802.11 frame tunnel mode.
11.2. Roaming Behavior
It is important that CAPWAP implementations react properly to mobile
devices associating to the networks in how they generate Add Mobile
and Delete Mobile messages. This section expands upon the examples
provided in the previous section, and describes how the CAPWAP
control protocol is used in order to provide secure roaming.
Once a client has successfully associated with the network in a
secure fashion, it is likely to attempt to roam to another WTP.
Figure 8 shows an example of a currently associated station moving
from its "Old WTP" to a "new WTP". The figure is useful for multiple
different security policies, including IEEE 802.1X and dynamic WEP
keys, WPA or even WPA2 both with key caching (where the IEEE 802.1x
exchange would be bypassed) and without.
Client Old WTP WTP AC
Association Request/Response
<--------------------------------------( - )-------------->
Mobile Config Request[Add Mobile (Clear Text, 802.1X)]
<---------------->
802.1X Authentication (if no key cache entry exists)
<--------------------------------------( - )-------------->
802.11i 4-way Key Exchange
<--------------------------------------( - )-------------->
Mobile Config Request[Delete Mobile]
<---------------------------------->
Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)]
<---------------->
Figure 8: Client Roaming Example
11.3. Group Key Refresh
Periodically, the Group Key (GTK)for the BSS needs to be updated.
The AC uses an EAPoL frame to update the group key for each STA in
the BSS. While the AC is updating the GTK, each L2 broadcast frame
transmitted to the BSS needs to be duplicated and transmitted using
both the current GTK and the new GTK. Once the GTK update process
has completed, broadcast frames transmitted to the BSS will be
encrypted using the new GTK.
In the case of Split MAC, the AC needs to duplicate all broadcast
packets and update the key index so that the packet is transmitted
using both the current and new GTK to ensure that all STA's in the
BSS receive the broadcast frames. In the case of local MAC, the WTP
needs to duplicate and transmit broadcast frames using the
appropriate index to ensure that all STA's in the BSS continue to
receive broadcast frames.
The Group Key update procedure is given in the following figure. The
AC will signal the update to the GTK using an 802.11 Configuration
Request frame with the new GTK, its index, the TSC for the Group Key
and the Key Status set to 3 (begin GTK update). The AC will then
begin updating the GTK for each STA. During this time, the AC (for
Split MAC) or WTP (for Local MAC) must duplicate broadcast packets
and transmit them encrypted with both the current and new GTK. When
the AC has completed the GTK update to all STA's in the BSS, the AC
must transmit an 802.11 Configuration Request frame containing the
new GTK, its index, and the Key Status set to 4 (GTK update
complete).
Client WTP AC
802.11 Config Request ( Update WLAN (GTK, GTK Index, GTK Start, Group TSC) )
<----------------------------------------------
802.1X EAPoL (GTK Message 1)
<-------------( - )-------------------------------------------
802.1X EAPoL (GTK Message 2)
-------------( - )------------------------------------------->
802.11 Config Request ( Update WLAN (GTK Index, GTK Complete) )
<---------------------------------------------
Figure 9: Group Key Update Procedure
11.4. BSSID to WLAN ID Mapping
The CAPWAP protocol allows the WTP to assign BSSIDs upon creation of
a WLAN (see Section 11.9.1). While manufacturers are free to assign
BSSIDs using any arbitrary mechanism, it is advised that where
possible the BSSIDs are assigned as a contiguous block.
When assigned as a block, implementations can still assign any of the
available BSSIDs to any WLAN. One possible method is for the WTP to
assign the address using the following algorithm: base BSSID address
+ WLAN ID.
The WTP communicates the maximum number of BSSIDs that it supports
during the Config Request within the IEEE 802.11 WTP WLAN Radio
Configuration message element (see Section 11.9.23).
11.5. Quality of Service for IEEE 802.11 Control Messages
It is recommended that IEEE 802.11 MAC management frames be sent by
both the AC and the WTP with appropriate Quality of Service values,
ensuring that congestion in the network minimizes occurrences of
packet loss. Therefore, a Quality of Service enabled CAPWAP device
should use:
802.1P: The precedence value of 7 SHOULD be used for all IEEE 802.11
MAC management frames, except for Probe Requests which SHOULD use
4.
DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11
MAC management frames, except for Probe Requests which SHOULD use
34.
11.6. IEEE 802.11 Specific CAPWAP Control Messages
This section defines CAPWAP Control Messages that are specific to the
IEEE 802.11 binding. The two messages are defined, the IEEE 802.11
WLAN Config Request and IEEE 802.11 WLAN Config Response messages.
See Section 4.3.1.1
The valid message types for IEEE 802.11 specific control messages are
listed below. The IANA Enterprise number used with these messages is
13277.
CAPWAP Control Message Message Type
Value
IEEE 802.11 WLAN Configuration Request 3398912
IEEE 802.11 WLAN Configuration Response 3398913
11.6.1. IEEE 802.11 WLAN Configuration Request
The IEEE 802.11 WLAN Configuration Request is sent by the AC to the
WTP in order to change services provided by the WTP. This control
message is used to either create, update or delete a WLAN on the WTP.
The IEEE 802.11 WLAN Configuration Request is sent as a result of
either some manual admistrative process (e.g., deleting a WLAN), or
automatically to create a WLAN on a WTP. When sent automatically to
create a WLAN, this control message is sent after the CAPWAP
Configure Update Request message has been received by the WTP.
Upon receiving this control message, the WTP will modify the
necessary services, and transmit an IEEE 802.11 WLAN Configuration
Response.
A WTP MAY provide service for more than one WLAN, therefore every
WLAN is identified through a numerical index. For instance, a WTP
that is capable of supporting up to 16 SSIDs, could accept up to 16
IEEE 802.11 WLAN Configuration Request messages that include the Add
WLAN message element.
Since the index is the primary identifier for a WLAN, an AC MAY
attempt to ensure that the same WLAN is identified through the same
index number on all of its WTPs. An AC that does not follow this
approach MUST find some other means of maintaining a WLAN Identifier
to SSID mapping table.
The following message elements may be included in the IEEE 802.11
WLAN Configuration Request message. Only one message element MUST be
present.
o IEEE 802.11 Add WLAN, see Section 11.9.1
o IEEE 802.11 Delete WLAN, see Section 11.9.4
o IEEE 802.11 Information Element, see Section 11.9.6
o IEEE 802.11 Update WLAN, see Section 11.9.21
11.6.2. IEEE 802.11 WLAN Configuration Response
The IEEE 802.11 WLAN Configuration Response message is sent by the
WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11
WLAN Configuration Request message, and to indicate if the requested
configuration was successfully applied, or if an error related to the
processing of the IEEE 802.11 WLAN Configuration Request message
occurred on the WTP.
The following message element MAY be included in the IEEE 802.11 WLAN
Configuration Response message.
o IEEE 802.11 Assigned WTP BSSID, see Section 11.9.3
The following message element MUST be included in the IEEE 802.11
WLAN Configuration Response message. Only one message element MUST
be present.
o Result Code, see Section 4.4.28
11.7. CAPWAP Data Message Bindings
This section describes the CAPWAP Data Message bindings to support
IEEE 802.11 frames.
Payload encapsulation: The CAPWAP protocol defines the CAPWAP data
message, which is used to encapsulate a wireless payload. For
IEEE 802.11, the IEEE 802.11 header and payload are encapsulated
(excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS
checksum is handled by the WTP. This allows the WTP to validate
an IEEE 802.11 frame prior to sending it to the AC. Similarly,
when an AC wishes to transmit a frame towards a station, the WTP
computes and adds the FCS checksum.
Optional Wireless Specific Information: The optional CAPWAP header
field (see Section 4.1) is only used with CAPWAP data messages,
and it serves two purposes, depending upon the direction of the
message. For messages from the WTP to the AC, the field uses the
format described in the "IEEE 802.11 Frame Info" field (see
below). However, for messages sent by the AC to the WTP, the
format used is described in described in the "Destination WLANs"
field (also defined below).
IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a
station over the air, it is encapsulated and this field is used to
include radio and PHY specific information associated with the
frame.
The IEEE 802.11 Frame Info field has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSSI | SNR | Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSSI: RSSI is a signed, 8-bit value. It is the received signal
strength indication, in dBm.
SNR: SNR is a signed, 8-bit value. It is the signal to noise
ratio of the received IEEE 802.11 frame, in dB.
Data Rate: The data rate field is a 16 bit unsigned value. The
contents of the field is set to 1/10th of the data rate of the
packet received by the WTP. For instance, a packet received at
5.5Mbps would be set to 55, while 11Mbps would be set to 110.
Destination WLANs The Destination WLAN field is used to specify the
target WLANs for a given frame, and is only used with broadcast
and multicast frames. This field allows the AC to transmit a
single broadcast or multicast frame to the WTP, and allows the WTP
to perform the necessary frame replication services. The field
uses the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WLAN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
WLAN: This bit field indicates the WLAN ID (see section
Section 11.9.1) which the WTP will transmit the associated
frame on. For instance, if a multicast packet is to be
transmitted on WLANs 1 and 3, bits 1 and 3 of this field would
be enabled. Note this field is to be set to zero for unicast
packets and is unused if the WTP is not providing encryption
services.
Reserved: This field MUST be set to zero.
11.8. CAPWAP Control Message bindings
This section describes the IEEE 802.11 specific message elements
included in CAPWAP Control Messages.
11.8.1. Configuration Status Message
The following IEEE 802.11 specific message elements may be included
in the CAPWAP Configuration Status Message.
o IEEE 802.11 Antenna, see Section 11.9.2
o IEEE 802.11 Direct Sequence Control, see Section 11.9.5
o IEEE 802.11 MAC Operation, see Section 11.9.7
o IEEE 802.11 Multi Domain Capability, see Section 11.9.11
o IEEE 802.11 OFDM Control, see Section 11.9.12
o IEEE 802.11 Supported Rates, see Section 11.9.17
o IEEE 802.11 Tx Power, see Section 11.9.18
o IEEE 802.11 TX Power Level, see Section 11.9.19
o IEEE 802.11 WTP Radio Configuration, see Section 11.9.23
11.8.2. Configuration Status Response Message
The following IEEE 802.11 specific message elements may be included
in the CAPWAP Configuration Status Response Message.
o IEEE 802.11 Antenna, see Section 11.9.2
o IEEE 802.11 Direct Sequence Control, see Section 11.9.5
o IEEE 802.11 MAC Operation, see Section 11.9.7
o IEEE 802.11 Multi Domain Capability, see Section 11.9.11
o IEEE 802.11 OFDM Control, see Section 11.9.12
o IEEE 802.11 Rate Set, see Section 11.9.13
o IEEE 802.11 Supported Rates, see Section 11.9.17
o IEEE 802.11 Tx Power, see Section 11.9.18
o IEEE 802.11 WTP Quality of Service, see Section 11.9.22
o IEEE 802.11 WTP Radio Configuration, see Section 11.9.23
11.8.3. Configuration Update Request Message
The following IEEE 802.11 specific message elements may be included
in the CAPWAP Configuration Update Request Message.
o IEEE 802.11 Antenna, see Section 11.9.2
o IEEE 802.11 Direct Sequence Control, see Section 11.9.5
o IEEE 802.11 MAC Operation, see Section 11.9.7
o IEEE 802.11 Multi Domain Capability, see Section 11.9.11
o IEEE 802.11 OFDM Control, see Section 11.9.12
o IEEE 802.11 Rate Set, see Section 11.9.13
o IEEE 802.11 RSNA Error Report From Mobile, see Section 11.9.14
o IEEE 802.11 Tx Power, see Section 11.9.18
o IEEE 802.11 WTP Quality of Service, see Section 11.9.22
o IEEE 802.11 WTP Radio Configuration, see Section 11.9.23
11.8.4. Mobile Config Request
The following IEEE 802.11 specific message elements MAY included in
the CAPWAP Mobile Config Request message.
o IEEE 802.11 Mobile, see Section 11.9.9
o IEEE 802.11 Mobile Session Key, see Section 11.9.10
o Station QoS Profile, see Section 11.9.15
11.8.5. WTP Event Request
The following IEEE 802.11 specific message elements may be included
in the CAPWAP WTP Event Request message.
o IEEE 802.11 MIC Countermeasures, see Section 11.9.8
o IEEE 802.11 Statistics, see Section 11.9.16
o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 11.9.24
11.9. IEEE 802.11 Message Element Definitions
The following IEEE 802.11 specific message elements are defined in
this section.
IEEE 802.11 Message Element Type Value
IEEE 802.11 Add WLAN 1024
IEEE 802.11 Antenna 1025
IEEE 802.11 Assigned WTP BSSID 1026
IEEE 802.11 Delete WLAN 1027
IEEE 802.11 Direct Sequence Control 1028
IEEE 802.11 Information Element 1029
IEEE 802.11 MAC Operation 1030
IEEE 802.11 MIC Countermeasures 1031
IEEE 802.11 Mobile 1032
IEEE 802.11 Mobile Session Key 1033
IEEE 802.11 Multi-Domain Capability 1034
IEEE 802.11 OFDM Control 1035
IEEE 802.11 Rate Set 1036
IEEE 802.11 RSNA Error Report From Mobile 1037
IEEE 802.11 Station QoS Profile 1038
IEEE 802.11 Statistics 1039
IEEE 802.11 Supported Rates 1040
IEEE 802.11 Tx Power 1041
IEEE 802.11 Tx Power Level 1042
IEEE 802.11 Update Mobile QoS 1043
IEEE 802.11 Update WLAN 1044
IEEE 802.11 WTP Quality of Service 1045
IEEE 802.11 WTP Radio Configuration 1046
IEEE 802.11 WTP Radio Fail Alarm Indication 1047
11.9.1. IEEE 802.11 Add WLAN
The Add WLAN message element is used by the AC to define a wireless
LAN on the WTP. The inclusion of this message element MUST also
include IEEE 802.11 Information Element message elements, containing
the following 802.11 IEs:
Power Capability information element
WPA information element
RSN information element
EDCA Parameter Set information element
QoS Capability information element
WMM information element
If present, the RSN information element is sent along with the IEEE
802.11 Add WLAN in order to instruct the WTP on the usage of the Key
field.
Note that ACs MAY include additional information elements as they see
fit. The message element uses the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Key Status | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group TSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group TSC | QoS | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Mode | Tunnel Mode | Suppress SSID | SSID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1024 for IEEE 802.11 Add WLAN
Length: >= 49
Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier.
Capability: A 16-bit value containing the capabilities information
field to be advertised by the WTP within the Probe and Beacon
messages.
Key-Index: The Key Index associated with the key.
Key Status: A 1 byte value that specifies the state and usage of the
key that has been included. The following values describe the key
usage and its status:
0 - A value of zero, with the inclusion of the RSN Information
Element means that the WLAN uses per-station encryption keys, and
therefore the key in the 'Key' field is only used for multicast
traffic.
1 - When set to one, the WLAN employs a shared WEP key, also known as
a static WEP key, and uses the encryption key for both unicast and
multicast traffic for all stations.
2 - The value of 2 indicates that the AC will begin rekeying the GTK
with the STA's in the BSS. It is only valid when IEEE 802.11i is
enabled as the security policy for the BSS.
3 - The value of 3 indicates that the AC has completed rekeying the
GTK and broadcast packets no longer need to be duplicated and
transmitted with both GTK's.
Key Length: A 16-bit value representing the length of the Key field.
Key: A 32 byte Session Key to use to provide data privacy. For
static WEP keys, which is true when the 'Key Status' bit is set to
one, this key is used for both unicast and multicast traffic. For
encryption schemes that employ a separate encryption key for
unicast and multicast traffic, the key included hereonly applies
to multicast data, and the cipher suite is specified in an
accompanied RSN Information Element. In these scenarios, the key,
and cipher information, is communicated via the Add Mobile Station
(Section 4.4.8).
Group TSC A 48-bit value containing the Transmit Sequence Counter
for the updated group key. The WTP will set the TSC for
broadcast/multicast frames to this value for the updated group
key.
QOS: An 8-bit value specifying the default QoS policy to enforce for
station's traffic on this WLAN.
The following values are supported:
0 - Best Effort
1 - Video
2 - Voice
3 - Background
Auth Type: An 8-bit value specifying the supported authentication
type.
The following values are supported:
0 - Open System
1 - WEP Shared Key
2 - WPA/WPA2 802.1X
3 - WPA/WPA2 PSK
MAC Mode: This field specifies whether the WTP should support the
WLAN in Local or Split MAC modes. Note that the AC MUST NOT
request a mode of operation that was not advertised by the WTP
during the discovery process (see section Section 4.4.37). The
following values are supported:
0 - Local-MAC: Service for the WLAN is to be provided in Local
MAC mode.
1 - Split-MAC: Service for the WLAN is to be provided in Split
MAC mode.
Tunnel Mode: This field specifies the frame tunneling type to be
used for user traffic from all stations associated with the WLAN.
The AC MUST NOT request a mode of operation that was not
advertised by the WTP during the discovery process (see section
Section 4.4.35). IEEE 802.11 managment and control frames SHALL
be tunneled using 802.11 Tunnel mode. The following values are
supported:
0 - Local Bridging: All user traffic is to be locally bridged.
1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC in
802.3 format (see section Section 4.2).
2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC
in 802.11 format.
Supress SSID: A boolean indicating whether the SSID is to be
advertised by the WTP. A value of zero supresses the SSID in the
802.11 Beacon and Probe Response frames, while a value of one will
cause the WTP to populate the field.
SSID: The SSID attribute is the service set identifier that will be
advertised by the WTP for this WLAN.
11.9.2. IEEE 802.11 Antenna
The antenna message element is communicated by the WTP to the AC to
provide information on the antennas available. The AC MAY use this
element to reconfigure the WTP's antennas. The value contains the
following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Diversity | Combiner | Antenna Cnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna Selection [0..N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1025 for IEEE 802.11 Antenna
Length: >= 5
Radio ID: An 8-bit value representing the radio to configure.
Diversity: An 8-bit value specifying whether the antenna is to
provide receive diversity. The value of this field is the same as
the IEEE 802.11 dot11DiversitySelectionRx MIB element (see [6]).
The following values are supported:
0 - Disabled
1 - Enabled (may only be true if the antenna can be used as a
receive antenna)
Combiner: An 8-bit value specifying the combiner selection. The
following values are supported:
1 - Sectorized (Left)
2 - Sectorized (Right)
3 - Omni
4 - MIMO
Antenna Count: An 8-bit value specifying the number of Antenna
Selection fields. This value should be the same as the one found
in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [6]).
Antenna Selection: One 8-bit antenna configuration value per antenna
in the WTP. The following values are supported:
1 - Internal Antenna
2 - External Antenna
11.9.3. IEEE 802.11 Assigned WTP BSSID
The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when
the IEEE 802.11 WLAN Config Request included the IEEE 802.11 Add WLAN
message element. The value field of this message element contains
the BSSID that has been assigned by the WTP, which allows the WTP to
perform its own BSSID assignment.
The WTP is free to assign the BSSIDs the way it sees fit, but it is
highly recommended that the WTP assign the BSSID using the following
algorithm: BSSID = {base BSSID} + WLAN ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | BSSID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1026 for IEEE 802.11 Assigned WTP BSSID
Length: 6
Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier.
BSSID: The BSSID assigned by the WTP for the WLAN created as a
result of receiving an IEEE 802.11 Add WLAN.
11.9.4. IEEE 802.11 Delete WLAN
The delete WLAN message element is used to inform the WTP that a
previously created WLAN is to be deleted. The value contains the
following fields:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1027 for IEEE 802.11 Delete WLAN
Length: 3
Radio ID: An 8-bit value representing the radio
WLAN ID: An 8-bit value specifying the WLAN Identifier
11.9.5. IEEE 802.11 Direct Sequence Control
The direct sequence control message element is a bi-directional
element. When sent by the WTP, it contains the current state. When
sent by the AC, the WTP MUST adhere to the values. This element is
only used for 802.11b radios. The value has the following fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | Current Chan | Current CCA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Energy Detect Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1028 for IEEE 802.11 Direct Sequence Control
Length: 8
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
Current Channel: This attribute contains the current operating
frequency channel of the DSSS PHY. This value comes from the IEEE
802.11 dot11CurrentChannel MIB element (see [6]).
Current CCA: The current CCA method in operation, whose value can be
found in the IEEE 802.11 dot11CCAModeSupported MIB element (see
[6]). Valid values are:
1 - energy detect only (edonly)
2 - carrier sense only (csonly)
4 - carrier sense and energy detect (edandcs)
8 - carrier sense with timer (cswithtimer)
16 - high rate carrier sense and energy detect (hrcsanded)
Energy Detect Threshold: The current Energy Detect Threshold being
used by the DSSS PHY. The value can be found in the IEEE 802.11
dot11EDThreshold MIB element (see [6]).
11.9.6. IEEE 802.11 Information Element
The IEEE 802.11 Information Element is used to communicate any IE
defined in the IEEE 802.11 protocol. The data field contains the raw
IE as it would be included within an IEEE 802.11 MAC management
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |B|P| Flags |Info Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1029 for IEEE 802.11 Information Element
Length: >= 2
Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier.
B: When set, the WTP is to include the information element in
beacons associated with the WLAN.
P: When set, the WTP is to include the information element in probe
responses associated with the WLAN.
Flags: Reserved field and MUST be set to zero.
Info Element: The IEEE 802.11 Information Element, which includes
the type, length and value field.
11.9.7. IEEE 802.11 MAC Operation
The MAC operation message element is sent by the AC to set the 802.11
MAC parameters on the WTP. The value contains the following fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | RTS Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Short Retry | Long Retry | Fragmentation Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1030 for IEEE 802.11 MAC Operation
Length: 16
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
RTS Threshold: This attribute indicates the number of octets in an
MPDU, below which an RTS/CTS handshake MUST NOT be performed. An
RTS/CTS handshake MUST be performed at the beginning of any frame
exchange sequence where the MPDU is of type Data or Management,
the MPDU has an individual address in the Address1 field, and the
length of the MPDU is greater than this threshold. Setting this
attribute to be larger than the maximum MSDU size MUST have the
effect of turning off the RTS/CTS handshake for frames of Data or
Management type transmitted by this STA. Setting this attribute
to zero MUST have the effect of turning on the RTS/CTS handshake
for all frames of Data or Management type transmitted by this STA.
The default value of this attribute MUST be 2347. The value of
this field comes from the IEEE 802.11 dot11RTSThreshold MIB
element (see [6]).
Short Retry: This attribute indicates the maximum number of
transmission attempts of a frame, the length of which is less than
or equal to RTSThreshold, that MUST be made before a failure
condition is indicated. The default value of this attribute MUST
be 7. The value of this field comes from the IEEE 802.11
dot11ShortRetryLimit MIB element (see [6]).
Long Retry: This attribute indicates the maximum number of
transmission attempts of a frame, the length of which is greater
than dot11RTSThreshold, that MUST be made before a failure
condition is indicated. The default value of this attribute MUST
be 4. The value of this field comes from the IEEE 802.11
dot11LongRetryLimit MIB element (see [6]).
Fragmentation Threshold: This attribute specifies the current
maximum size, in octets, of the MPDU that MAY be delivered to the
PHY. An MSDU MUST be broken into fragments if its size exceeds
the value of this attribute after adding MAC headers and trailers.
An MSDU or MMPDU MUST be fragmented when the resulting frame has
an individual address in the Address1 field, and the length of the
frame is larger than this threshold. The default value for this
attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the
attached PHY and MUST never exceed the lesser of 2346 or the
aMPDUMaxLength of the attached PHY. The value of this attribute
MUST never be less than 256. The value of this field comes from
the IEEE 802.11 dot11FragmentationThreshold MIB element (see [6]).
Tx MSDU Lifetime: This attribute speficies the elapsed time in TU,
after the initial transmission of an MSDU, after which further
attempts to transmit the MSDU MUST be terminated. The default
value of this attribute MUST be 512. The value of this field
comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB
element (see [6]).
Rx MSDU Lifetime: This attribute specifies the elapsed time in TU,
after the initial reception of a fragmented MMPDU or MSDU, after
which further attempts to reassemble the MMPDU or MSDU MUST be
terminated. The default value MUST be 512. The value of this
field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB
element (see [6]).
11.9.8. IEEE 802.11 MIC Countermeasures
The MIC Countermeasures message element is sent by the WTP to the AC
to indicate the occurrence of a MIC failure. See the IEEE 802.11
dot11RSNATKIPCounterMeasuresInvoked MIB element (see [6]) for more
info.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1031 for IEEE 802.11 MIC Countermeasures
Length: 8
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier,
on which the MIC failure occurred.
MAC Address: The MAC Address of the mobile station that caused the
MIC failure.
11.9.9. IEEE 802.11 Mobile
The IEEE 802.11 Mobile message element accompanies the Add Mobile
message element, and is used to deliver IEEE 802.11 station policy
from the AC to the WTP.
The latest IEEE 802.11 Mobile message element overrides any
previously received message elements.
If the QoS field is set, the WTP MUST observe and provide policing of
the 802.11e priority tag to ensure that it does not exceed the value
provided by the AC.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities | WLAN ID |Supported Rates
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1032 for IEEE 802.11 Mobile
Length: >= 8
Radio ID: An 8-bit value representing the radio
Association ID: A 16-bit value specifying the IEEE 802.11
Association Identifier
Flags: The Flags field MUST be set to zero
Capabilities: A 16-bit field containing the IEEE 802.11 Capabilities
Information Field to use with the mobile.
WLAN ID: An 8-bit value specifying the WLAN Identifier
Supported Rates: The variable length field containing the supported
rates to be used with the mobile station, as found in the IEEE
802.11 dot11OperationalRateSet MIB element (see [6]).
11.9.10. IEEE 802.11 Mobile Session Key
The Mobile Session Key Payload message element is sent when the AC
determines that encryption of a mobile station must be performed in
the WTP. This message element MUST NOT be present without the IEEE
802.11 Mobile (see Section 11.9.9) message element, and MUST NOT be
sent if the WTP had not specifically advertised support for the
requested encryption scheme.
The RSN information element MUST sent along with the IEEE 802.11
Mobile Session Key in order to instruct the WTP on the usage of the
Key field. The AKM field of the RSM information element is used by
the WTP to identify the authentication protocol.
If the IEEE 802.11 Mobile Session Key message element's AKM-Only bit
is set, the WTP MUST drop all IEEE 802.11 packets that are not part
of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an
encryption key is in force, requiring that the AKM packets be
encrypted. Once the mobile station has successfully completed
authentication via the AKM, the AC must send a new Add Mobile message
element to remove the AKM-Only restriction, and optionally push the
session key down to the WTP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |A|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise TSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise TSC | Pairwise RSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise RSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-
Type: 1033 for IEEE 802.11 Mobile Session Key
Length: >= 25
MAC Address: The mobile station's MAC Address
Flags: A 16 bit field, whose unused bits MUST be set to zero. The
following bits are defined:
A: The one bit AKM-Only field is set by the AC to inform the WTP
that is MUST NOT accept any 802.11 data frames, other than AKM
frames. This is the equivalent of the WTP's IEEE 802.1X port
for the mobile station to be in the closed state. When set,
the WTP MUST drop any non-IEEE 802.1X packets it receives from
the mobile station.
C: The one bit field is set by the AC to inform the WTP that
encryption services will be provided by the AC. When set, the
WTP SHOULD police frames received from stations to ensure that
are properly encrypted as specified in the RSN Information
Element, but does not need to take specific cryptographic
action on the frame. Similarly, for transmitted frames, the
WTP only needs to forward already encrypted frames.
Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to
use for unicast packets transmitted to the mobile.
Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for
unicast packets received from the mobile.
Key: The key the WTP is to use when encrypting traffic to/from the
mobile station. For dynamically created keys, this is commonly
known as a Pairwise Transient Key (PTK).
11.9.11. IEEE 802.11 Multi-Domain Capability
The multi-domain capability message element is used by the AC to
inform the WTP of regulatory limits. The AC will transmit one
message element per frequency band to indicate the regulatory
constraints in that domain. The value contains the following fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | First Channel # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Channels | Max Tx Power Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1034 for IEEE 802.11 Multi-Domain Capability
Length: 8
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero
First Channnel #: This attribute indicates the value of the lowest
channel number in the subband for the associated domain country
string. The value of this field comes from the IEEE 802.11
dot11FirstChannelNumber MIB element (see [6]).