draft-ietf-capwap-protocol-specification-00.txt   draft-ietf-capwap-protocol-specification-01.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 28, 2006 M. Montemurro, Editor Expires: November 6, 2006 M. Montemurro, Editor
Chantry Networks Chantry Networks
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
February 24, 2006 May 5, 2006
CAPWAP Protocol Specification CAPWAP Protocol Specification
draft-ietf-capwap-protocol-specification-00 draft-ietf-capwap-protocol-specification-01
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 August 28, 2006. This Internet-Draft will expire on November 6, 2006.
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 Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized autonomous access points to systems consisting of a centralized
controller and Wireless Termination Points (WTPs). The general goal controller and Wireless Termination Points (WTPs). The general goal
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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, including an extension which supports the IEEE 802.11
wireless LAN protocol. Future extensions will enable support of wireless LAN protocol. Future extensions will enable support of
additional wireless technologies. additional wireless technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Conventions used in this document . . . . . . . . . . . 8 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Contributing Authors . . . . . . . . . . . . . . . . . . 8 1.2. Conventions used in this document . . . . . . . . . . . 8
1.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 8
1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Wireless Binding Definition . . . . . . . . . . . . . . 12 2.1. Wireless Binding Definition . . . . . . . . . . . . . . 12
2.2. CAPWAP State Machine Definition . . . . . . . . . . . . 12 2.2. CAPWAP Session Establishment Overview . . . . . . . . . 12
2.3. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 21 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 14
2.3.1. DTLS Error Handling Requirements . . . . . . . . . . 21 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . 15
2.3.2. DTLS Cookie Exchange Failure . . . . . . . . . . . . 22 2.3.2. CAPWAP to DTLS Commands . . . . . . . . . . . . . . 22
2.3.3. DTLS Re-Assembly Failure . . . . . . . . . . . . . . 23 2.3.3. DTLS to CAPWAP Notifications . . . . . . . . . . . 23
3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 24 2.3.4. DTLS State Transitions . . . . . . . . . . . . . . 23
3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 24 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 26
3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 24 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . 27
3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 25 2.4.2. DTLS Error Handling . . . . . . . . . . . . . . . . 28
4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 26 2.4.3. DTLS Rehandshake Behavior . . . . . . . . . . . . . 29
4.1. CAPWAP Transport Header . . . . . . . . . . . . . . . . 27 2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . 32
4.1.1. VER Field . . . . . . . . . . . . . . . . . . . . . 27 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2. RID Field . . . . . . . . . . . . . . . . . . . . . 27 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 35
4.1.3. F Bit . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 35
4.1.4. L Bit . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 36
4.1.5. R Bit . . . . . . . . . . . . . . . . . . . . . . . 28 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 37
4.1.6. Fragment ID . . . . . . . . . . . . . . . . . . . . 28 4.1. CAPWAP Transport Header . . . . . . . . . . . . . . . . 38
4.1.7. Length . . . . . . . . . . . . . . . . . . . . . . . 28 4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 40
4.1.8. Status and WLANS . . . . . . . . . . . . . . . . . . 28 4.3. CAPWAP Control Messages . . . . . . . . . . . . . . . . 41
4.1.9. Payload . . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. Control Message Format . . . . . . . . . . . . . . 41
4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 28 4.3.2. Control Message Quality of Service . . . . . . . . 44
4.3. CAPWAP Control Messages Overview . . . . . . . . . . . . 29 4.4. CAPWAP Protocol Message Elements . . . . . . . . . . . . 44
4.3.1. Control Message Format . . . . . . . . . . . . . . . 29 4.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . 45
4.3.2. Message Element Format . . . . . . . . . . . . . . . 31 4.4.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . 46
4.3.3. Quality of Service . . . . . . . . . . . . . . . . . 32 4.4.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . 46
5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 33 4.4.4. AC Name . . . . . . . . . . . . . . . . . . . . . . 47
5.1. Discovery Request . . . . . . . . . . . . . . . . . . . 33 4.4.5. AC Name with Index . . . . . . . . . . . . . . . . 47
5.1.1. Discovery Type . . . . . . . . . . . . . . . . . . . 34 4.4.6. AC Timestamp . . . . . . . . . . . . . . . . . . . 48
5.1.2. WTP Descriptor . . . . . . . . . . . . . . . . . . . 34 4.4.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . 48
5.1.3. WTP Radio Information . . . . . . . . . . . . . . . 35 4.4.8. Add Mobile Station . . . . . . . . . . . . . . . . 49
5.1.4. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 36 4.4.9. Add Static MAC ACL Entry . . . . . . . . . . . . . 49
5.1.5. WTP Frame Type . . . . . . . . . . . . . . . . . . . 36 4.4.10. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 50
5.2. Discovery Response . . . . . . . . . . . . . . . . . . . 37 4.4.11. Change State Event . . . . . . . . . . . . . . . . 50
5.2.1. AC Address . . . . . . . . . . . . . . . . . . . . . 38 4.4.12. Data Transfer Data . . . . . . . . . . . . . . . . 51
5.2.2. AC Descriptor . . . . . . . . . . . . . . . . . . . 38 4.4.13. Data Transfer Mode . . . . . . . . . . . . . . . . 52
5.2.3. AC Name . . . . . . . . . . . . . . . . . . . . . . 39 4.4.14. Decryption Error Report . . . . . . . . . . . . . . 52
5.2.4. WTP Manager Control IPv4 Address . . . . . . . . . . 39 4.4.15. Decryption Error Report Period . . . . . . . . . . 53
5.2.5. WTP Manager Control IPv6 Address . . . . . . . . . . 40 4.4.16. Delete MAC ACL Entry . . . . . . . . . . . . . . . 53
5.3. Primary Discovery Request . . . . . . . . . . . . . . . 41 4.4.17. Delete Mobile Station . . . . . . . . . . . . . . . 54
5.3.1. Discovery Type . . . . . . . . . . . . . . . . . . . 41 4.4.18. Delete Static MAC ACL Entry . . . . . . . . . . . . 54
5.3.2. WTP Descriptor . . . . . . . . . . . . . . . . . . . 41 4.4.19. Discovery Type . . . . . . . . . . . . . . . . . . 55
5.3.3. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 41 4.4.20. Duplicate IPv4 Address . . . . . . . . . . . . . . 55
5.3.4. WTP Frame Type . . . . . . . . . . . . . . . . . . . 41 4.4.21. Duplicate IPv6 Address . . . . . . . . . . . . . . 56
5.3.5. WTP Radio Information . . . . . . . . . . . . . . . 41 4.4.22. Idle Timeout . . . . . . . . . . . . . . . . . . . 56
5.4. Primary Discovery Response . . . . . . . . . . . . . . . 41 4.4.23. Image Data . . . . . . . . . . . . . . . . . . . . 57
5.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . 42 4.4.24. Image Filename . . . . . . . . . . . . . . . . . . 57
5.4.2. AC Name . . . . . . . . . . . . . . . . . . . . . . 42 4.4.25. Initiate Download . . . . . . . . . . . . . . . . . 58
5.4.3. WTP Manager Control IPv4 Address . . . . . . . . . . 42 4.4.26. Location Data . . . . . . . . . . . . . . . . . . . 58
5.4.4. WTP Manager Control IPv6 Address . . . . . . . . . . 42 4.4.27. MTU Discovery Padding . . . . . . . . . . . . . . . 59
6. Control Channel Management . . . . . . . . . . . . . . . . . 43 4.4.28. Radio Administrative State . . . . . . . . . . . . 59
6.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 43 4.4.29. Result Code . . . . . . . . . . . . . . . . . . . . 60
6.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 43 4.4.30. Session ID . . . . . . . . . . . . . . . . . . . . 60
7. WTP Configuration Management . . . . . . . . . . . . . . . . 44 4.4.31. Statistics Timer . . . . . . . . . . . . . . . . . 61
7.1. Configuration Consistency . . . . . . . . . . . . . . . 44 4.4.32. Vendor Specific Payload . . . . . . . . . . . . . . 61
7.1.1. Configuration Flexibility . . . . . . . . . . . . . 45 4.4.33. WTP Board Data . . . . . . . . . . . . . . . . . . 62
7.2. Configure Request . . . . . . . . . . . . . . . . . . . 45 4.4.34. WTP Descriptor . . . . . . . . . . . . . . . . . . 63
7.2.1. Administrative State . . . . . . . . . . . . . . . . 45 4.4.35. WTP Fallback . . . . . . . . . . . . . . . . . . . 64
7.2.2. AC Name . . . . . . . . . . . . . . . . . . . . . . 46 4.4.36. WTP Frame Encapsulation Type . . . . . . . . . . . 65
7.2.3. AC Name with Index . . . . . . . . . . . . . . . . . 46 4.4.37. WTP IPv4 IP Address . . . . . . . . . . . . . . . . 66
7.2.4. WTP Board Data . . . . . . . . . . . . . . . . . . . 46 4.4.38. WTP MAC Type . . . . . . . . . . . . . . . . . . . 66
7.2.5. Statistics Timer . . . . . . . . . . . . . . . . . . 47 4.4.39. WTP Radio Information . . . . . . . . . . . . . . . 67
7.2.6. WTP Static IP Address Information . . . . . . . . . 48 4.4.40. WTP Manager Control IPv4 Address . . . . . . . . . 67
7.2.7. WTP Reboot Statistics . . . . . . . . . . . . . . . 49 4.4.41. WTP Manager Control IPv6 Address . . . . . . . . . 68
7.3. Configure Response . . . . . . . . . . . . . . . . . . . 50 4.4.42. WTP Name . . . . . . . . . . . . . . . . . . . . . 69
7.3.1. Decryption Error Report Period . . . . . . . . . . . 50 4.4.43. WTP Reboot Statistics . . . . . . . . . . . . . . . 69
7.3.2. Change State Event . . . . . . . . . . . . . . . . . 50 4.4.44. WTP Static IP Address Information . . . . . . . . . 70
7.3.3. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 51 4.5. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 71
7.3.4. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 52 4.5.1. DiscoveryInterval . . . . . . . . . . . . . . . . . 71
7.3.5. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 52 4.5.2. DTLSRehandshake . . . . . . . . . . . . . . . . . . 71
7.3.6. WTP Fallback . . . . . . . . . . . . . . . . . . . . 53 4.5.3. DTLSSessionDelete . . . . . . . . . . . . . . . . . 71
7.3.7. Idle Timeout . . . . . . . . . . . . . . . . . . . . 53 4.5.4. EchoInterval . . . . . . . . . . . . . . . . . . . 71
7.4. Configuration Update Request . . . . . . . . . . . . . . 54 4.5.5. KeyLifetime . . . . . . . . . . . . . . . . . . . . 71
7.4.1. WTP Name . . . . . . . . . . . . . . . . . . . . . . 54 4.5.6. MaxDiscoveryInterval . . . . . . . . . . . . . . . 72
7.4.2. Change State Event . . . . . . . . . . . . . . . . . 54 4.5.7. NeighborDeadInterval . . . . . . . . . . . . . . . 72
7.4.3. Administrative State . . . . . . . . . . . . . . . . 54 4.5.8. ResponseTimeout . . . . . . . . . . . . . . . . . . 72
7.4.4. Statistics Timer . . . . . . . . . . . . . . . . . . 55 4.5.9. RetransmitInterval . . . . . . . . . . . . . . . . 72
7.4.5. Location Data . . . . . . . . . . . . . . . . . . . 55 4.5.10. SilentInterval . . . . . . . . . . . . . . . . . . 72
7.4.6. Decryption Error Report Period . . . . . . . . . . . 55 4.5.11. WaitJoin . . . . . . . . . . . . . . . . . . . . . 72
7.4.7. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 55 4.6. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 73
7.4.8. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 55 4.6.1. DiscoveryCount . . . . . . . . . . . . . . . . . . 73
7.4.9. Add MAC ACL Entry . . . . . . . . . . . . . . . . . 55 4.6.2. MaxDiscoveries . . . . . . . . . . . . . . . . . . 73
7.4.10. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 56 4.6.3. MaxRetransmit . . . . . . . . . . . . . . . . . . . 73
7.4.11. Add Static MAC ACL Entry . . . . . . . . . . . . . . 56 4.6.4. RetransmitCount . . . . . . . . . . . . . . . . . . 73
7.4.12. Delete Static MAC ACL Entry . . . . . . . . . . . . 57 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 74
7.4.13. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 57 5.1. Discovery Request Message . . . . . . . . . . . . . . . 74
7.4.14. AC Name with Index . . . . . . . . . . . . . . . . . 57 5.2. Discovery Response Message . . . . . . . . . . . . . . . 75
7.4.15. WTP Fallback . . . . . . . . . . . . . . . . . . . . 58 5.3. Primary Discovery Request Message . . . . . . . . . . . 75
7.4.16. Idle Timeout . . . . . . . . . . . . . . . . . . . . 58 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 76
7.4.17. Timestamp . . . . . . . . . . . . . . . . . . . . . 58 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 77
7.5. Configuration Update Response . . . . . . . . . . . . . 58 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 77
7.5.1. Result Code . . . . . . . . . . . . . . . . . . . . 58 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 78
7.6. Change State Event Request . . . . . . . . . . . . . . . 59 7. Control Channel Management . . . . . . . . . . . . . . . . . 79
7.6.1. Change State Event . . . . . . . . . . . . . . . . . 59 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 79
7.7. Change State Event Response . . . . . . . . . . . . . . 59 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 79
7.8. Clear Config Indication . . . . . . . . . . . . . . . . 60 8. WTP Configuration Management . . . . . . . . . . . . . . . . 80
8. Device Management Operations . . . . . . . . . . . . . . . . 61 8.1. Configuration Consistency . . . . . . . . . . . . . . . 80
8.1. Image Data Request . . . . . . . . . . . . . . . . . . . 61 8.1.1. Configuration Flexibility . . . . . . . . . . . . . 81
8.1.1. Image Download . . . . . . . . . . . . . . . . . . . 61 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 81
8.1.2. Image Data . . . . . . . . . . . . . . . . . . . . . 61 8.3. Configuration Status Response . . . . . . . . . . . . . 82
8.2. Image Data Response . . . . . . . . . . . . . . . . . . 62 8.4. Configuration Update Request . . . . . . . . . . . . . . 82
8.3. Reset Request . . . . . . . . . . . . . . . . . . . . . 62 8.5. Configuration Update Response . . . . . . . . . . . . . 83
8.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 63 8.6. Change State Event Request . . . . . . . . . . . . . . . 84
8.5. WTP Event Request . . . . . . . . . . . . . . . . . . . 63 8.7. Change State Event Response . . . . . . . . . . . . . . 84
8.5.1. Decryption Error Report . . . . . . . . . . . . . . 63 8.8. Clear Config Indication . . . . . . . . . . . . . . . . 85
8.5.2. Duplicate IPv4 Address . . . . . . . . . . . . . . . 64 9. Device Management Operations . . . . . . . . . . . . . . . . 86
8.5.3. Duplicate IPv6 Address . . . . . . . . . . . . . . . 64 9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 86
8.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 65 9.2. Image Data Response . . . . . . . . . . . . . . . . . . 87
8.7. Data Transfer Request . . . . . . . . . . . . . . . . . 65 9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . 87
8.7.1. Data Transfer Mode . . . . . . . . . . . . . . . . . 66 9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 87
8.7.2. Data Transfer Data . . . . . . . . . . . . . . . . . 66 9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . 87
8.8. Data Transfer Response . . . . . . . . . . . . . . . . . 67 9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 88
9. Mobile Session Management . . . . . . . . . . . . . . . . . . 68 9.7. Data Transfer Request . . . . . . . . . . . . . . . . . 88
9.1. Mobile Config Request . . . . . . . . . . . . . . . . . 68 9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 88
9.1.1. Add Mobile . . . . . . . . . . . . . . . . . . . . . 68 10. Mobile Session Management . . . . . . . . . . . . . . . . . . 90
9.1.2. Delete Mobile . . . . . . . . . . . . . . . . . . . 69 10.1. Mobile Config Request . . . . . . . . . . . . . . . . . 90
9.2. Mobile Config Response . . . . . . . . . . . . . . . . . 69 10.2. Mobile Config Response . . . . . . . . . . . . . . . . . 90
9.2.1. Result Code . . . . . . . . . . . . . . . . . . . . 70 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 91
10. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . . . 71 11.1. Split MAC and Local MAC Functionality . . . . . . . . . 91
10.1. Endpoint Authentication using DTLS . . . . . . . . . . . 71 11.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . 91
10.1.1. Authenticating with Certificates . . . . . . . . . . 71 11.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . 93
10.1.2. Authenticating with Preshared Keys . . . . . . . . . 72 11.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 96
10.2. Refreshing Cryptographic Keys . . . . . . . . . . . . . 73 11.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . 97
10.3. Certificate Usage . . . . . . . . . . . . . . . . . . . 73 11.4. Transport specific bindings . . . . . . . . . . . . . . 97
11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 74 11.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 99
11.1. Division of labor . . . . . . . . . . . . . . . . . . . 74 11.6. Quality of Service for Control Messages . . . . . . . . 99
11.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . 74 11.7. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . 100
11.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . 76 11.7.1. IEEE 802.11 WLAN Config Request . . . . . . . . . . 100
11.2. Roaming Behavior and 802.11 security . . . . . . . . . . 79 11.7.2. IEEE 802.11 WLAN Config Response . . . . . . . . . 101
11.3. Transport specific bindings . . . . . . . . . . . . . . 80 11.8. Data Message bindings . . . . . . . . . . . . . . . . . 101
11.3.1. Payload encapsulation . . . . . . . . . . . . . . . 80 11.9. Control Message bindings . . . . . . . . . . . . . . . . 101
11.3.2. Status and WLANS field . . . . . . . . . . . . . . . 80 11.9.1. Mobile Config Request . . . . . . . . . . . . . . . 101
11.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 81 11.9.2. WTP Event Request . . . . . . . . . . . . . . . . . 101
11.5. Quality of Service for Control Messages . . . . . . . . 81 11.9.3. Configuration Messages . . . . . . . . . . . . . . 102
11.6. Data Message bindings . . . . . . . . . . . . . . . . . 82 11.10. IEEE 802.11 Message Element Definitions . . . . . . . . 102
11.7. Control Message bindings . . . . . . . . . . . . . . . . 82 11.10.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . 102
11.7.1. Mobile Config Request . . . . . . . . . . . . . . . 82 11.10.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 106
11.7.2. WTP Event Request . . . . . . . . . . . . . . . . . 86 11.10.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . 107
11.8. 802.11 Control Messages . . . . . . . . . . . . . . . . 88 11.10.4. IEEE 802.11 Broadcast Probe Mode . . . . . . . . . 108
11.8.1. IEEE 802.11 WLAN Config Request . . . . . . . . . . 88 11.10.5. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . 108
11.8.2. IEEE 802.11 WLAN Config Response . . . . . . . . . . 94 11.10.6. IEEE 802.11 Direct Sequence Control . . . . . . . . 109
11.8.3. IEEE 802.11 WTP Event . . . . . . . . . . . . . . . 94 11.10.7. IEEE 802.11 Information Element . . . . . . . . . . 110
11.9. Message Element Bindings . . . . . . . . . . . . . . . . 96 11.10.8. IEEE 802.11 MAC Operation . . . . . . . . . . . . . 110
11.9.1. IEEE 802.11 WTP WLAN Radio Configuration . . . . . . 96 11.10.9. IEEE 802.11 MIC Countermeasures . . . . . . . . . . 112
11.9.2. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 98 11.10.10. IEEE 802.11 MIC Error Report From Mobile . . . . . 112
11.9.3. IEEE 802.11 Multi-domain Capability . . . . . . . . 98 11.10.11. IEEE 802.11 Mobile . . . . . . . . . . . . . . . . 113
11.9.4. IEEE 802.11 MAC Operation . . . . . . . . . . . . . 99 11.10.12. IEEE 802.11 Mobile Session Key . . . . . . . . . . 114
11.9.5. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 101 11.10.13. IEEE 802.11 Multi-domain Capability . . . . . . . . 116
11.9.6. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 101 11.10.14. IEEE 802.11 OFDM Control . . . . . . . . . . . . . 117
11.9.7. IEEE 802.11 Direct Sequence Control . . . . . . . . 102 11.10.15. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . 118
11.9.8. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 103 11.10.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . 118
11.9.9. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 104 11.10.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . 120
11.9.10. IEEE 802.11 Supported Rates . . . . . . . . . . . . 105 11.10.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . 121
11.9.11. IEEE 802.11 CFP Status . . . . . . . . . . . . . . . 105 11.10.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . 121
11.9.12. IEEE 802.11 Broadcast Probe Mode . . . . . . . . . . 106 11.10.20. IEEE 802.11 Update Mobile QoS . . . . . . . . . . . 122
11.9.13. IEEE 802.11 WTP Quality of Service . . . . . . . . . 106 11.10.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . 122
11.9.14. IEEE 802.11 MIC Error Report From Mobile . . . . . . 108 11.10.22. IEEE 802.11 WTP Quality of Service . . . . . . . . 125
11.10. IEEE 802.11 Message Element Values . . . . . . . . . . . 108 11.10.23. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . 126
12. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . . . 109 11.10.24. IEEE 802.11 WTP Radio Configuration . . . . . . . . 127
12.1. MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 109 11.10.25. Station QoS Profile . . . . . . . . . . . . . . . . 128
12.2. SilentInterval . . . . . . . . . . . . . . . . . . . . . 109 11.11. Technology Specific Message Element Values . . . . . . . 129
12.3. NeighborDeadInterval . . . . . . . . . . . . . . . . . . 109 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 130
12.4. WaitJoin . . . . . . . . . . . . . . . . . . . . . . . . 109 13. Security Considerations . . . . . . . . . . . . . . . . . . . 132
12.5. EchoInterval . . . . . . . . . . . . . . . . . . . . . . 109 13.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 132
12.6. DiscoveryInterval . . . . . . . . . . . . . . . . . . . 109 13.1.1. Converting Protected Data into Unprotected Data . . 133
12.7. RetransmitInterval . . . . . . . . . . . . . . . . . . . 110 13.1.2. Converting Unprotected Data into Protected Data
12.8. ResponseTimeout . . . . . . . . . . . . . . . . . . . . 110 (Insertion) . . . . . . . . . . . . . . . . . . . . 133
12.9. KeyLifetime . . . . . . . . . . . . . . . . . . . . . . 110 13.1.3. Deletion of Protected Records . . . . . . . . . . . 133
13. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . . . 111 13.1.4. Insertion of Unprotected Records . . . . . . . . . 133
13.1. MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 111 13.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 133
13.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . . . 111 13.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . 134
13.3. RetransmitCount . . . . . . . . . . . . . . . . . . . . 111 13.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 134
13.4. MaxRetransmit . . . . . . . . . . . . . . . . . . . . . 111 13.5. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 135
14. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 112 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 136
15. Security Considerations . . . . . . . . . . . . . . . . . . . 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 137
15.1. PSK based Session Key establishment . . . . . . . . . . 114 15.1. Normative References . . . . . . . . . . . . . . . . . . 137
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115 15.2. Informational References . . . . . . . . . . . . . . . . 138
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140
17.1. Normative References . . . . . . . . . . . . . . . . . . 116 Intellectual Property and Copyright Statements . . . . . . . . . 141
17.2. Informational References . . . . . . . . . . . . . . . . 117
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118
Intellectual Property and Copyright Statements . . . . . . . . . 119
1. Introduction 1. Introduction
The emergence of centralized architectures, in which simple IEEE The emergence of centralized architectures, in which simple IEEE
802.11 WTPs are managed by an Access Controller (AC) suggests that a 802.11 WTPs are managed by an Access Controller (AC) suggests that a
standards based, interoperable protocol could radically simplify the standards based, interoperable protocol could radically simplify the
deployment and management of wireless networks. WTPs require a set deployment and management of wireless networks. WTPs require a set
of dynamic management and control functions related to their primary of dynamic management and control functions related to their primary
task of connecting the wireless and wired mediums. Traditional task of connecting the wireless and wired mediums. Traditional
protocols for managing WTPs are either manual static configuration protocols for managing WTPs are either manual static configuration
via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs
are self-contained). This document describes the CAPWAP Protocol, a are self-contained). This document describes the CAPWAP Protocol, a
standard, interoperable protocol which enables an AC to manage a standard, interoperable protocol which enables an AC to manage a
collection of WTPs. The protocol is defined to be independent of collection of WTPs. While the protocol is defined to be independent
layer 2 technology. An IEEE 802.11 binding is provided to support of layer 2 technology, an IEEE 802.11 binding is provided to support
IEEE 802.11 wireless LAN networks. IEEE 802.11 wireless LAN 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 AC forwards viewed as remote RF interfaces controlled by the AC. The AC forwards
all L2 frames to be transmitted by a WTP to that WTP via the CAPWAP all L2 frames to be transmitted by a WTP to that WTP via the CAPWAP
protocol. L2 frames from mobile nodes (STAs) are forwarded by the protocol. L2 frames from mobile nodes (STAs) are forwarded by the
WTP to the AC using the CAPWAP protocol. Both Split-MAC and Local WTP to the AC using the CAPWAP protocol. Both Split-MAC and Local
MAC arhcitectures are supported. Figure 1 illustrates this MAC arhcitectures are supported. Figure 1 illustrates this
arrangement as applied to an IEEE 802.11 binding. arrangement as applied to an IEEE 802.11 binding.
skipping to change at page 7, line 48 skipping to change at page 7, line 48
Figure 1: Representative CAPWAP Architecture for Split MAC Figure 1: Representative CAPWAP Architecture for Split 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
and allows network operators to more tightly control their wireless and allows network operators to more tightly control their wireless
network infrastructure. network infrastructure.
Goals 1.1. Goals
Goals for the CAPWAP protocol are listed below: The goals for the CAPWAP protocol are listed below:
1. To centralize the bridging, forwarding, authentication and policy 1. To centralize the bridging, forwarding, authentication and policy
enforcement functions for a wireless network. Optionally, the AC enforcement functions for a wireless network. Optionally, the AC
may also provide centralized encryption of user traffic. may also provide centralized encryption of user traffic.
Centralization of these functions will enable reduced cost and Centralization of these functions will enable reduced cost and
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
skipping to change at page 8, line 26 skipping to change at page 8, line 26
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 other 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 mobile node (STA) to AC
communication is strictly outside the scope of this document. communication is strictly outside the scope of this document.
1.1. 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.2. 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 in revision 01 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:
skipping to change at page 9, line 17 skipping to change at page 9, line 17
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
Phone: +1 408-853-5269, Email: pcalhoun@cisco.com Phone: +1 408-853-5269, Email: pcalhoun@cisco.com
Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134
Phone: +1 408-853-5548, Email: rsuri@cisco.com Phone: +1 408-853-5548, Email: rsuri@cisco.com
Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134
Phone: +1 408-853-0532, Email: ncamwing@cisco.com Phone: +1 408-853-0532, Email: ncamwing@cisco.com
Scott Kelly, Facetime Communications, 1159 Triton Dr, Foster City, CA 94404 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 650 572-5846, Email: scott@hyperthought.com Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043
Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com
Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108
Phone: +1 734 222 1610, Email: shares@nexthop.com Phone: +1 734 222 1610, Email: shares@nexthop.com
DTLS is used as the security solution for the CAPWAP protocol. The DTLS is used as the security solution for the CAPWAP protocol. The
following people are authors of significant DTLS-related text following people are authors of significant DTLS-related text
included in this document: included in this document:
Scott Kelly, Facetime Communications, 1159 Triton Dr, Foster City, CA 94404 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 650 572-5846, Email: scott@hyperthought.com Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303
Email: ekr@networkresonance.com Email: ekr@networkresonance.com
The concept of using DTLS to secure the CAPWAP protocol was part of The concept of using DTLS to secure the CAPWAP protocol was part of
the Secure Light Access Point Protocol (SLAPP) proposal [add the Secure Light Access Point Protocol (SLAPP) proposal [add
reference when available]. The following people are authors of the reference when available]. The following people are authors of the
SLAPP proposal: SLAPP proposal:
Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089
Phone: +1 408-480-4716, Email: partha@arubanetworks.com Phone: +1 408-480-4716, Email: partha@arubanetworks.com
Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085
Phone: +1 408 470 7372, Email: dharkins@tropos.com Phone: +1 408 470 7372, Email: dharkins@tropos.com
Subbu Ponnuswammy, 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
[Ed note: Additional authors to be added as required.] 1.4. Acknowledgements
1.3. 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 [14]. Charles' review can be found at [16].
[Ed note: Additional acknowledgements to be added as required.]
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)
DTLS is a standards-track IETF protocol based upon TLS. The [14]. 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 are forwarded wireless frames. CAPWAP protocol Control messages are forwarded wireless frames. CAPWAP protocol Control
messages are management messages exchanged between a WTP and an AC. messages are management messages exchanged between a WTP and an AC.
The CAPWAP Data and Control packets are sent over separate UDP ports. The CAPWAP Data and Control packets are sent over separate UDP ports.
Since both data and control frames can exceed the PMTU, the payload Since both data and control frames can exceed the PMTU, the payload
of a CAPWAP data or control message can be fragmented. The of a CAPWAP data or control message can be fragmented. The
fragmentation behavior is highly dependent upon the lower layer fragmentation behavior is defined in Section 3.
transport and is defined in Section 3.
The CAPWAP Protocol begins with a discovery phase. The WTPs send a The CAPWAP Protocol begins with a discovery phase. The WTPs send a
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, using the DTLS AC with which to establish a secure DTLS session. CAPWAP protocol
initialization request message. [MTU discovery mechanism? to messages will be fragmented to the maximum length discovered to be
determine the MTU supported by the network between the WTP and AC.] supported by the network.
CAPWAP protocol messages will be fragmented to the maximum length
discovered to be 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. For the IEEE 802.11 binding, this information
typically includes a name (IEEE 802.11 Service Set Identifier, SSID) typically includes a name (IEEE 802.11 Service Set Identifier, SSID)
security parameters, the data rates to be advertised and the security parameters, the data rates to be advertised and the
associated radio channel(s) to be used. The WTP is then enabled for associated radio channel(s) to be used. The WTP is then enabled for
operation. 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 resultant 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 mobile units (STAs) that are
communicating with the WTP. This may include the creation of local communicating with the WTP. This may include the creation of local
data structures in the WTP for the mobile units and the collection of data structures in the WTP for the mobile units and the collection of
statistical information about the communication between the WTP and statistical information about the communication between the WTP and
the mobile units. The CAPWAP protocol provides a mechanism for the the mobile units. The CAPWAP protocol provides a mechanism for the
AC to obtain statistical information collected by the WTP. AC to obtain statistical information collected by the WTP.
skipping to change at page 12, line 44 skipping to change at page 12, line 40
Request message, and a Mobile message element, carried in the Mobile Request message, and a Mobile message element, carried in the Mobile
Configure Request. If technology specific message elements are Configure Request. If technology specific message elements are
required for any of the existing CAPWAP messages defined in this required for any of the existing CAPWAP messages defined in this
specification, they MUST also be defined in the technology binding specification, they MUST also be defined in the technology binding
document. 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 this specification, begins with "IEEE 802.11"."
2.2. CAPWAP State Machine Definition 2.2. CAPWAP Session Establishment Overview
This section describes the session establishment process message
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
certificates for DTLS authentication. The CAPWAP Protocol State
Machine is described in detail in Section 2.3.
============ ============
WTP AC
============ ============
[----------- begin optional discovery ------------]
Discover Request ------>
<------ Discover Response
[----------- end optional discovery ------------]
(--- begin dtls handshake ---)
ClientHello ------>
<------ HelloVerifyRequest
(with cookie)
ClientHello ------>
(with cookie)
<------ ServerHello
<------ Certificate
<------ ServerHelloDone
(WTP callout for AC authorization)
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ------>
(AC callout for WTP
authorization)
[ChangeCipherSpec]
<------ Finished
(--- DTLS session is established now ---)
Join Request ------>
<------ Join Response
( ---assume image is up to date ---)
Configure Request ------->
<------ Configure Response
(--- enter RUN state ---)
:
:
Echo Request ------->
<------ Echo Response
:
:
EventRequest ------->
<------ Event Response
:
:
At the end of the illustrated CAPWAP message exchange, the AC and WTP
are securely exchanging CAPWAP control messages. This is an
idealized illustration, provided to clarify protocol operation.
Section 2.3 provides a detailed description of the corresponding
state machine.
2.3. CAPWAP State Machine Definition
The following state diagram represents the lifecycle of a WTP-AC The following state diagram represents the lifecycle of a WTP-AC
session: session. Use of DTLS by the CAPWAP protocol results in the
juxtaposition of two nominally separate yet tightly bound state
machines. The DTLS and CAPWAP state machines are coupled through an
API consisting of commands (from CAPWAP to DTLS) and notifications
(from (DTLS to CAPWAP). Certain transitions in the DTLS state
machine are triggered by commands from the CAPWAP state machine,
while certain transitions in the CAPWAP state machine are triggered
by notifications from the DTLS state machine.
/-------------\ This section defines the CAPWAP Integrated State Machine. In the
| v figure below, single lines (denoted with '-' and '|') are used to
| +------------+ illustrate state transitions. Double lines (denoted with '=' and
| C| Idle |<---------------------------------------+ '"') are used to illustrate commands and notifications between DTLS
| +------------+ | and CAPWAP. A line composed of '~' characters is used to delineate
| ^ |a ^ | the boundary between nominal CAPWAP and DTLS state machine
| | | \----\ y | components.
| | | | +-------------+------------+ |
| | | | | | DTLS-rekey | |
| | | | | +--------->+------------+ |
| | | | | | |6 ^
| | | |t V | x V |
| | | +--------+--+ +------------+ |
| / | C| Run |------>| DTLS-Reset |<---|----\
| / | r+-----------+ u +------------+ | |
| / | ^ ^ v| | |
| | v | | | | |
| | +--------------+ | /----/ V | |
| | C| Discovery | q| k| +-------+ | |
| | b+--------------+ +-------------+ | Reset |-+ w |
| | |d f| ^ | Configure | +-------+ |
| | | | | +-------------+ |
| |e v | | ^ |
| +---------+ v |i 2| |
| C| Sulking | +------------+ +--------------+ |
| +---------+ C| DTLS-Init |--->| DTLS-Complete| |
| +------------+ z +--------------+ |
| |h |4 |
| | v o /
\ | +------------+-------/
\-----------------/ | Image Data |C
+------------+n
Figure 2: CAPWAP State Machine /-------------<----------------+--------------------\
v |d |
+------+ b+-----------+ +----------+ |
| Idle |-->| Discovery |--->| Sulking | |
+------+ a +-----------+ c +----------+ |
^ |aa ^ |e /----------------------\ |
| V f| v k| | |
h +--------------+ +------------+ i +------------+j | |
/--| Join |->| Configure |-->| Image Data | | |
| +--------------+ g+------------+ +------------+ | |
| "c1, ^ ^ ^ m| ^ |l | |
| "c4 " " " | /-------/ | /----/ |
| " " " " V |s v V |
| " " " " +------------+ o+------------+ |
| " " " " | Run |->| Reset |-------/
| " " " " n+------------+ +------------+ p
| " " " " "c2 ^ ^ c3" ^
\---"-----"--"---"--------"----"-------/ " " CAPWAP
~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~
" " " " " " " " DTLS
v " "n2 \"""""\ " " v "n6,n7
/-->+------+ " W+------+ " " " +------------+
| /-| Idle | " C| Auth |--"~-"----"----->| Shutdown |-------\P
| | +------+ " +------+V " " " /--->| |<----\ |
| |X Z| " ^ U| " " n4 " | +------------+ | |
| | | " | | " " n5," | ^ | |
| | v "n1 |Y | n3" v n8" |R |Q | |
| | +--------+ | +------------+ S+------------+ | |
| | | Init | \->| Run |<--| Rekey | | |
| | +--------+ | |-->| | | |
| | +------------+T +------------+ | |
| \---------------------------------------------------------/ |
\-------------------------------------------------------------/
Figure 2: CAPWAP Integrated State Machine
The CAPWAP protocol state machine, depicted above, is used by both The CAPWAP protocol state machine, depicted above, is used by both
the AC and the WTP. For every state defined, only certain messages the AC and the WTP. In cases where states are not shared (i.e. not
are permitted to be sent and received. In all of the CAPWAP control implemented in one or the other of the AC or WTP), this is explicitly
messages defined in this document, the state for which each command called out in the transition descriptions below. For every state
is valid is specified. defined, only certain messages are permitted to be sent and received.
The CAPWAP control messages definitions specify the state(s) in which
each message is valid.
Note that in the state diagram figure above, the 'C' character is 2.3.1. CAPWAP Protocol State Transitions
used to represent a condition that causes the state to remain the
same.
The following text discusses the various state transitions, and the The following text discusses the various state transitions, and the
events that cause them. events that cause them. This section does not discuss interactions
between DTLS- and CAPWAP-specific states. Those interactions, as
well as DTLS-specific states and transitions, are discussed in
subsequent sections.
Idle to Discovery (a): This is the initialization state. Idle to Discovery (a): This transition occurs once device
initialization is complete.
WTP: The WTP enters the Discovery state prior to transmitting the WTP: The WTP enters the Discovery state prior to transmitting the
first Discovery Request message (see Section 5.1). Upon first Discovery Request message (see Section 5.1). Upon
entering this state, the WTP sets the DiscoveryInterval timer entering this state, the WTP sets the DiscoveryInterval timer
(see Section 12). The WTP resets the DiscoveryCount counter to (see Section 4.5). The WTP resets the DiscoveryCount counter
zero (0) (see Section 13). The WTP also clears all information to zero (0) (see Section 4.6). The WTP also clears all
from ACs (e.g., AC Addresses) it may have received during a information from ACs it may have received during a previous
previous Discovery phase. Discovery phase.
AC: The AC does not need to maintain state information for the WTP AC: The AC does not maintain state information for the WTP upon
upon reception of the Discovery Request message, but it MUST reception of the Discovery Request message, but it SHOULD
respond with a Discovery Response message (see Section 5.2). respond with a Discovery Response message (see Section 5.2).
This transition is a no-op for the AC.
Discovery to Discovery (b): This is the state in which the WTP Idle to Join (aa): This transition occurs when the WTP presents a
DTLS ClientHello message containing a valid cookie to the AC.
WTP: This transition is a no-op for the WTP.
AC: The AC does not maintain state information until the WTP
presents a DTLS ClientHello message containing a valid cookie.
Upon receipt of a DTLS ClientHello message containing a valid
cookie, the AC creates session state and transitions to the
Join state.
Discovery to Discovery (b): In the Discovery state, the WTP
determines which AC to connect to. determines which AC to connect to.
WTP: This event occurs when the DiscoveryInterval timer expires. WTP: This transition occurs when the DiscoveryInterval timer
The WTP transmits a Discovery Request message to every AC from expires. If the WTP is configured with a list of ACs, it
which the WTP has not received a Discovery Response message. transmits a Discovery Request message to every AC from which it
For every transition to this event, the WTP increments the has not received a Discovery Response message. For every
DiscoveryCount counter. See Section 5.1 for more information transition to this event, the WTP increments the DiscoveryCount
on how the WTP knows the ACs to which ACs it should transmit counter. See Section 5.1 for more information on how the WTP
the Discovery Request messages. The WTP restarts the knows the ACs to which it should transmit the Discovery Request
DiscoveryInterval timer. messages. The WTP restarts the DiscoveryInterval timer
whenever it transmits Discovery Request messages.
AC: This is a no-op. AC: This is a no-op.
Discovery to Sulking (d): This state occurs on a WTP when Discovery Discovery to Sulking (c): This transition occurs on a WTP when
or connectivity to the AC fails. Discovery or connectivity to the AC fails.
WTP: The WTP enters this state when the DiscoveryInterval timer WTP: The WTP enters this state when the DiscoveryInterval timer
expires and the DiscoveryCount variable is equal to the expires and the DiscoveryCount variable is equal to the
MaxDiscoveries variable (see Section 13). Upon entering this MaxDiscoveries variable (see Section 4.6). Upon entering this
state, the WTP shall start the SilentInterval timer. While in state, the WTP shall start the SilentInterval timer. While in
the Sulking state, all received CAPWAP protocol messages the Sulking state, all received CAPWAP protocol messages
received shall be ignored. received shall be ignored.
AC: This is a no-op. AC: This is a no-op.
Sulking to Idle (e): This state occurs on a WTP when it must restart Sulking to Idle (d): This transition occurs on a WTP when it must
the discovery phase. restart the discovery phase.
WTP: The WTP enters this state when the SilentInterval timer (see WTP: The WTP enters this state when the SilentInterval timer (see
Section 12) expires. Section 4.5) expires.
AC: This is a no-op. AC: This is a no-op.
Discovery to DTLS-Init (f): This state is used by the WTP to confirm Discovery to Join (e): This transition occurs when the WTP sends a
its commitment to an AC that it wishes to be provided service and ClientHello message to the AC, confirming that it wishes to be
to simultaneously establish a secure channel with that AC. provided services by the AC.
WTP: The WTP selects the best AC based on the information it
gathered during the Discovery Phase. It then sends a
ClientHello to its preferred AC, sets the WaitJoin timer, and
awaits the outcome of the DTLS handshake.
AC: The AC enters this state for the given WTP upon reception
of a ClientHello. The AC responds by sending either the
ServerHello or the HelloVerifyRequest to the WTP. For the AC,
this is a meta-state; in actuality, it remains in the Discovery
state. To do otherwise resuls in loss of the stateless nature
of the cookie exchange.
DTLS-Init to Idle (h): This state transition is used when the DTLS
Initialization process failed.
WTP: This state transition occurs if the WTP is unable to
successfully establish a DTLS session.
AC: This state transition occurs if the AC is unable to
successfully establish a DTLS session.
DTLS-Init to Discovery (i): This state transition is used to return
the WTP to discovery mode when an unresponsive AC is encountered.
WTP: The WTP enters the Discovery state when the DTLS handshake WTP: The WTP selects the best AC based either on information it
fails. gathered during the Discovery Phase or on its configuration.
It then sends a JoinRequest message to its preferred AC, sets
the WaitJoin timer, and awaits the Join Response Message.
AC: This state transition is invalid. AC: This is a no-op for the AC.
DTLS-Init to DTLS-Complete (z): This state transition is used to Join to Discovery (f): This state transition is used to return the
indicate DTLS session establishment. WTP to the Discovery state when an unresponsive AC is encountered.
WTP: The DTLS-Complete state is entered when the WTP receives the WTP: The WTP re-enters the Discovery state when the WaitJoin timer
Finished message from the AC. expires.
AC: The DTLS-Complete state is entered when the AC receives the AC: This is a no-op.
Finished mesage from the WTP.
DTLS-Complete to Configure (2): This state transition is used by the Join to Configure (g): This state transition is used by the WTP and
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 DTLS session establishment and 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 Configure Request message(see the same, the WTP transmits the Configuration Status message
Section 7.2) message 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 12). (see ). (Section 4.5) If the version numbers are not the same,
the WTP will immediately transition to Image Data state (see
transition (i)).
AC: This state transition occurs when the AC receives the AC: This state transition occurs immediately after the AC
Configure Request message from the WTP. The AC must transmit a transmits the Join Response message to the WTP. If the AC
Configure Response message(see Section 7.3) to the WTP, and may receives the Configuration Status message from the WTP, the AC
include specific message elements to override the WTP's must transmit a Configuration Status Response message(see
configuration. Section 8.3) to the WTP, and may include specific message
elements to override the WTP's configuration. If the AC
instead receives the Image Data Request from the WTP, it
immediately transitions to the Image Data state (see transition
(i)).
DTLS Complete to Image Data (4): This state transition is used by the Join to Reset (h): This state transition occurs when the WaitJoin
WTP and the AC to download executable firmware. Timer expires.
WTP: The state transition occurs when the WTP WaitJoin timer
expires, or upon DTLS negotiation failure.
AC: Thise state transition occurs when the AC WaitJoin timer
expires, or or upon DTLS negotiation failure.
Configure to Image Data (i): This state transition is used by the 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 8.1) message requesting that the AC's latest firmware Section 9.1) message requesting that a download of the AC's
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 8.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 (n): The Image Data state is used by WTP and Image Data to Image Data (j): The Image Data state is used by WTP and
the AC during the firmware download phase. the AC during the firmware download phase.
WTP: The WTP enters the Image Data state when it receives a Image WTP: The WTP enters the Image Data state when it receives an Image
Data Response message indicating that the AC has more data to Data Response message indicating that the AC has more data to
send. 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 DTLS-Reset (k): This state is used to reset the DTLS Configure to Reset (k): This state transition is used to reset the
connection prior to restarting the WTP with a new configuration. connection to the AC prior to restarting the WTP with a new
configuration.
WTP: The WTP enters the DTLS-Reset state when it determines that a WTP: The WTP enters the Reset state when it determines that a
new configuration is required. reset of the WTP is required, due to the characteristics of a
new configuration.
AC: The AC transitions to the DTLS-Reset state when the DTLS AC: The AC transitions to the Reset state when it receives the
connection tear-down is complete. DTLSPeerDisconnect (n7) notification.
Image Data to DTLS-Reset (o): This state transition is used to reset Image Data to Reset (l): This state transition is used to reset the
the DTLS connection prior to restarting the WTP after an image DTLS connection prior to restarting the WTP after an image
download. download.
WTP: The WTP enters the DTLS-Reset state when image download WTP: When an image download completes, the WTP enters the Reset
completes. state, and terminates the DTLS connection, sending a
DTLSShutdown command to the DTLS state machine.
AC: The AC enters the DTLS-Reset state upon receipt of TLS AC: The AC enters the Reset state upon receipt of a DTLSIdle (n6)
Finished message from the WTP. notification.
Configure to Run (q): This state transition occurs when the WTP and Configure to Run (m): This state transition occurs when the WTP and
AC enter their normal state of operation. AC enter their normal state of operation.
WTP: The WTP enters this state when it receives a successful WTP: The WTP enters this state when it receives a successful
Configure Response message from the AC. The WTP initializes Configuration Status Response message from the AC. The WTP
the HeartBeat Timer (see Section 12), and transmits the Change initializes the HeartBeat timer (see Section 4.5), and
State Event Request message (see Section 7.6). transmits the Change State Event Request message (see
Section 8.6).
AC: This state transition occurs when the AC receives the Change AC: This state transition occurs when the AC receives the Change
State Event Request message (see Section 7.6) from the WTP. State Event Request message (see Section 8.6) from the WTP.
The AC responds with a Change State Event Response (see The AC responds with a Change State Event Response (see
Section 7.7) message. The AC must start the Section 8.7) message. The AC must start the
NeighborDeadInterval timer (see Section 12). NeighborDeadInterval timer (see Section 4.5).
Run to Run (r): This is the normal state of operation. Run to Run (n): This is the normal state of operation.
WTP: This is the WTP's normal state of operation. There are many WTP: This is the WTP's normal state of operation. There are many
events that result this state transition: events that result this state transition:
Configuration Update: The WTP receives a Configuration Update Configuration Update: The WTP receives a Configuration Update
Request message(see Section 7.4). The WTP MUST respond with Request message(see Section 8.4). The WTP MUST respond with
a Configuration Update Response message (see Section 7.5). a Configuration Update Response message (see Section 8.5).
Change State Event: The WTP receives a Change State Event Change State Event: The WTP receives a Change State Event
Response message, or determines that it must initiate a Response message, or determines that it must initiate a
Change State Event Request message, as a result of a failure Change State Event Request message, as a result of a failure
or change in the state of a radio. or change in the state of a radio.
Echo Request: The WTP receives an Echo Request message (see Echo Request: The WTP receives an Echo Request message (see
Section 6.1), to which it MUST respond with an Echo Response Section 7.1), to which it MUST respond with an Echo Response
message(see Section 6.2). message(see Section 7.2).
Clear Config Indication: The WTP receives a Clear Config Clear Config Indication: The WTP receives a Clear Config
Indication message (see Section 7.8). The WTP MUST reset Indication message (see Section 8.8). The WTP MUST reset
its configuration back to manufacturer defaults. its configuration back to manufacturer defaults.
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 8.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 8.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 8.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 8.8). Section 9.8).
WLAN Config Request: The WTP receives a WLAN Config Request WLAN Config Request: The WTP receives a WLAN Config Request
message (see Section 11.8.1), to which it MUST respond with message (see Section 11.7.1), to which it MUST respond with
a WLAN Config Response message (see Section 11.8.2). a WLAN Config Response message (see Section 11.7.2).
Mobile Config Request: The WTP receives a Mobile Config Request Mobile Config Request: The WTP receives a Mobile Config Request
message (see Section 9.1), to which it MUST respond with a message (see Section 10.1), to which it MUST respond with a
Mobile Config Response message (see Section 9.2). 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 7.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 7.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 7.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 7.7). Section 8.7).
Echo: The AC sends an Echo Request message Section 6.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 6.2) from the WTP. Section 7.2 from the WTP.
Clear Config Indication: The AC sends a Clear Config Indication Clear Config Indication: The AC sends a Clear Config Indication
message (see Section 7.8). message (see Section 8.8).
WLAN Config: The AC sends a WLAN Config Request message (see WLAN Config: The AC sends a WLAN Config Request message (see
Section 11.8.1) or receives the corresponding WLAN Config Section 11.7.1) or receives the corresponding WLAN Config
Response message (see Section 11.8.2) from the WTP. Response message (see Section 11.7.2) from the WTP.
Mobile Config: The AC sends a Mobile Config Request message Mobile Config: The AC sends a Mobile Config Request message
(see Section 9.1) or receives the corresponding Mobile (see Section 10.1) or receives the corresponding Mobile
Config Response message (see Section 9.2) from the WTP. Config Response message (see Section 10.2) 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 8.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 8.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 the
AC (see Section 8.5) and MUST generate a corresponding WTP AC (see Section 9.5) and MUST generate a corresponding WTP
Event Response message (see Section 8.6). Event Response message (see Section 9.6).
Run to Idle (t): This event occurs when an error occurs in the Run to Reset(o): This state transition is used when the AC or WTP
communication between the WTP and the AC. wish to tear down the connection. This may occur as part of
normal operation, or due to error conditions.
WTP: The WTP enters the Idle state when the underlying reliable WTP: The WTP enters the Reset state when it initiates orderly
transport in unable to transmit a message within the termination of the DTLS connection, or when the underlying
RetransmitInterval timer (see Section 12), and the maximum reliable transport is unable to transmit a message within the
number of RetransmitCount counter has reached the MaxRetransmit RetransmitInterval timer, see Section 4.5 The WTP also enters
variable (see Section 13). the Reset state upon receiving a DTLS session termination
message (DTLS alert) from the AC. The WTP sends a DTLSReset
command to the DTLS state machine.
AC: The AC enters the Idle state when the underlying reliable AC: The AC enters the Idle state when it initiates orderly
transport in unable to transmit a message within the termination of the DTLS connection, or when the underlying
RetransmitInterval timer (see Section 12), and the maximum reliable transport is unable to transmit a message within the
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 13). variable (see Section 4.6). The AC also enters the Reset state
upon receiving a DTLS session termination message from the WTP.
Run to DTLS-Reset(u): This state transition is used to when the AC or Reset to Idle (p): This state transition occurs when the state
WTP wish to tear down the connection. machine is restarted following a system restart, an unrecoverable
error on the AC-WTP connection, or orderly session teardown.
WTP: The WTP enters the DTLS-Reset state when it initiates orderly WTP: The WTP clears any state associated with any AC and enters
termination of the DTLS connection; The WTP sends a TLS the Idle state.
Finished message to the AC.
AC: The AC enters the DTLS-Reset state upon receipt of a TLS AC: The AC clears any state associated with the WTP and enters the
Finished message from the WTP. idle state.
Run to DTLS-Rekey (x): This state is used to initiate a new DTLS Run to Image Data (s): This state transition occurs when the AC
handshake. Either the WTP or AC may initiate the state transmits an Image Data Request to the WTP, with the Initiate
transition. DTLS protected CAPWAP packets may continue to flow Download message element. The means by which the AC decides to
while a new handshake is being performed. Because packets may be download firmware is undefined, but could occur through an
reordered, records encrypted under the new cipher suite may be administrative action.
received before one side receives the ChangeCipherSpec from the
other side.
The epoch value in the DTLS record header allows the data from the WTP: The WTP enters this state when it receives an an Image Data
two associations/cryptographic states to be distinguished. Request to the WTP, with the Initiate Download message element.
Implementations SHOULD retain the state for the old association The WTP responds by transmitting an Image Data Request with the
until it is likely that all old records have been received or Image Filename message element included..
dropped, e.g., for the maximum packet lifetime. If the state is
dropped too early, the only effect will be that some data is lost,
which is a condition that systems running over unreliable
protocols need to consider in any case.
Because the new handshake is performed over the existing DTLS AC: This state transition occurs when the AC decides that an WTP
association, both sides can be confident that the handshake was is to update its firmware by sending an Image Data Request to
properly initiated and was not tampered with. All data is the WTP, with the Initiate Download message element.
protected under either the old or new keys--and these can be
distinguished by both the epoch and the authentication (MAC)
verification. Thus, there is no period during which data is
unprotected.
WTP: The WTP enters the DTLS-Rekey state when either (1) a rekey 2.3.2. CAPWAP to DTLS Commands
is required, or (2) the AC initiates a DTLS handshake.
AC: The AC enters the DTLS-Rekey state when either (1) a rekey is Four commands are defined for the CAPWAP to DTLS API. These
required, or (2) the WTP initiates a DTLS handshake. "commands" are conceptual, and may be implemented as one or more
function calls. This API definition is provided to clarify
interactions between the DTLS and CAPWAP components of the integrated
CAPWAP state machine.
DTLS-rekey to Run (y): This event occurs when the DTLS rehandshake is Below is a list of the minimal command API:
completed.
WTP: This state transition occurs when the WTP completes the DTLS o c1: DTLSStart is sent to the DTLS module to cause a DTLS session
rehandshake. to be established.
AC: This state transition occurrs when the AC completed the DTLS o c2: DTLSRehandshake is sent to the DTLS module to cause initiation
rehandshake. of a rehandshake (DTLS rekey).
DTLS-rekey to Reset (6): This event occurs when the DTLS rehandshake o c3: DTLSShutdown is sent to the DTLS module to cause session
exchange phase times out. teardown.
WTP: This state transition occurs when the WTP does not o c4: DTLSAbort is sent to the DTLS module to cause session teardown
successfully complete the DTLS rehandshake phase. when the WaitJoin timer expires.
AC: This state transition occurs when the AC does not successfully 2.3.3. DTLS to CAPWAP Notifications
complete the DTLS rehandshake phase.
DTLS-Reset to Reset (v): This state transition is used to complete Eight notifications are defined for the DTLS to CAPWAP API. These
DTLS session tear-down. "notifications" are conceptual, and may be implemented in numerous
ways (e.g. as function return values). This API definition is
provided to clarify interactions between the DTLS and CAPWAP
components of the integrated CAPWAP state machine.
WTP: The WTP enters the Reset state when it has completed DTLS Below is a list of the API notifications:
session clean-up, and it is ready to complete the CAPWAP
protocol session clean-up.
AC: The AC enters the Reset state when it has completed DTLS o n1: DTLSInitFailure is sent to the CAPWAP module to indicate an
session clean-up, and it is ready to complete the CAPWAP initialization failure, which may be due to out of memory or other
protocol session clean-up. internal error condition.
Reset to Idle (w): This event occurs when the state machine is o n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the
restarted. CAPWAP module to indicate peer authentication or authorization
failures, respectively.
WTP: The WTP reboots. After reboot the WTP will start its CAPWAP o n3: DTLSEstablished is sent to the CAPWAP module to indicate that
state machine in the Idle state. that a secure channel now exists.
AC: The AC clears any state associated with the WTP. The AC o n4: DTLSEncapFailure may be sent to CAPWAP to indicate an
generally does this as a result of the reliable link layer encapsulation failure. DTLSDecapFailure may be sent to CAPWAP to
timing out. indicate an encryption/authentication failure
2.3. Use of DTLS in the CAPWAP Protocol o n5: DTLSRehandshake is sent to the CAPWAP module to indicate DTLS
rehandshake initiation by peer.
DTLS is used as a tightly-integrated secure wrapper for the CAPWAP o n6: DTLSIdle is sent to the CAPWAP module to indicate that session
protocol. Certain errors may occur during the DTLS negotiation abort (as requested by CAPWAP) is complete; this occurs when the
and/or the resulting session; the following section describes those, WaitJoin timer expires, or when CAPWAP is executing an orderly
along with handling requirements. It is important to note that the session shutdown.
CAPWAP protocol, being the controlling entity for the DTLS session,
must establish its own timers outside of DTLS (e.g. WaitJoin), and
is responsible for terminating sessions which timeout. DTLS
implements a retransmission backoff timer, but will not terminate a
session unless instructed to do so.
2.3.1. DTLS Error Handling Requirements o n7: DTLSPeerDisconnect is sent to the CAPWAP module to indicate
DTLS session teardown by peer. Note that the n7 notification, can
be received while in the Join, Configure, Image Data, Run and
Reset states, and always causes a transition to the Reset state.
DTLS uses all of the same handshake messages and flows as TLS, with o n8: DTLSReassemblyFailure may be sent to the CAPWAP module to
three principal changes: indicate DTLS fragment reassembly failure.
1. A stateless cookie exchange has been added to prevent denial of 2.3.4. DTLS State Transitions
service attacks.
2. Modifications to the handshake header have been made to handle This section describes the transitions in the DTLS-specific portion
message loss, reordering, and fragmentation of the state machine.
3. Retransmission timers to handle message loss have been added. Idle to Init (Z): This transition indicates the begining of a DTLS
session.
Each of these features can cause the DTLS session to fail, as WTP: The state ransition is triggered by receipt of the DTLSStart
discussed below. For reference, an illustration of a normal DTLS command from the CAPWAP state machine, and causes the WTP to
session establishment (in this particular case, using certificates send a DTLS ClientHello to the AC.
for authentication) is as follows:
Client (WTP) Server (AC) AC: The state transition is triggered by receipt of the DTLSStart
------------ ------------ command from the CAPWAP state machine. The AC starts the
ClientHello ------> WaitJoin timer and awaits reception of a DTLS ClientHello
message
<----- HelloVerifyRequest Init to Authenticate/Authorize (Y) This transition indicates that the
(contains cookie) DTLS handshake is in progress.
WTP: The WTP executes this state transition upon receipt of a
valid ServerHello.
AC: The AC executes this transition upon receipt of a certificate
payload (if configured for public key authentication) or upon
receipt of the ClientKeyExchange payload if configured for
preshared keys.
Init to Idle(X) This state transition occurs upon timeout of the
WaitJoin Timer.
WTP: Upon receiving a DTLSAbort command from the CAPWAP state
machine, the WTP DTLS state machine transitions to Idle state.
AC: Upon receiving a DTLSAbort command from the CAPWAP state
machine, the AC DTLS state machine transitions to Idle state.
Authenticate/Authorize to Authenticate/Authorize (W) This state
transition is a Loopback state, representing execution of the TLS
handshake protocol, including authorization callbacks to the
CAPWAP architecture.
WTP: Upon receiving AC credential, attempt to execute associated
validation, authentication, and authorization callbacks. Note
that credentials may span protocol messages, in which case the
WTP will remain in this state pending receipt of all credential
payloads.
AC: Upon receipt of the WTP credential, attempt to execute
associated validation, authentication, and authorization
callbacks. Note that credentials may span protocol messages,
in which case the AC will remain in this state pending receipt
of all credential payloads.
Authenticate/Authorize to Shutdown (V) This state transition
indicates a failure of the DTLS handshake.
WTP: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the
CAPWAP state machine, depending on the exact cause of the
error. May send a DTLS notification to the AC to indicate
failure.
AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the CAPWAP
state machine, depending on the exact cause of the error. May
send a DTLS Notification to the AC to indicate failure.
Authenticate/Authorize to Run (U) This state transition occurs upon
successful completion of the DTLS handshake.
WTP: Send a DTLSEstablished notification to the CAPWAP state
machine.
AC: Send a DTLSEstablished notification to the CAPWAP state
machine.
Run to Rekey (T) This state transition occurs when a DTLS rehandshake
is in progress; this is initiated when either (a) the DTLS state
machine receives the DTLSRehandshake command from CAPWAP, or (b) a
DTLS rehandshake message is received from the peer..
WTP: If CAPWAP issued a DTLSRehandshake command, initiate
rehandshake with the peer; note that control traffic may
continue to flow using existing secure association. If the
rehandshake is initiated by the peer, send a DTLSRehandshake
notification to CAPWAP.
AC: If CAPWAP issued a DTLSRehandshake command, initiate
rehandshake with the peer; note that control traffic may
continue to flow using existing secure association. If the
rehandshake is initiated by the peer, send a DTLSRehandshake
notification to CAPWAP.
Run to Shutdown (S) This state transition indicates a shutdown of the
DTLS channel.
WTP: This state transition occurs when the CAPWAP state machine
sends a DTLSShutdown command, or when the the AC terminates the
DTLS session.
AC: This state transition occurs when CAPWAP state machine sends a
DTLSShutdown command, or when the WTP terminates the DTLS
session.
Rekey to Run (R) This state transition indicates the successful
completion of a DTLS rehandshake.
WTP: This state transition occurs when the WTP receives the DTLS
Finished message from the AC, completing the DTLS re-handshake.
AC: This state transition occurs when the AC sends a DTLS Finished
message to the WTP, completing the DTLS re-handshake.
Rekey to Shutdown (Q) This state transition indicates the failure of
the DTLS rekey operation.
WTP: This state transition occurs when there is a failure in the
rehandshake negotiation with the AC.
AC: This state transition occurs when there is a failure in the
rehandshake negotiation with the WTP.
Shutdown to Idle (P) This state transition occurs upon transmission
of a DTLS Session termination message, or upon receipt of a DTLS
session termination message.
WTP: This state transition occurs after the WTP transmits the DTLS
session termination message. If the WTP receives a DTLS
session termination message, it sends the DTLSPeerDisconnect
notification to CAPWAP and moves to the Idle state.
AC: This state transition occurs after the AC transmits the DTLS
session termination message. If the AC receives a DTLS session
termination message, it sends the DTLSPeerDisconnect
notification to CAPWAP and moves to the Idle state.
2.4. Use of DTLS in the CAPWAP Protocol
DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP
protocol. In this document DTLS and CAPWAP are discussed as
nominally distinct entitites; however they are very closely coupled,
and may even be implemented inseparably. Since there are DTLS
library implementations currently available, and since security
protocols (e.g. IPsec, TLS) are often implemented in widely
available acceleration hardware, it is both convenient and forward-
looking to maintain a modular distinction in this document.
This section describes a detailed walk-through of the interactions
between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
encountered during the normal course of operation.
2.4.1. DTLS Handshake Processing
Details of the DTLS handshake process are specified in [DTLS]. This
section describes the interactions between the DTLS session
establishment process and the CAPWAP protocol. In the normal case,
the DTLS handshake will proceed as follows (NOTE: this example uses
certificates, but preshared keys are also supported):
============ ============
WTP AC
============ ============
ClientHello ------> ClientHello ------>
<------ HelloVerifyRequest
(with cookie) (with cookie)
<------ ServerHello (seq=1)
<------ Certificate (seq=2) ClientHello ------>
<------ ServerHelloDone (seq=3) (with cookie)
<------ ServerHello
<------ Certificate
<------ ServerHelloDone
(WTP callout for AC authorization)
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished ------> Finished ------>
(AC callout for WTP
authorization)
[ChangeCipherSpec] [ChangeCipherSpec]
<------ Finished <------ Finished
2.3.2. DTLS Cookie Exchange Failure DTLS, as specified, provides its own retransmit timers with an
exponential back-off. However, it will never terminate the handshake
due to non-responsiveness; rather, it will continue to increase its
back-off timer period. Hence, timing out incomplete DTLS handshakes
is entirely the responsiblity of the CAPWAP protocol.
The cookie exchange is optional in DTLS. For use with the CAPWAP 2.4.1.1. Join Operations
protocol, it may not be required if the network on which the AC and
WTP reside is entirely within the same administrative domain.
However, if AC-WTP communications traverse multiple administrative
domains, the cookie exchange SHOULD be supported. There are three
potential points of failure in Hello exchange, assuming cookies are
used:
o The AC does not respond to the ClientHello (this may occur The WTP, either through the Discovery process, or through pre-
independently of cookie usage) configuration, determines the AC to connect to. The WTP uses DTLS to
establish a secure connection to the selected AC. Prior to
initiation of the DTLS handshake, the WTP sets the WaitJoin timer.
Upon receipt of a ClientHello message containing a valid cookie, the
AC sets the WaitJoin timer. If the Join operation has not completed
prior to timer expiration, the Join process is aborted, the WTP
transitions back to Discovery state, and the AC transitions back to
Idle state. Upon successful completion of the Join process the
WaitJoin timer is deactivated.
o The WTP does not respond to the HelloVerifyRequest 2.4.2. DTLS Error Handling
o The ClientHello contains an invalid cookie If the AC does not respond to any DTLS messages sent by the WTP, the
DTLS specification calls for the WTP to retransmit these messages.
If the WaitJoin timer expires, CAPWAP will issue the DTLSAbort
command, causing DTLS to terminate the handshake and remove any
allocated session context. Note that DTLS MAY send a single TLS
Alert message to the AC to indicate session termination.
In determining appropriate error handling behavior for any of these If the WTP does not respond to any DTLS messages sent by the AC, the
cases, it is important to remember that the stateless cookie CAPWAP protocol allows for three possiblities, listed below. Note
implements a defense mechanism from the point of view of the AC. that DTLS MAY send a single TLS Alert message to the AC to indicate
That is, it is explictly designed to minimize AC-side processing session termination.
prior to verifying that the WTP can receive and respond to packets at
the specified address. Hence, any processing associated with this
mechanism SHOULD be minimized.
In the case of AC non-responsiveness to the ClientHello, the WaitJoin o The message was lost in transit; in this case, the WTP will re-
timer will eventually expire. When this occurs, the WTP SHOULD log transmit its last outstanding message, since it did not receive
an error message and choose an alternative AC if one exists, or the reply.
return to the CAPWAP protocol Discovery state.
In the case of WTP non-responsiveness to the HelloVerifyRequest, the o The WTP sent a DTLS Alert, which was lost in transit; in this
DTLS implementation purposely does not set a timer (the case, the AC's WaitJoin timer will expire, and the session will be
HelloVerifyRequest is stateless by design). This means that DTLS terminated.
itself will provide no indication of WTP non-responsiveness. To
mitigate this, the AC MAY log a message when sending a
HelloVerifyRequest, and SHOULD log a message upon receipt of a valid
corresponding ClientHello. In this way, optional external detection
of non-responsive WTP's can be used to troubleshoot such problems
using data from the AC alone. In reality, administrators will
typically have access to WTP logs as well, making detection of such
problems straightforward.
In case of an invalid cookie in the ClientHello, the AC MUST o Communication with the WTP has completely failed; in this case,
terminate the DTLS handshake, returing to Discovery state. A DTLS the AC's WaitJoin timer will expire, and the session will be
alert MAY be sent to the WTP indicating the failure. terminated.
2.3.3. DTLS Re-Assembly Failure The DTLS specification provides for retransmission of unacknowledged
requests. If retransmissions remain unacknowledged, the WaitJoin
timer will eventually expire, at which time the CAPWAP module will
terminate the session.
If a cookie fails to validate, this could represent a WTP error, or
it could represent a DoS attack. Hence, AC resource utilization
SHOULD be minimized. The AC MAY log a message indicating the
failure, but SHOULD NOT attempt to reply to the WTP.
Since DTLS handshake messages are potentially larger than the maximum Since DTLS handshake messages are potentially larger than the maximum
record size, DTLS supports fragmenting of handshake messages across record size, DTLS supports fragmenting of handshake messages across
multiple records. There are several potential causes of re-assembly multiple records. There are several potential causes of re-assembly
errors, including overlapping and/or lost fragments. The DTLS errors, including overlapping and/or lost fragments. The DTLS module
implementation should return an error to the CAPWAP protocol MUST send a DTLSReassemblyFailure notification to CAPWAP. Whether
implementation when such errors occur. The precise error value is an precise information is given along with notification is an
API issue, and hence is beyond the scope of this document. Upon implementation issue, and hence is beyond the scope of this document.
receipt of such an error, the CAPWAP protocol implementation SHOULD Upon receipt of such an error, the CAPWAP protocol implementation
log an appropriate error message. Whether processing continues or SHOULD log an appropriate error message. Whether processing
the DTLS session is terminated is implementation dependent. continues or the DTLS session is terminated is implementation
dependent.
DTLS decapsulation errors consist of three types: decryption errors,
and authentication errors, and malformed DTLS record headers. Since
DTLS authenticates the data prior to encapsulation, if decryption
fails, it is difficult to detect this without first attempting to
authenticate the packet. If authentication fails, a decryption error
is also likely, but not guaranteed. Rather than attempt to derive
(and require the implementation of) algorithms for detecting
decryption failures, these are reported as authentication failures.
The DTLS module MUST provide a DTLSDecapFailure notification to
CAPWAP when such errors occur. If a malformed DTLS record header is
detected, the packets SHOULD be silently discarded, and the receiver
MAY log an error message.
There is currently only one encapsulation error defined: MTU
exceeeded. As part of DTLS session establishment, CAPWAP informs
DTLS of the MTU size. This may be dynamically modified at any time
when CAPWAP sends the DTLSMtuUpdate command to DTLS. DTLS returns
this notification to CAPWAP whenever a transmission request will
result in a packet which exceeds the MTU.
2.4.3. DTLS Rehandshake Behavior
DTLS rekeying (known in DTLS as "rehandshake") requires special
attention, as the DTLS specification provides no rehandshake
triggering mechanism. Rather, the application (in this case, CAPWAP)
is expected to manage this for itself. This section addressed
various aspects of rehandshake behavior.
One simple way to think of a DTLS session is as a pair of
unidirectional channels which are tightly bound together. A useful
analogy is the twisted pair used for phone wiring, with one line per
pair. Then, the rehandshake process can be thought of using the call
over the existing pair to establish a call over a new pair - that is,
an entirely new session is negotiated under the protection of the
existing session.
This sounds simple enough, yet there is operational complexity in
changing over to the new session. In particular, how does each end
know when it is safe to delete the "old" session, and switch over to
the new one? If DTLS were not a datagram protocol, this would be
simpler, but the fact that message delivery is unreliable
significantly complicates things: when the AC (the "server")
transmits its Finished message, it cannot be sure that the WTP
received it until the WTP transmits data on the new channel.
This fact constrains the way in which we transition to the new
session, and delete the old one. The WTP, upon receipt of the AC's
Finished message for the new session, immediately makes the new
session active, and transmits no further data (e.g. echo requests,
statistics, etc) on the old channel, and sends a TLS "user_cancelled"
alert message on the old channel, after which the old session is
immediately deleted.
The AC, sets a DTLSSessionDelete timer, (see Section 4.5) and
immediately makes the new session active, and transmits no further
data (e.g. echo requests, statistics, etc) on the old channel.
If a TLS "user_cancelled" alert message is received on the old
channel, the session delete timer is deactivated, and the session is
deleted.
if the dtls-session-delete timer expires, a TLS "user_cancelled"
alert message is transmitted on the old channel, and the session is
deleted.
Note that there is a slight possibility that some packets may be in
flight when the session is deleted. However, since CAPWAP provides
reliable delivery, these packets will be retransmitted over the new
channel.
2.4.3.1. Peer Initiated Rehandshake Triggers
Since key lifetimes are not negotiable in DTLS, it is possible that a
rehandshake from a peer may occur at any time, and implementations
must be prepared for this eventuality. Presumably, communicating
devices will be within the same domain of control. This being the
case, overly-aggressive rekeying may be detected by simply monitoring
logs, assuming such activity is indeed logged. Hence,
implementations MUST log rekey attempts as they occur, reporting the
time and identifying information for the peer.
CAPWAP implementations MUST provide an administrative interface which
permits specification of key lifetimes in seconds. Also,
implementations which wait until this interval has expired to begin
the rehandshake process are liable to encounter temporary service
lapses on heavily loaded networks, so implementations SHOULD begin
the rehandshake before the actual lifetime has elapsed.
Given the relatively low bandwidth we might reasonably expect over a
CAPWAP control channel and the strength of modern cryptographic
algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume
that lifetimes will typically be more than 8 hours. Given this
assumption, a good rule of thumb for deciding when to rekey is this:
deduct a random number of seconds from the lifetime (say, between 1%
and 5% of the lifetime), and begin the rehandshake process at that
point. Using a random value helps avert collisions, when both sides
initiate a rehandshake at the same time (discussed further below).
2.4.3.2. Time Based Rehandshake Triggers
CAPWAP implementations MUST provide an administrative interface which
permits specification of key lifetimes in seconds. Also,
implementations which wait until this interval has expired to begin
the rehandshake process are liable to encounter temporary service
lapses on heavily loaded networks, so implementations SHOULD begin
the rehandshake before the actual lifetime has elapsed.
Given the relatively low bandwidth we might reasonably expect over a
CAPWAP control channel and the strength of modern cryptographic
algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume
that key lifetimes will typically be more than 8 hours. Given this
assumption, a good rule of thumb for deciding when to rekey is this:
deduct a random number of seconds from the lifetime (say, between 1%
and 5% of the lifetime), and begin the rehandshake process at that
point. Using a random value helps avert collisions, when both sides
initiate a rehandshake at the same time.
2.4.3.3. Volume Based Rehandshake Triggers
CAPWAP implementations MUST provide an administrative interface which
permits specification of key lifetimes in packet count. Like time-
based, lifetimes, implementations which wait until this interval has
expired to begin the rehandshake process may encounter temporary
service lapses on heavily loaded networks, so implementations SHOULD
begin the rehandshake before the actual lifetime has elapsed.
Volume-based lifetime estimation for purposes of rehandshake
initiation is considerably more complex than time-based lifetime. In
addition to avoiding collisions, the maximum burst rate must be
known, and an extimate made, assuming rehandshake packets are lost,
etc. Hence, we do not specify a one-size-fits-all approach here, and
the specific algorithm used is implementation dependent.
2.4.3.4. Rehandshake Collisions
A collision occurs when both sides initiate a rehandshake
simultaneously. No matter how much care is taken, rehandshake
collisions are a distinct possibility. Hence, a contention
resolution strategy is specified.
A rehandshake collision is detected when a system receives a
rehandshake initiation when it has one outstanding with the same
peer.
When this occurs, each side will compare its own address with that of
its peer (in network byte order).
The one with the lower of the two addresses will ignore the peer's
rehandshake message, and continue with its own rehandshake process.
The one with the higher message will immediately abort its current
rehandshake, and set the DTLSRehandshake timer (see Section 4.5); if
the peer with the lower address does not complete the rehandshake
before the timer expires, the peer with the higher address will re-
initiate.
2.4.4. DTLS EndPoint Authentication
DTLS supports endpoint authentication with certificates or preshared
keys. The TLS algorithm suites for each endpoint authentication
method are described below.
2.4.4.1. Authenticating with Certificates
Note that only block ciphers are currently recommended for use with
DTLS. To understand the reasoning behind this, see [26].
However,support for AES counter mode encryption is currently
progressing in the TLS working group, and once protocol identifiers
are available, they will be added below. At present, the following
algorithms MUST be supported when using certificates for CAPWAP
authentication:
o TLS_RSA_WITH_AES_128_CBC_SHA
o TLS_RSA_WITH_3DES_EDE_CBC_SHA
The following algorithms SHOULD be supported when using certificates:
o TLS_DH_RSA_WITH_AES_128_CBC_SHA
o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
The following algorithms MAY be supported when using certificates:
o TLS_RSA_WITH_AES_256_CBC_SHA
o TLS_DH_RSA_WITH_AES_256_CBC_SHA
2.4.4.2. Authenticating with Preshared Keys
Pre-shared keys present significant challenges from a security
perspective, and for that reason, their use is strongly discouraged.
However, [13] defines 3 different methods for authenticating with
preshared keys:
o PSK key exchange algorithm - simplest method, ciphersuites use
only symmetric key algorithms
o DHE_PSK key exchange algorithm - use a PSK to authenticate a
Diffie-Hellman exchange. These ciphersuites give some additional
protection against dictionary attacks and also provide Perfect
Forward Secrecy (PFS).
o RSA_PSK key exchange algorithm - use RSA and certificates to
authenticate the server, in addition to using a PSK. This is not
susceptible to passive attacks.
The first approach (plain PSK) is susceptible to passive dictionary
attacks; hence, while this alorithm MAY be supported, special care
should be taken when choosing that method. In particular, user-
readable passphrases SHOULD NOT be used, and use of short PSKs should
be strongly discouraged. Additionally, DHE_PSK MUST be supported,
and RSA_PSK MAY be supported.
The following cryptographic algorithms MUST be supported when using
preshared keys:
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
The following algorithms SHOULD be supported when using preshared
keys:
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
The following algorithms MAY be supported when using preshared keys:
o TLS_PSK_WITH_AES_128_CBC_SHA
o TLS_PSK_WITH_AES_256_CBC_SHA
o TLS_PSK_WITH_3DES_EDE_CBC_SHA
o TLS_RSA_PSK_WITH_AES_128_CBC_SHA
o TLS_RSA_PSK_WITH_AES_256_CBC_SHA
o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
2.4.4.3. Certificate Usage
Validation of the certificates 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
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
distinguishable from the certificate used by the WTP. To accomplish
this differentiation, the x.509v3 certificates MUST include the
Extensions field [11] and MUST include the NetscapeComment [15]
extension.
For an AC, the value of the NetscapeComment extension MUST be the
string "CAPWAP AC Device Certificate". For a WTP, the value of the
NetscapeComment extension MUST be the string "CAPWAP WTP Device
Certificate".
Part of the CAPWAP certificate validation process includes ensuring
that the proper string is included in the NetscapeComment extension,
and only allowing the CAPWAP session to be established if the
extension does not represent the same role as the device validating
the certificate. For instance, a WTP MUST NOT accept a certificate
whose NetscapeComment field is set to "CAPWAP WTP Device
Certificate".
3. CAPWAP Transport 3. CAPWAP Transport
The CAPWAP protocol uses UDP as a transport, and can be used with The CAPWAP protocol uses UDP as a transport, and can be used with
IPv4 or IPv6. This section details the specifics of how the CAPWAP IPv4 or IPv6. This section details the specifics of how the CAPWAP
protocol works in conjunction with IP. protocol works in conjunction with IP.
3.1. UDP Transport 3.1. UDP Transport
Communication between a WTP and an AC is established according to the Communication between a WTP and an AC is established according to the
standard UDP client/server model. One of the CAPWAP requirements is standard UDP client/server model. One of the CAPWAP requirements is
to allow a WTP to reside behind a firewall and/or Network Address to allow a WTP to reside behind a firewall and/or Network Address
Translation (NAT) device. Since the connection is initiated by the Translation (NAT) device. Since the connection is initiated by the
WTP (client) to the well-known UDP port of the AC (server), the use WTP (client) to the well-known UDP port of the AC (server), the use
of UDP is a logical choice. of UDP is a logical choice.
CAPWAP protocol control packets sent between the WTP and the AC use CAPWAP protocol control packets sent between the WTP and the AC use
well known UDP port 12222. CAPWAP protocol data packets sent between well known UDP port [to be IANA assigned]. CAPWAP protocol data
the WTP and the AC use UDP port [to be IANA assigned]. packets sent between the WTP and the AC use UDP port [to be IANA
assigned].
3.2. AC Discovery 3.2. AC Discovery
A WTP and an AC will frequently not reside in the same IP subnet A WTP and an AC will frequently not reside in the same IP subnet
(broadcast domain). When this occurs, the WTP must be capable of (broadcast domain). When this occurs, the WTP must be capable of
discovering the AC, without requiring that multicast services are discovering the AC, without requiring that multicast services are
enabled in the network. This section describes how AC discovery is enabled in the network. This section describes how AC discovery is
performed by WTPs. performed by WTPs.
As the WTP attempts to establish communication with an AC, it sends As the WTP attempts to establish communication with an AC, it sends
skipping to change at page 27, line 12 skipping to change at page 38, line 12
the appropriate wireless standard. Additional information is in the appropriate wireless standard. Additional information is in
Section 4.2. Section 4.2.
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.3.2. style header, defined in Section 4.4.
4.1. CAPWAP Transport Header 4.1. CAPWAP Transport 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.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER| RID |F|L|R| Frag ID | Length | |Version| RID | HLEN |F|L|W|M| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Frag Offset |Rsv-2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Radio MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status/WLANs | Payload... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. VER Field
A 2 bit field which contains the version of CAPWAP used in this
packet. The value for this draft is 0.
4.1.2. RID Field Version: A 4 bit field which contains the version of CAPWAP used in
this packet. The value for this draft is 0.
A 3 bit field which contains the Radio ID number for this packet. RID: A 5 bit field which contains the Radio ID number for this
WTPs with multiple radios but a single MAC Address use this field to packet. WTPs with multiple radios but a single MAC Address range
indicate which radio is associated with the packet. use this field to indicate which radio is associated with the
packet.
4.1.3. F Bit HLEN: Length of CAPWAP tunnel header in 4 byte words. (Similar to IP
header length). This length includes the optional headers.
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.
4.1.4. L Bit L: The Not Last 'L' bit is valid only if the 'F' bit is set and
The Not Last 'L' bit is valid only if the 'F' bit is set and
indicates whether the packet contains the last fragment of a indicates whether the packet contains the last fragment of a
fragmented exchange between WTP and AC. When this bit is 1, the fragmented exchange between WTP and AC. When this bit is 1, the
packet is not the last fragment. When this bit is 0, the packet is packet is not the last fragment. When this bit is 0, the packet
the last fragment. is the last fragment.
4.1.5. R Bit W: The Wireless 'W' bit is used to specify whether the optional
wireless specific information field is present in the header. A
value of one (1) is used to represent the fact that the optional
header is present.
The R bit is reserved and set to 0 in this version of the CAPWAP M: The M bit is used to indicate that the Radio MAC Address optional
protocol. header is present. This is used to communicate the MAC address of
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.
4.1.6. Fragment ID Flags: A set of reserved bits for future flags in the CAPWAP header.
All implementations complying with version zero of this protocol
MUST set these bits to zero.
An 8 bit field whose value is assigned to each group of fragments Fragment ID: An 16 bit field whose value is assigned to each group of
making up a complete set. The fragment ID space is managed fragments making up a complete set. The fragment ID space is
individually for every WTP/AC pair. The value of Fragment ID is managed individually for every WTP/AC pair. The value of Fragment
incremented with each new set of fragments. The Fragment ID wraps to ID is incremented with each new set of fragments. The Fragment ID
zero after the maximum value has been used to identify a set of wraps to zero after the maximum value has been used to identify a
fragments. The CAPWAP protocol only supports up to 2 fragments per set of fragments.
frame.
4.1.7. Length Fragment Offset: A 13 bit field that indicates where in the payload
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
units of 8 octets (64 bits). The first fragment has offset zero.
The 16 bit length field contains the number of bytes in the Payload. Reserved: The 3-bit Reserved-2 field is reserved and set to 0 in this
The field is encoded as an unsigned number. version of the CAPWAP protocol.
4.1.8. Status and WLANS Radio MAC Address: This optional field contains the MAC address of
the radio receiving the packet. This is useful in packets sent
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
'M' bit is set.
The interpretation of this 16 bit field is binding specific. Refer The field contains the basic format:
to the transport portion of the binding for a specific wireless
technology for the definition of this field.
4.1.9. Payload 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The number of bytes in the MAC Address field. The length
field is present since new IEEE technologies are using 48 byte
MAC addresses.
This field contains the header for a CAPWAP Data Message or CAPWAP MAC Address: The MAC Address of the receiving radio.
Control Message, followed by the data associated with that message.
Wireless Specific Information: This optional field contains
technology specific information that may be used to carry per
packet wireless information. This field is only present if the
'W' bit is set.
The field contains the basic 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wireless ID | Length | Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wireless ID: The wireless binding identifier. The following
values are defined:
1 - : IEEE 802.11
Length: The length of the data field
Data: Wireless specific information, whose details are defined in
the technology specific binding section.
Payload: This field contains the header for a CAPWAP Data Message or
CAPWAP Control Message, followed by the data associated with that
message.
4.2. CAPWAP Data Messages 4.2. CAPWAP Data Messages
A CAPWAP protocol data message is a forwarded wireless frame. The A CAPWAP protocol data message is a forwarded wireless frame. The
CAPWAP protocol defines two different modes of encapsulations; IEEE CAPWAP protocol defines two different modes of encapsulations; IEEE
802.3 and native wireless. IEEE 802.3 encapsulation requires that 802.3 and native wireless. IEEE 802.3 encapsulation requires that
the bridging function be performed in the WTP. An IEEE 802.3 the bridging function be performed in the WTP. An IEEE 802.3
encapsulated user payload frame has the following format: encapsulated user payload frame has the following format:
+------------------------------------------------------+ +------------------------------------------------------+
skipping to change at page 29, line 14 skipping to change at page 41, line 13
subject to the rules defined under the specific wireless technology subject to the rules defined under the specific wireless technology
binding. As a consequence, each wireless technology binding MUST binding. As a consequence, each wireless technology binding MUST
define a section entitled "Payload encapsulation", which defines the define a section entitled "Payload encapsulation", which defines the
format of the wireless payload that is encapsulated within the CAPWAP format of the wireless payload that is encapsulated within the CAPWAP
Data messages. Data messages.
In the event that the encapsulated frame would exceed the transport In the event that the encapsulated frame would exceed the transport
layer's MTU, the sender is responsible for the fragmentation of the layer's MTU, the sender is responsible for the fragmentation of the
frame, as specified in Section 3.3. frame, as specified in Section 3.3.
4.3. CAPWAP Control Messages Overview 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 WTP Configuration: The WTP Configuration messages are used by the AC
to push a specific configuration to the WTP it has a control to push a specific configuration to the WTP it has a control
channel with. Messages that deal with the retrieval of statistics channel with. Messages that deal with the retrieval of statistics
from the WTP also fall in this category. from the WTP also fall in this category.
Mobile Session Management: Mobile session management messages are Mobile Session Management: Mobile session management messages are
used by the AC to push specific mobile policies to the WTP. used by the AC to push specific mobile station policies to the
WTP.
Firmware Management: Messages in this category are used by the AC to Firmware Management: Messages in this category are used by the AC to
push a new firmware image to the WTP. push a new firmware image to the WTP.
Discovery, WTP Configuration and Mobile Session Management messages Discovery, WTP Configuration and Mobile Session Management messages
MUST be implemented. Firmware Management MAY be implemented. MUST be implemented. Firmware Management MAY be implemented.
In addition, technology specific bindings may introduce new control In addition, technology specific bindings may introduce new control
channel commands. channel commands.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Seq Num | Msg Element Length | | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] | | Seq Num | Msg Element Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.1.1. Message Type 4.3.1.1. Message Type
The Message Type field identifies the function of the CAPWAP control The Message Type field identifies the function of the CAPWAP control
message. The valid values for Message Type are the following: message. The Message Type field is comprised of an IANA Enterprise
Number and a message type value field. The first two byte contain
the IANA Enterprise Number (for example, the IEEE 802.11 IANA
Enterprise number is 13277), and the second two bytes contain the
Message Type value. The message type field can be expressed as:
Description Value Message Type = IANA Enterprise Number * 256 + Message Type Value
The valid values for base CAPWAP Message Types are given in the table
below:
CAPWAP Control Message Message Type
Value
Discovery Request 1 Discovery Request 1
Discovery Response 2 Discovery Response 2
Configure Request 3 Join Request 3
Configure Response 4 Join Response 4
Configuration Update Request 5 Configuration Status 5
Configuration Update Response 6 Configuration Status Response 6
WTP Event Request 7 Configuration Update Request 7
WTP Event Response 8 Configuration Update Response 8
Change State Event Request 9 WTP Event Request 9
Change State Event Response 10 WTP Event Response 10
Echo Request 11 Change State Event Request 11
Echo Response 12 Change State Event Response 12
Unused 13 Echo Request 13
Image Data Request 14 Echo Response 14
Image Data Response 15 Image Data Request 15
Reset Request 16 Image Data Response 16
Reset Response 17 Reset Request 17
Primary Discovery Request 18 Reset Response 18
Primary Discovery Response 19 Primary Discovery Request 19
Data Transfer Request 20 Primary Discovery Response 20
Data Transfer Response 21 Data Transfer Request 21
Clear Config Indication 22 Data Transfer Response 22
WLAN Config Request 23 Clear Config Indication 23
WLAN Config Response 24 Mobile Config Request 24
Mobile Config Request 25 Mobile Config Response 25
Mobile Config 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/ 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
pending have the same sequence number. This field will wrap back to pending have the same sequence number. This field will wrap back to
zero. zero.
4.3.1.3. Message Element Length 4.3.1.3. Message Element Length
The Length field indicates the number of bytes following the Sequence The Length field indicates the number of bytes following the Sequence
Num field. Num field.
4.3.1.4. Message Element[0..N] 4.3.1.4. Flags
The Flags field MUST be set to zero.
4.3.1.5. Time Stamp
The Timestamp contains the timestamp. PRC-TODO: Details need to be
added here, and I am waiting for info from Dave Perkins.
4.3.1.6. Message Element[0..N]
The message element(s) carry the information pertinent to each of the The message element(s) carry the information pertinent to each of the
control message types. Every control message in this specification control message types. Every control message in this specification
specifies which message elements are permitted. specifies which message elements are permitted.
4.3.2. Message Element Format 4.3.2. Control Message Quality of Service
The message element is used to carry information pertinent to a It is recommended that CAPWAP control messages be sent by both the AC
control message. Every message element is identified by the Type and the WTP with an appropriate Quality of Service precedence value,
field, whose numbering space is managed via IANA (see Section 16). ensuring that congestion in the network minimizes occurrences of
The total length of the message elements is indicated in the Message CAPWAP control channel disconnects. Therefore, a Quality of Service
enabled CAPWAP device should use the following values:
802.1P: The precedence value of 7 SHOULD be used.
DSCP: The DSCP tag value of 46 SHOULD be used.
4.4. CAPWAP Protocol Message Elements
This section defines the CAPWAP Protocol message elements which are
included in CAPWAP protocol control messages.
Message elements are used to carry information needed in control
messages. Every message element is identified by the Type field,
whose numbering space is managed via IANA (see Section 14). The
total length of the message elements is indicated in the Message
Element Length field. 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.
Additional message elements may be defined in separate IETF Additional message elements may be defined in separate IETF
documents. documents.
skipping to change at page 31, line 47 skipping to change at page 45, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | 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. of bytes in the Value field.
4.3.2.1. Generic Message Elements 4.4.1. AC Descriptor
This section includes message elements that are not bound to a
specific control message.
4.3.2.1.1. Vendor Specific
The Vendor Specific Payload is used to communicate vendor specific The AC payload message element is used by the AC to communicate it's
information between the WTP and the AC. The value contains the current state. The value contains the following fields.
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 | | Reserved | Hardware Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... | | HW Ver | Software Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Ver | Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit | Active WTPs | Max WTPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max WTPs | Security |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 104 for Vendor Specific Type: 1 for AC Descriptor
Length: >= 7 Length: 18
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Reserved: MUST be set to zero
Network Management Private Enterprise Codes" [17]
Element ID: A 16-bit Element Identifier which is managed by the Hardware Version: The AC's hardware version number
vendor.
Value: The value associated with the vendor specific element. Software Version: The AC's Firmware version number
4.3.3. Quality of Service Stations: The number of mobile stations currently associated with
the AC
It is recommended that CAPWAP control messages be sent by both the AC Limit: The maximum number of stations supported by the AC
and the WTP with an appropriate Quality of Service precedence value, Active WTPs: The number of WTPs currently attached to the AC
ensuring that congestion in the network minimizes occurrences of
CAPWAP control channel disconnects. Therefore, a Quality of Service
enabled CAPWAP device should use:
802.1P: The precedence value of 7 SHOULD be used. Max WTPs: The maximum number of WTPs supported by the AC
DSCP: The DSCP tag value of 46 SHOULD be used. Security: A 8 bit bit mask specifying the authentication credential
type supported by the AC. The following values are supported (see
Section 2.4.4):
5. CAPWAP Discovery Operations 1 - X.509 Certificate Based
The Discovery messages are used by a WTP to determine which ACs are 2 - Pre-Shared Secret
available to provide service, and the capabilities and load of the
ACs.
5.1. Discovery Request 4.4.2. AC IPv4 List
The Discovery Request message is used by the WTP to automatically The AC List message element is used to configure a WTP with the
discover potential ACs available in the network. The Discovery latest list of ACs in a cluster.
Request message provides ACs with the primary capabilities of the
WTP. A WTP must exchange this information to ensure subsequent
exchanges with the ACs are consistent with the WTP's functional
characteristics. A WTP must transmit this command even if it has a
statically configured AC.
Discovery Request messages MUST be sent by a WTP in the Discover 0 1 2 3
state after waiting for a random delay less than 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
MaxDiscoveryInterval, after a WTP first comes up or is +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(re)initialized. A WTP MUST send no more than the maximum of | AC IP Address[] |
MaxDiscoveries Discovery Request messages, waiting for a random delay +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
less than MaxDiscoveryInterval between each successive message.
This is to prevent an explosion of WTP Discovery Request messages. Type: 2 for AC List
An example of this occurring is when many WTPs are powered on at the
same time.
Discovery Request messages MUST be sent by a WTP when no Echo Length: 4
Response messages are received for NeighborDeadInterval and the WTP
returns to the Idle state. Discovery Request messages are sent after
NeighborDeadInterval. They MUST be sent after waiting for a random
delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum
of MaxDiscoveries Discovery Request messages, waiting for a random
delay less than MaxDiscoveryInterval between each successive message.
If a Discovery Response message is not received after sending the The AC IP Address: An array of 32-bit integers containing an AC's
maximum number of Discovery Request messages, the WTP enters the IPv4 Address.
Sulking state and MUST wait for an interval equal to SilentInterval
before sending further Discovery Request messages.
The Discovery Request message may be sent as a unicast, broadcast or 4.4.3. AC IPv6 List
multicast message.
Upon receiving a Discovery Request message, the AC will respond with The AC List message element is used to configure a WTP with the
a Discovery Response message sent to the address in the source latest list of ACs in a cluster.
address of the received discovery request message.
The following subsections define the message elements that MUST be 0 1 2 3
included in the Discovery Request message. 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[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 for AC IPV6 List
5.1.1. Discovery Type Length: 16
The Discovery message element is used to configure a WTP to operate The AC IP Address: An array of 32-bit integers containing an AC's
in a specific mode. IPv6 Address.
4.4.4. AC Name
The AC name message element contains an ASCII representation of the
AC's identity. The value is a variable length byte string. The
string is NOT zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Discovery Type| | Name ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 58 for Discovery Type Type: 4 for AC Name
Length: 1 Length: > 0
Discovery Type: An 8-bit value indicating how the AC was discovered. Name: A variable length ASCII string containing the AC's name
The following values are supported:
0 - Broadcast 4.4.5. AC Name with Index
1 - Configured 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
message element would be present is equal to the number of ACs
configured on the WTP.
5.1.2. WTP Descriptor 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WTP descriptor message element is used by the WTP to communicate Type: 5 for AC Name with Index
it's current hardware/firmware configuration. The value contains the
following fields. Length: > 2
Index: The index of the preferred server (e.g., 1=primary,
2=secondary).
AC Name: A variable length ASCII string containing the AC's name.
4.4.6. AC Timestamp
The AC Timestamp message element is sent by the AC to synchronize the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Version | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Version |
Type: 6 for AC Timestamp
Length: 4
Timestamp: The AC's current time, allowing all of the WTPs to be
time synchronized in the format defined by Network Time Protocol
(NTP) in RFC 1305 [10].
4.4.7. Add MAC ACL Entry
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
no longer provides any service to the MAC addresses provided in the
message. The MAC Addresses provided in this message element are not
expected to be saved in non-volatile memory on 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Boot Version | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Encryption Capabilities | | MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 7 for Add MAC ACL Entry
Length: >= 7
Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to add to the ACL.
4.4.8. Add Mobile Station
The Add Mobile Station message element is used by the AC to inform a
WTP that it should forward traffic for a particular mobile station.
The Add Mobile Station message element will be accompanied by
technology specific binding information element which may include
security parameters. Consequently, the security parameters must be
applied by the WTP for the particular mobile.
Once a mobile station's policy has been pushed to the WTP through
this message element, an AC may change any policies by simply sending
a modified Add Mobile Station message element. When a WTP receives
an Add Mobile Station message element for an existing mobile station,
it must override any existing state it may have for the mobile
station in question. The latest Add Mobile Station message element
data overrides any previously received messages.
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 | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | VLAN Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 for WTP Descriptor Type: 8 for Add Mobile
Length: 16 Length: >= 7
Hardware Version: A 32-bit integer representing the WTP's hardware
version number
Software Version: A 32-bit integer representing the WTP's Firmware Radio ID: An 8-bit value representing the radio
version number
Boot Version: A 32-bit integer representing the WTP's boot loader's MAC Address: The mobile station's MAC Address
version number
Max Radios: An 8-bit value representing the number of radios (where VLAN Name: An optional variable string containing the VLAN Name on
each radio is identified via the RID field) supported by the WTP which the WTP is to locally bridge user data. Note this field is
only valid with WTPs configured in Local MAC mode.
Radios in use: An 8-bit value representing the number of radios 4.4.9. Add Static MAC ACL Entry
present in the WTP
Encryption Capabilities: This 16-bit field is used by the WTP to The Add Static MAC ACL Entry message element is used by an AC to add
communicate it's capabilities to the AC. Since most WTP's support a permanent ACL entry on a WTP, ensuring that the WTP no longer
link layer encryption, the AC may make use of these services. provides any service to the MAC addresses provided in the message.
There are binding dependent encryption capabilities. A WTP that The MAC Addresses provided in this message element are expected to be
does not have any encryption capabilities would set this field to saved in non-volative memory on the WTP.
zero (0). Refer to the specific binding for further specification
of the Encryption Capabilities field.
5.1.3. WTP Radio Information 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WTP radios information message element is used to communicate the Type: 9 for Add Static MAC ACL Entry
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. Length: >= 7
Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to add to the permanent ACL.
4.4.10. CAPWAP Timers
The CAPWAP Timers message element is used by an AC to configure
CAPWAP timers on a WTP.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Timers
Length: 2
Discovery: The number of seconds between CAPWAP Discovery packets,
when the WTP is in the discovery mode.
Echo Request: The number of seconds between WTP Echo Request CAPWAP
messages.
4.4.11. Change State Event
The Change State message element is used to communicate a change in
the operational state of a radio. The value contains two fields, as
shown.
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 | Radio Type | | Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for Change State Event
Type: 4 for WTP Radio Information
Length: 3 Length: 3
Radio ID: The Radio Identifier, which typically refers to an Radio ID: The Radio Identifier, typically refers to some interface
interface index on the WTP 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. 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.
2 - 802.11a: An IEEE 802.11a radio. 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:
4 - 802.11g: An IEEE 802.11g radio. 0 - Normal
8 - 802.11n: An IEEE 802.11n radio. 1 - Radio Failure
65535 - all: Used to specify all radios in the WTP. 2 - Software Failure
5.1.4. WTP MAC Type 4.4.12. Data Transfer Data
The WTP MAC-Type message element allows the WTP to communicate its The Data Transfer Data message element is used by the WTP to provide
mode of operation to the AC. A WTP that advertises support for both information to the AC for debugging purposes.
modes allows the AC to select the mode to use, based on local policy.
0 0 1 2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Type | | Data Type | Data Length | Data ....
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD for WTP MAC Type Type: 12 for Data Transfer Data
Length: 1 Length: >= 3
MAC Type: The MAC mode of operation supported by the WTP. The Data Type: An 8-bit value the type of information being sent. The
following values are supported following values are supported:
0 - Local-MAC: Local-MAC is the default mode that MUST be 1 - WTP Crash Data
supported by all WTPs.
1 - Split-MAC: Split-MAC support is optional, and allows the AC 2 - WTP Memory Dump
to receive and process native wireless frames.
2 - Both: WTP is capable of supporting both Local-MAC and Split- Data Length: Length of data field.
MAC.
5.1.5. WTP Frame Type Data: Debug information.
The WTP Frame-Type message element allows the WTP to communicate the 4.4.13. Data Transfer Mode
tunneling modes of operation which it supports to the AC. A WTP that
advertises support for all modes allows the AC to select which mode The Data Transfer Mode message element is used by the AC to request
will be used, based on its local policy. information from the WTP for debugging purposes.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Frame Type | | Data Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: TBD for WTP Frame Type Type: 13 for Data Transfer Mode
Length: 1 Length: 1
Frame Type: The Frame type specifies the encapsulation modes Data Type: An 8-bit value the type of information being requested.
supported by the WTP. The following values are supported The following values are supported:
1 - Local Bridging: Local Bridging allows the WTP to perform the 1 - WTP Crash Data
bridging function. This value MUST NOT be used when the MAC
Type is set to Split-MAC.
2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to 2 - WTP Memory Dump
encapsulate all user payload as native IEEE 802.3 frames (see
Section 4.2). This value MUST NOT be used when the MAC Type is
set to Split-MAC.
4 - Native Bridging: Native Bridging requires the WTP and AC to 4.4.14. Decryption Error Report
encapsulate all user payloads as native wireless frames, as
defined by the wireless binding (see Section 4.2).
7 - All: The WTP is capable of supporting all frame types. The Decryption Error Report message element value is used by the WTP
to inform the AC of decryption errors that have occurred since the
last report. Note that this error reporting mechanism is not used if
encryption and decryption services are provided via the AC.
5.2. Discovery Response 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 |Num Of Entries | Mobile MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Discovery Response message provides a mechanism for an AC to Type: 14 for Decryption Error Report
advertise its services to requesting WTPs.
Discovery Response messages are sent by an AC after receiving a Length: >= 8
Discovery Request message from a WTP.
When a WTP receives a Discovery Response message, it MUST wait for an Radio ID: The Radio Identifier, which typically refers to an
interval not less than DiscoveryInterval for receipt of additional interface index on the WTP
Discovery Response messages. After the DiscoveryInterval elapses, Num Of Entries: An 8-bit unsigned integer indicating the number of
the WTP enters the DTLS-Init state and selects one of the ACs that mobile MAC addresses.
sent a Discovery Response message and send a DTLS Handshake to that
AC.
The following subsections define the message elements that MUST be Mobile MAC Address: An array of mobile station MAC addresses that
included in the Discovery Response Message. have caused decryption errors.
5.2.1. AC Address 4.4.15. Decryption Error Report Period
The AC address message element is used to communicate the identity of The Decryption Error Report Period message element value is used by
the AC. The value contains two fields, as shown. the AC to inform the WTP how frequently it should send decryption
error report messages.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report Period
Length: 3
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP
Report Interval: A 16-bit unsigned integer indicating the time, in
seconds
4.4.16. Delete MAC ACL Entry
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAC Address | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for AC Address Type: 16 for Delete MAC ACL Entry
Length: 7 Length: >= 7
Num of Entries: The number of MAC Addresses in the array.
Reserved: MUST be set to zero MAC Address: An array of MAC Addresses to delete from the ACL.
Mac Address: The MAC Address of the AC 4.4.17. Delete Mobile Station
5.2.2. AC Descriptor 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 AC payload message element is used by the AC to communicate it's The transmission of a Delete Mobile Station message element could
current state. The value contains the following fields. occur for various reasons, including for administrative reasons, as a
result of the fact that the mobile has roamed to another WTP, etc.
Once access has been terminated for a given station, any future
packets received from the mobile station must result in a
deauthenticate message, as specified in [6].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Hardware Version ... | | Radio ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Ver | Software Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Ver | Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit | Radios | Max Radio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radio | Security | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Descriptor Type: 17 for Delete Mobile Station
Length: 18 Length: 7
Reserved: MUST be set to zero Radio ID: An 8-bit value representing the radio
Hardware Version: The AC's hardware version number
Software Version: The AC's Firmware version number MAC Address: The mobile station's MAC Address
Stations: The number of mobile stations currently associated with 4.4.18. Delete Static MAC ACL Entry
the AC
Limit: The maximum number of stations supported by the AC 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
that the WTP provides service to the MAC addresses provided in the
message.
Radios: The number of WTPs currently attached to 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Max Radio: The maximum number of WTPs supported by the AC Type: 18 for Delete Static MAC ACL Entry
Security: A 8 bit bit mask specifying the authentication credential Length: >= 7
type supported by the AC. The following values are supported (see
Section 10):
1 - X.509 Certificate Based Num of Entries: The number of MAC Addresses in the array.
2 - Pre-Shared Secret MAC Address: An array of MAC Addresses to delete from the static MAC
ACL entry.
5.2.3. AC Name 4.4.19. Discovery Type
The AC name message element contains an ASCII representation of the The Discovery message element is used to configure a WTP to operate
AC's identity. The value is a variable length byte string. The in a specific mode.
string is NOT zero terminated.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Name ... | Discovery Type|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 31 for AC Name Type: 19 for Discovery Type
Length: > 0 Length: 1
Name: A variable length ASCII string containing the AC's name Discovery Type: An 8-bit value indicating how the AC was discovered.
The following values are supported:
5.2.4. WTP Manager Control IPv4 Address 0 - Broadcast
The WTP Manager Control IPv4 Address message element is sent by the 1 - Configured
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 4.4.20. Duplicate IPv4 Address
WTPs connected. In the event that multiple WTP Manager Control IPV4
Address message elements are returned, the WTP is expected to perform The Duplicate IPv4 Address message element is used by a WTP to inform
load balancing across the multiple interfaces. an AC that it has detected another IP device using the same IP
address it is currently using.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 20 for Duplicate IPv4 Address
Type: 99 for WTP Manager Control IPv4 Address Length: 10
Length: 6
IP Address: The IP Address of an interface. IP Address: The IP Address currently used by the WTP.
WTP Count: The number of WTPs currently connected to the interface. MAC Address: The MAC Address of the offending device.
5.2.5. WTP Manager Control IPv6 Address 4.4.21. Duplicate IPv6 Address
The WTP Manager Control IPv6 Address message element is sent by the The Duplicate IPv6 Address message element is used by a WTP to inform
AC to the WTP during the discovery process and is used by the AC to an AC that it has detected another host using the same IP address it
provide the interfaces available on the AC, and the current number of is currently using.
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 142 for WTP Manager Control IPv6 Address Type: 21 for Duplicate IPv6 Address
Length: 18 Length: 22
IP Address: The IP Address of an interface. IP Address: The IP Address currently used by the WTP.
WTP Count: The number of WTPs currently connected to the interface. MAC Address: The MAC Address of the offending device.
5.3. Primary Discovery Request 4.4.22. Idle Timeout
The Primary Discovery Request message is sent by the WTP to determine The Idle Timeout message element is sent by the AC to the WTP to
whether its preferred (or primary) AC is available. provide it with the idle timeout that it should enforce on its active
mobile station entries.
A Primary Discovery Request message is sent by a WTP when it has a 0 1 2 3
primary AC configured, and is connected to another AC. This 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
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 | Timeout |
consequence, this message is only sent by a WTP when it is in the Run +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
state.
The frequency of the Primary Discovery Request messages should be no Type: 22 for Idle Timeout
more often than the sending of the Echo Request message.
Upon receipt of a Discovery Request message, the AC responds with a Length: 4
Primary Discovery Response message sent to the address in the source
address of the received Primary Discovery Request message.
The following subsections define the message elements that MUST be Timeout: The current idle timeout to be enforced by the WTP.
included in the Primary Discovery message.
5.3.1. Discovery Type 4.4.23. Image Data
The Discovery Type message element is defined in Section 5.1.1. The image data message element is present in the Image Data Request
message sent by the AC and contains the following fields.
5.3.2. WTP Descriptor 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Checksum | Image Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Image Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WTP Descriptor message element is defined in Section 5.1.2. Type: 23 for Image Data
5.3.3. WTP MAC Type Length: >= 4 (allows 0 length element if last data unit is 1024
bytes)
The Discovery Type message element is defined in Section 5.1.4. Opcode: An 8-bit value representing the transfer opcode. The
following values are supported:
5.3.4. WTP Frame Type 3 - Image data is included
The WTP Frame Type message element is defined in Section 5.1.5. 5 - An error occurred. Transfer is aborted
5.3.5. WTP Radio Information Checksum: A 16-bit value containing a checksum of the image data
that follows
A WTP Radio Information message element must be present for every Image Data: The Image Data field contains 1024 characters, unless
radio in the WTP. This message element is defined in Section 5.1.3. 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
is sent.
5.4. Primary Discovery Response 4.4.24. Image Filename
The Primary Discovery Response message enables an AC to advertise its The image filename message element is sent by the WTP to the AC and
availability and services to requesting WTPs that are configured to is used to initiate the firmware download process. This message
have the AC as its primary AC. element contains the image filename, which the AC subsequently
transfers to the WTP via the Image Data message element. The value
is a variable length byte string, which is NOT zero terminated.
Primary Discovery Response messages are sent by an AC after receiving 0 1 2 3
a Primary Discovery Request message. 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a WTP receives a Primary Discovery Response message, it may Type: 24 for Image Filename
establish a CAPWAP protocol connection to its primary AC, based on
the configuration of the WTP Fallback Status message element on the
WTP.
The following subsections define the message elements that MUST be Length: >= 1
included in the Primary Discovery Request message.
5.4.1. AC Descriptor Filename: A variable length string containing the filename to
download.
The Discovery Type message element is defined in Section 5.2.2. 4.4.25. Initiate Download
5.4.2. AC Name 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
having the WTP initiate its own Image Data Request, with the Image
Download message element. This message element does not contain any
data.
The AC Name message element is defined in Section 5.2.3. Type: 25 for Initiate Download
5.4.3. WTP Manager Control IPv4 Address Length: 0
A WTP Radio Information message element MAY be present for every 4.4.26. Location Data
radio in the WTP which are reachable via IPv4. This message element
is defined in Section 5.2.4.
5.4.4. WTP Manager Control IPv6 Address The Location Data message elementis a variable length byte string
containing user defined location information (e.g. "Next to
Fridge"). This information is configurable by the network
administrator, and allows for the WTP location to be determined
through this field. The string is not zero terminated.
A WTP Radio Information message element must be present for every 0
radio in the WTP which are reachable via IPv6. This message element 0 1 2 3 4 5 6 7
is defined in Section 5.2.5. +-+-+-+-+-+-+-+-+-
| Location ...
+-+-+-+-+-+-+-+-+-
6. Control Channel Management Type: 26 for Location Data
The Control Channel Management messages are used by the WTP and AC to Length: > 0
maintain a control communication channel.
6.1. Echo Request Timeout: A non-zero terminated string containing the WTP location.
The Echo Request message is a keep alive mechanism for CAPWAP control 4.4.27. MTU Discovery Padding
messages.
Echo Request messages are sent periodically by a WTP in the Run state The MTU Discovery Padding message element is used as padding to
(see Section 2.2) to determine the state of the connection between perform MTU discovery, and MUST contain octets of value 0xFF, of any
the WTP and the AC. The Echo Request message is sent by the WTP when length
the Heartbeat timer expires. The WTP MUST start its
NeighborDeadInterval timer when the Heartbeat timer expires.
The Echo Request message carries no message elements. 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding...
+-+-+-+-+-+-+-+-
When an AC receives an Echo Request message it responds with an Echo Type: 27 for MTU Discovery Padding
Response message.
6.2. Echo Response Length: variable
The Echo Response message acknowledges the Echo Request message, and Timeout: A variable length pad.
is only processed while in the Run state (see Section 2.2).
An Echo Response message is sent by an AC after receiving an Echo 4.4.28. Radio Administrative State
Request message. After transmitting the Echo Response message, the
AC SHOULD reset its Heartbeat timer to expire in the value configured
for EchoInterval. If another Echo Request message is not received by
the AC when the timer expires, the AC SHOULD consider the WTP to be
no longer be reachable.
The Echo Response message carries no message elements. The administrative event message element is used to communicate the
state of a particular radio. The value contains the following
fields.
When a WTP receives an Echo Response message it stops the 0 1
NeighborDeadInterval timer, and initializes the Heartbeat timer to 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
the EchoInterval. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the NeighborDeadInterval timer expires prior to receiving an Echo Type: 28 for Administrative State
Response message, the WTP enters the Idle state.
7. WTP Configuration Management Length: 2
Wireless Termination Point Configuration messages are used to Radio ID: An 8-bit value representing the radio to configure. The
exchange configuration information between the AC and the WTP. Radio ID field may also include the value of 0xff, which is used
to identify the WTP itself. Therefore, if an AC wishes to change
the administrative state of a WTP, it would include 0xff in the
Radio ID field.
7.1. Configuration Consistency Admin State: An 8-bit value representing the administrative state of
the radio. The following values are supported:
The CAPWAP protocol provides flexibility in how WTP configuration is 1 - Enabled
managed. A WTP has two options: 2 - Disabled
1. The WTP retains no configuration and accepts the configuration 4.4.29. Result Code
provided by the AC.
2. The WTP retains the configuration of parameters provided by the AC The Result Code message element value is a 32-bit integer value,
that are non-default values. indicating the result of the request operation corresponding to the
sequence number in the message.
If the WTP opts to save configuration locally, the CAPWAP protocol 0 1 2 3
state machine defines the Configure state, which allows for 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
configuration exchange. In the Configure state, the WTP sends its +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
current configuration overrides to the AC via the Configure Request | Result Code |
message. A configuration override is a parameter that is non- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
default. One example is that in the CAPWAP protocol, the default
antenna configuration is internal omni antenna. A WTP that either
has no internal antennas, or has been explicitly configured by the AC
to use external antennas, sends its antenna configuration during the
configure phase, allowing the AC to become aware of the WTP's current
configuration.
Once the WTP has provided its configuration to the AC, the AC sends Type: 29 for Result Code
its own configuration. This allows the WTP to inherit the
configuration and policies from the AC.
An AC maintains a copy of each active WTP's configuration. There is Length: 4
no need for versioning or other means to identify configuration
changes. If a WTP becomes inactive, the AC MAY delete the
configuration associated with it. If a WTP fails, and connects to a
new AC, it provides its overridden configuration parameters, allowing
the new AC to be aware of the WTP's configuration.
This model allows for resiliency in case of an AC failure, that Result Code: The following values are defined:
another AC can provide service to the WTP. In this scenario, the new
AC would be automatically updated with WTP configuration changes,
eliminating the need for inter-AC communication or the need for all
ACs to be aware of the configuration of all WTPs in the network.
Once the CAPWAP protocol enters the Run state, the WTPs begin to 0 Success
provide service. It is quite common for administrators to require
that configuration changes be made while the network is operational.
Therefore, the Configuration Update Request is sent by the AC to the 1 Failure (AC List message element MUST be present)
WTP to make these changes at run-time.
7.1.1. Configuration Flexibility 2 Success (NAT detected)
The CAPWAP protocol provides the flexibility to configure and manage 3 Failure (unspecified)
WTPs of varying design and functional characteristics. When a WTP
first discovers an AC, it provides primary functional information
relating to its type of MAC and to the nature of frames to be
exchanged. The AC configures the WTP appropriately. The AC also
establishes corresponding internal operations to deal with the WTP
according to its functionalities.
7.2. Configure Request 4 Failure (Join Failure, Resource Depletion)
The Configure Request message is sent by a WTP to deliver its current 5 Failure (Join Failure, Unknown Source)
configuration to its AC.
Configure Request messages are sent by a WTP while in the Configure 6 Failure (Join Failure, Incorrect Data)
state.
The Configure Request message carries binding specific message 7 Failure (Join Failure, Session ID already in use)
elements. Refer to the appropriate binding for the definition of
this structure.
When an AC receives a Configure Request message it will act upon the 4.4.30. Session ID
content of the packet and respond to the WTP with a Configure
Response message.
The Configure Request message includes multiple Administrative State The session ID message element value contains a randomly generated
message Elements. There is one such message element for the WTP, and unsigned 32-bit integer.
one message element per radio in the WTP.
The following subsections define the message elements that MUST be 0 1 2 3
included in the Configure Request message. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for Session ID
7.2.1. Administrative State Length: 4
The administrative event message element is used to communicate the Session ID: A 32-bit random session identifier
state of a particular radio. The value contains the following
fields. 4.4.31. Statistics Timer
The statistics timer message element value is used by the AC to
inform the WTP of the frequency which it expects to receive updated
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State | | Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 27 for Administrative State
Type: 31 for Statistics Timer
Length: 2 Length: 2
Radio ID: An 8-bit value representing the radio to configure. The Statistics Timer: A 16-bit unsigned integer indicating the time, in
Radio ID field may also include the value of 0xff, which is used seconds
to identify the WTP itself. Therefore, if an AC wishes to change
the administrative state of a WTP, it would include 0xff in the
Radio ID field.
Admin State: An 8-bit value representing the administrative state of 4.4.32. Vendor Specific Payload
the radio. The following values are supported:
1 - Enabled The Vendor Specific Payload is used to communicate vendor specific
information between the WTP and the AC. The value contains the
following format:
2 - Disabled 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.2.2. AC Name Type: 32 for Vendor Specific
The AC Name message element is defined in Section Section 5.2.3. Length: >= 7
7.2.3. AC Name with Index Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" [19]
Element ID: A 16-bit Element Identifier which is managed by the
vendor.
The AC Name with Index message element is sent by the AC to the WTP Value: The value associated with the vendor specific element.
to configure preferred ACs. The number of instances where this
message element would be present is equal to the number of ACs
configured on the WTP.
0 1 4.4.33. WTP Board Data
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 90 for AC Name with Index The WTP Board Data message element is sent by the WTP to the AC and
contains information about the hardware present.
Length: > 2 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional additional vendor specific WTP board data TLVs
Index: The index of the preferred server (e.g., 1=primary, Type: 33 for WTP Board Data
2=secondary).
AC Name: A variable length ASCII string containing the AC's name. Length: >=14
7.2.4. WTP Board Data Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes"
The WTP Board Data message element is sent by the WTP to the AC and Type: The following values are supported:
contains information about the hardware present.
0 - WTP Model Number: The WTP Model Number MUST be included in
the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included in
the WTP Board Data message element.
2 - Board ID: A hardware identifier, which MAY be included in the
WTP Board Data mesage element.
3 - Board Revision A revision number of the board, which MAY be
included in the WTP Board Data message element.
4.4.34. WTP Descriptor
The WTP descriptor message element is used by a WTP to communicate
it's current hardware/firmware configuration. The value contains the
following fields.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Card ID | Card Revision | | Max Radios | Radios in use | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Model | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Model | | Type=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number | | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number | | Type=1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number | | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number | | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number | | Type=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet MAC Address |
Type: 34 for WTP Descriptor
Length: >= 31
Max Radios: An 8-bit value representing the number of radios (where
each radio is identified via the RID field) supported by the WTP
Radios in use: An 8-bit value representing the number of radios
present in the WTP
Encryption Capabilities: This 16-bit field is used by the WTP to
communicate it's capabilities to the AC. Since most WTP's support
link layer encryption, the AC may make use of these services.
There are binding dependent encryption capabilities. A WTP that
does not have any encryption capabilities would set this field to
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
Network Management Private Enterprise Codes"
Type: The following values are supported. The Hardware Version,
Software Version, and Boot Version values MUST be included.
0 - WTP Model Number: The WTP Model Number MUST be included in
the WTP Board Data message element.
1 - WTP Serial Number: The WTP Serial Number MUST be included in
the WTP Board Data message element.
2 - Board ID: A hardware identifier, which MAY be included in the
WTP Board Data mesage element.
3 - Board Revision A revision number of the board, which MAY be
included in the WTP Board Data message element.
4 - Hardware Version: A 32-bit integer representing the WTP's
hardware version number
5 - Software Version: A 32-bit integer representing the WTP's
Firmware version number
6 - Boot Version: A 32-bit integer representing the WTP's boot
loader's version number
4.4.35. WTP Fallback
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
detects its preferred AC, and is not currently connected to it.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
Type: 35 for WTP Fallback
Length: 1
Mode: The 8-bit value indicates the status of automatic CAPWAP
fallback on the WTP. A value of zero disables fallback, while a
value of one enables it. When enabled, if the WTP detects that
its primary AC is available, and it is not connected to it, it
SHOULD automatically disconnect from its current AC and reconnect
to its primary. If disabled, the WTP will only reconnect to its
primary through manual intervention (e.g., through the Reset
Request command).
4.4.36. WTP Frame Encapsulation Type
The WTP Frame EncapsultationType message element allows the WTP to
communicate the encapsulation type, or tunneling modes of operation
which it supports to the AC. A WTP that advertises support for all
types allows the AC to select which type will be used, based on its
local policy.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Frame Enc Type |
+-+-+-+-+-+-+-+-+
Type: 36 for WTP Frame Encapsulation Type
Length: 1
Frame Encapsulation Type: The Frame type specifies the encapsulation
modes supported by the WTP. The following values are supported:
1 - Local Bridging: Local Bridging allows the WTP to perform the
bridging function. This value MUST NOT be used when the WTP
MAC Type is set to Split-MAC.
2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to
encapsulate all user payload as native IEEE 802.3 frames (see
Section 4.2). This value MUST NOT be used when the WTP MAC
Type is set to Split-MAC.
4 - Native Bridging: Native Bridging requires the WTP and AC to
encapsulate all user payloads as native wireless frames, as
defined by the wireless binding (see Section 4.2).
7 - All: The WTP is capable of supporting all frame encapsulation
types.
4.4.37. WTP IPv4 IP Address
The WTP IPv4 address is used to perform NAT detection.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP IPv4 IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 50 for WTP Board Data Type: 37 for WTP IPv4 IP Address
Length: 26 Length: 4
Card ID: A 2 byte hardware identifier. WTP IPv4 IP Address: The IPv4 address from which the WTP is sending
packets. This field is used for NAT detection.
Card Revision: A 2 byte Revision of the card. 4.4.38. WTP MAC Type
WTP Model: 8 byte WTP Model Number. 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
modes allows the AC to select the mode to use, based on local policy.
WTP Serial Number: 24 byte WTP Serial Number. 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MAC Type |
+-+-+-+-+-+-+-+-+
Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. Type: 38 for WTP MAC Type
7.2.5. Statistics Timer Length: 1
The statistics timer message element value is used by the AC to MAC Type: The MAC mode of operation supported by the WTP. The
inform the WTP of the frequency which it expects to receive updated following values are supported
statistics.
0 1 0 - Local-MAC: Local-MAC is the default mode that MUST be
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 supported by all WTPs.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer | 1 - Split-MAC: Split-MAC support is optional, and allows the AC
to receive and process native wireless frames.
2 - Both: WTP is capable of supporting both Local-MAC and Split-
MAC.
4.4.39. 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: 39 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.40. 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: 37 for Statistics Timer Type: 40 for WTP Manager Control IPv4 Address
Length: 2 Length: 6
Statistics Timer: A 16-bit unsigned integer indicating the time, in IP Address: The IP Address of an interface.
seconds
7.2.6. WTP Static IP Address Information WTP Count: The number of WTPs currently connected to the interface.
The WTP Static IP Address Information message element is used by an 4.4.41. WTP Manager Control IPv6 Address
AC to configure or clear a previously configured static IP address on
a WTP. 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static | | IP Address |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 82 for WTP Static IP Address Information Type: 41 for WTP Manager Control IPv6 Address
Length: 13 Length: 18
IP Address: The IP Address of an interface.
IP Address: The IP Address to assign to the WTP. This field is only WTP Count: The number of WTPs currently connected to the interface.
valid if the static field is set to one.
Netmask: The IP Netmask. This field is only valid if the static 4.4.42. WTP Name
field is set to one.
Gateway: The IP address of the gateway. This field is only valid if The WTP Name message element is a variable length bye string. The
the static field is set to one. string is not zero terminated.
Netmask: The IP Netmask. This field is only valid if the static 0
field is set to one. 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| WTP Name ...
+-+-+-+-+-+-+-+-+-
Static: An 8-bit boolean stating whether the WTP should use a static Type: 42 for WTP Name
IP address or not. A value of zero disables the static IP
address, while a value of one enables it.
7.2.7. WTP Reboot Statistics Length: variable
WTP Name: A non-zero terminated string containing the WTP name.
4.4.43. 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
AC to communicate reasons why reboots have occurred. AC to communicate reasons why reboots have occurred.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crash Count | CAPWAP Initiated Count | | Crash Count | CAPWAP Initiated Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Failure Count | Failure Type | | Link Failure Count | Failure Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 67 for WTP Reboot Statistics Type: 43 for WTP Reboot Statistics
Length: 7 Length: 7
Crash Count: The number of reboots that have occurred due to a WTP Crash Count: The number of reboots that have occurred due to a WTP
crash. A value of 65535 implies that this information is not crash. A value of 65535 implies that this information is not
available on the WTP. available on the WTP.
CAPWAP Initiated Count: The number of reboots that have occurred at CAPWAP Initiated Count: The number of reboots that have occurred at
the request of a CAPWAP protocol message, such as a change in the request of a CAPWAP protocol message, such as a change in
configuration that required a reboot or an explicit CAPWAP reset configuration that required a reboot or an explicit CAPWAP reset
skipping to change at page 49, line 44 skipping to change at page 70, line 13
available on the WTP. available on the WTP.
Link Failure Count: The number of times that a CAPWAP protocol Link Failure Count: The number of times that a CAPWAP protocol
connection with an AC has failed. connection with an AC has failed.
Failure Type: The last WTP failure. The following values are Failure Type: The last WTP failure. The following values are
supported: supported:
0 - Link Failure 0 - Link Failure
1 - CAPWAP Initiated (see Section 8.3) 1 - CAPWAP Initiated (see Section 9.3)
2 - WTP Crash 2 - WTP Crash
255 - Unknown (e.g., WTP doesn't keep track of info) 255 - Unknown (e.g., WTP doesn't keep track of info)
7.3. Configure Response 4.4.44. WTP Static IP Address Information
The Configure Response message is sent by an AC and provides a The WTP Static IP Address Information message element is used by an
mechanism for the AC to override a WTP's requested configuration. AC to configure or clear a previously configured static IP address on
a WTP.
Configure Response messages are sent by an AC after receiving a 0 1 2 3
Configure Request message. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static |
+-+-+-+-+-+-+-+-+
The Configure Response message carries binding specific message Type: 44 for WTP Static IP Address Information
elements. Refer to the appropriate binding for the definition of
this structure.
When a WTP receives a Configure Response message it acts upon the Length: 13
content of the message, as appropriate. If the Configure Response
message includes a Change State Event message element that causes a
change in the operational state of one of the Radio, the WTP will
transmit a Change State Event to the AC, as an acknowledgement of the
change in state.
The following subsections define the message elements that MUST be IP Address: The IP Address to assign to the WTP. This field is only
included in the Configure Response message. valid if the static field is set to one.
7.3.1. Decryption Error Report Period Netmask: The IP Netmask. This field is only valid if the static
field is set to one.
The Decryption Error Report Period message element value is used by Gateway: The IP address of the gateway. This field is only valid if
the AC to inform the WTP how frequently it should send decryption the static field is set to one.
error report messages.
0 1 2 Netmask: The IP Netmask. This field is only valid if the static
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 field is set to one.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for Decryption Error Report Period Static: An 8-bit boolean stating whether the WTP should use a static
IP address or not. A value of zero disables the static IP
address, while a value of one enables it.
Length: 3 4.5. CAPWAP Protocol Timers
Radio ID: The Radio Identifier, typically refers to some interface A WTP or AC that implements CAPWAP discovery MUST implement the
index on the WTP following timers.
Report Interval: A 16-bit unsigned integer indicating the time, in 4.5.1. DiscoveryInterval
seconds
7.3.2. Change State Event The minimum time, in seconds, that a WTP MUST wait after receiving a
Discovery Response, before initiating a DTLS handshake.
The Change State message element is used to communicate a change in Default: 5
the operational state of a radio. The value contains two fields, as
shown.
0 1 4.5.2. DTLSRehandshake
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Change State Event The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to
complete.
Length: 3 Default: 10
Radio ID: The Radio Identifier, typically refers to some interface 4.5.3. DTLSSessionDelete
index on the WTP.
State: An 8-bit boolean value representing the state of the radio. The minimum time, in seconds, a WTP MUST wait for DTLS session
A value of one disables the radio, while a value of two enables deletion.
it.
Cause: In the event of a radio being inoperable, the cause field Default: 5
would contain the reason the radio is out of service.
Cause: In the event of a radio being inoperable, the cause field 4.5.4. EchoInterval
would contain the reason the radio is out of service. The
following values are supported:
0 - Normal The minimum time, in seconds, between sending echo requests to the AC
with which the WTP has joined.
1 - Radio Failure Default: 30
2 - Software Failure 4.5.5. KeyLifetime
7.3.3. CAPWAP Timers The maximum time, in seconds, which a CAPWAP DTLS session key is
valid.
The CAPWAP Timers message element is used by an AC to configure Default: 28800
CAPWAP timers on a WTP.
0 1 4.5.6. MaxDiscoveryInterval
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 68 for CAPWAP Timers The maximum time allowed between sending discovery requests from the
Length: 2 interface, in seconds. Must be no less than 2 seconds and no greater
than 180 seconds.
Discovery: The number of seconds between CAPWAP Discovery packets, Default: 20 seconds.
when the WTP is in the discovery mode.
Echo Request: The number of seconds between WTP Echo Request CAPWAP 4.5.7. NeighborDeadInterval
messages.
7.3.4. AC IPv4 List The minimum time, in seconds, a WTP MUST wait without having received
Echo Responses to its Echo Requests, before the destination for the
Echo Request may be considered dead. Must be no less than
2*EchoInterval seconds and no greater than 240 seconds.
The AC List message element is used to configure a WTP with the Default: 60
latest list of ACs in a cluster.
0 1 2 3 4.5.8. ResponseTimeout
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[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 59 for AC List The minimum time, in seconds, which the WTP or AC must respond to a
CAPWAP Request message.
Length: 4 Default: 1
The AC IP Address: An array of 32-bit integers containing an AC's 4.5.9. RetransmitInterval
IPv4 Address.
7.3.5. AC IPv6 List The minimum time, in seconds, which a non-acknowledged CAPWAP packet
will be retransmitted.
The AC List message element is used to configure a WTP with the Default: 3
latest list of ACs in a cluster.
0 1 2 3 4.5.10. SilentInterval
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[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 141 for AC IPV6 List
Length: 16 The minimum time, in seconds, a WTP MUST wait after failing to
receive any responses to its discovery requests, before it MAY again
send discovery requests.
The AC IP Address: An array of 32-bit integers containing an AC's Default: 30
IPv6 Address.
7.3.6. WTP Fallback 4.5.11. WaitJoin
The WTP Fallback message element is sent by the AC to the WTP to The maximum time, in seconds, a WTP MUST wait without having received
enable or disable automatic CAPWAP fallback in the event that a WTP a DTLS Handshake message from an AC. This timer must be greater than
detects its preferred AC, and is not currently connected to it. 30 seconds.
0 Default: 60
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
Type: 91 for WTP Fallback 4.6. CAPWAP Protocol Variables
Length: 1 A WTP or AC that implements CAPWAP discovery MUST allow for the
following variables to be configured by system management; default
values are specified so as to make it unnecessary to configure any of
these variables in many cases.
Mode: The 8-bit value indicates the status of automatic CAPWAP 4.6.1. DiscoveryCount
fallback on the WTP. A value of zero disables fallback, while a
value of one enables it. When enabled, if the WTP detects that
its primary AC is available, and it is not connected to it, it
SHOULD automatically disconnect from its current AC and reconnect
to its primary. If disabled, the WTP will only reconnect to its
primary through manual intervention (e.g., through the Reset
Request command).
7.3.7. Idle Timeout The number of discoveries transmitted by a WTP to a single AC. This
is a monotonically increasing counter.
The Idle Timeout message element is sent by the AC to the WTP to 4.6.2. MaxDiscoveries
provide it with the idle timeout that it should enforce on its active
mobile station entries.
0 1 2 3 The maximum number of discovery requests that will be sent after a
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 boots.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 97 for Idle Timeout
Length: 4 Default: 10
Timeout: The current idle timeout to be enforced by the WTP. 4.6.3. MaxRetransmit
7.4. Configuration Update Request The maximum number of retransmissions for a given CAPWAP packet
before the link layer considers the peer dead.
Configure Update Request messages are sent by the AC to provision the Default: 5
WTP while in the Run state. This is used to modify the configuration
of the WTP while it is operational.
When an AC receives a Configuration Update Request message it will 4.6.4. RetransmitCount
respond with a Configuration Update Response message, with the
appropriate Result Code.
The following subsections define the message elements included in the The number of retransmissions for a given CAPWAP packet. This is a
Configuration Update message. monotonically increasing counter.
7.4.1. WTP Name 5. CAPWAP Discovery Operations
The WTP Name message element is a variable length bye string. The The Discovery messages are used by a WTP to determine which ACs are
string is not zero terminated. available to provide service, and the capabilities and load of the
ACs.
0 5.1. Discovery Request Message
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| WTP Name ...
+-+-+-+-+-+-+-+-+-
Type: 5 for WTP Name The Discovery Request message is used by the WTP to automatically
discover potential ACs available in the network. The Discovery
Request message provides ACs with the primary capabilities of the
WTP. A WTP must exchange this information to ensure subsequent
exchanges with the ACs are consistent with the WTP's functional
characteristics. A WTP must transmit this command even if it has a
statically configured AC.
Length: 0 Discovery Request messages MUST be sent by a WTP in the Discover
state after waiting for a random delay less than
MaxDiscoveryInterval, after a WTP first comes up or is
(re)initialized. A WTP MUST send no more than the maximum of
MaxDiscoveries Discovery Request messages, waiting for a random delay
less than MaxDiscoveryInterval between each successive message.
Timeout: A non-zero terminated string containing the WTP name. This is to prevent an explosion of WTP Discovery Request messages.
An example of this occurring is when many WTPs are powered on at the
same time.
7.4.2. Change State Event Discovery Request messages MUST be sent by a WTP when no Echo
Response messages are received for NeighborDeadInterval and the WTP
returns to the Idle state. Discovery Request messages are sent after
NeighborDeadInterval. They MUST be sent after waiting for a random
delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum
of MaxDiscoveries Discovery Request messages, waiting for a random
delay less than MaxDiscoveryInterval between each successive message.
The Change State Event message element is defined in Section If a Discovery Response message is not received after sending the
Section 7.3.2. maximum number of Discovery Request messages, the WTP enters the
Sulking state and MUST wait for an interval equal to SilentInterval
before sending further Discovery Request messages.
7.4.3. Administrative State The Discovery Request message may be sent as a unicast, broadcast or
multicast message.
The Administrative State message element is defined in Section Upon receiving a Discovery Request message, the AC will respond with
Section 7.2.1. a Discovery Response message sent to the address in the source
address of the received discovery request message.
7.4.4. Statistics Timer The following message elements MUST be included in the Discovery
Request message:
The Statistics Timer message element is defined in Section o Discovery Type, see Section 4.4.19
Section 7.2.5.
7.4.5. Location Data o WTP Descriptor, see Section 4.4.34
The Location Data message elementis a variable length byte string o WTP Frame Type, see Section 4.4.36
containing user defined location information (e.g. "Next to
Fridge"). This information is configurable by the network
administrator, and allows for the WTP location to be determined
through this field. The string is not zero terminated.
0 o WTP MAC Type, see Section 4.4.38
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| Location ...
+-+-+-+-+-+-+-+-+-
Type: 35 for Location Data o WTP Radio Information, see Section 4.4.39
Length: 0 5.2. Discovery Response Message
Timeout: A non-zero terminated string containing the WTP location. The Discovery Response message provides a mechanism for an AC to
advertise its services to requesting WTPs.
7.4.6. Decryption Error Report Period The Discovery Response message is sent by an AC after receiving a
Discovery Request message from a WTP.
The Decryption Error Report Period message element is defined in When a WTP receives a Discovery Response message, it MUST wait for an
Section 7.3.1. interval not less than DiscoveryInterval for receipt of additional
Discovery Response messages. After the DiscoveryInterval elapses,
the WTP enters the DTLS-Init state and selects one of the ACs that
sent a Discovery Response message and send a DTLS Handshake to that
AC.
7.4.7. AC IPv4 List The following message elements MUST be included in the Discovery
Response Message:
The AC List message element is defined in Section 7.3.4. o AC Descriptor, see Section 4.4.1
7.4.8. AC IPv6 List o AC Name, see Section 4.4.4
The AC List message element is defined in Section 7.3.5. o WTP Manager Control IPv4 Address, see Section 4.4.40
7.4.9. Add MAC ACL Entry o WTP Manager Control IPv6 Address, see Section 4.4.41
The Add MAC Access Control List (ACL) Entry message element is used 5.3. Primary Discovery Request Message
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
message. The MAC Addresses provided in this message element are not
expected to be saved in non-volatile memory on the WTP.
0 1 2 3 The Primary Discovery Request message is sent by the WTP to determine
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 whether its preferred (or primary) AC is available.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 65 for Add MAC ACL Entry A Primary Discovery Request message is sent by a WTP when it has a
primary AC configured, and is connected to another AC. This
generally occurs as a result of a failover, and is used by the WTP as
a means to discover when its primary AC becomes available. As a
consequence, this message is only sent by a WTP when it is in the Run
state.
Length: >= 7 The frequency of the Primary Discovery Request messages should be no
more often than the sending of the Echo Request message.
Num of Entries: The number of MAC Addresses in the array. Upon receipt of a Discovery Request message, the AC responds with a
Primary Discovery Response message sent to the address in the source
address of the received Primary Discovery Request message.
MAC Address: An array of MAC Addresses to add to the ACL. The following message elements MUST be included in the Primary
Discovery Request message.
7.4.10. Delete MAC ACL Entry o Discovery Type, see Section 4.4.19
The Delete MAC ACL Entry message element is used by an AC to delete a o WTP Descriptor, see Section 4.4.34
MAC ACL entry on a WTP, ensuring that the WTP provides service to the
MAC addresses provided in the message.
0 1 2 3 o WTP Frame Type, see Section 4.4.36
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 66 for Delete MAC ACL Entry o WTP MAC Type, see Section 4.4.38
Length: >= 7 o WTP Radio Information, see Section 4.4.39 A WTP Radio Information
message element MUST be present for every radio in the WTP.
Num of Entries: The number of MAC Addresses in the array. 5.4. Primary Discovery Response
MAC Address: An array of MAC Addresses to delete from the ACL. The Primary Discovery Response message enables an AC to advertise its
availability and services to requesting WTPs that are configured to
have the AC as its primary AC.
7.4.11. Add Static MAC ACL Entry The Primary Discovery Response message is sent by an AC after
receiving a Primary Discovery Request message.
The Add Static MAC ACL Entry message element is used by an AC to add When a WTP receives a Primary Discovery Response message, it may
a permanent ACL entry on a WTP, ensuring that the WTP no longer establish a CAPWAP protocol connection to its primary AC, based on
provides any service to the MAC addresses provided in the message. the configuration of the WTP Fallback Status message element on the
The MAC Addresses provided in this message element are expected to be WTP.
saved in non-volative memory on the WTP.
0 1 2 3 The following message elements MUST be included in the Primary
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 Discovery Response message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 70 for Add Static MAC ACL Entry o AC Descriptor, see Section 4.4.1
Length: >= 7 o AC Name, see Section 4.4.4
Num of Entries: The number of MAC Addresses in the array. o WTP Manager Control IPv4 Address, see Section 4.4.40
MAC Address: An array of MAC Addresses to add to the permanent ACL. o WTP Manager Control IPv6 Address, see Section 4.4.41
7.4.12. Delete Static MAC ACL Entry 6. CAPWAP Join Operations
The Delete Static MAC ACL Entry message element is used by an AC to The Join Request message is used by a WTP to request service from an
delete a previously added static MAC ACL entry on a WTP, ensuring AC after a DTLS connection is established to that AC. The Join
that the WTP provides service to the MAC addresses provided in the Response message is used by the the AC to indicate that it will or
will not provide service.
6.1. Join Request
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
sent by a WTP after receiving one or more Discovery Responses, and
completion of DTLS session establishment. When an AC receives a Join
Request message it responds with a Join Response message.
Upon completion of the DTLS handshake (synonymous with DTLS "session
establishment"), the WTP sends the Join Request message to the AC.
Upon receipt of the Join Request Message, the AC generates a Join
Response message and sends it to the WTP, indicating success or
failure.
Upon transmission of the Join Request message, the WTP sets the
WaitJoin timer. If the Join Response message has not been received
prior to expiration, the WTP aborts the Join process and transitions
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
message MUST be silently discarded by the AC. No response is sent to
the WTP. The AC SHOULD log this event.
The following message elements MUST be included in the Join Request
message. message.
0 1 2 3 o Location Data, see Section 4.4.26
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 71 for Delete MAC ACL Entry o Session ID, see Section 4.4.30
o WTP Descriptor, see Section 4.4.34
Length: >= 7 o WTP IPv4 IP Address, see Section 4.4.37
Num of Entries: The number of MAC Addresses in the array. o WTP Name, see Section 4.4.42
MAC Address: An array of MAC Addresses to delete from the static MAC o WTP Radio Information, see Section 4.4.39 A WTP Radio Information
ACL entry. message element MUST be present for every radio in the WTP.
7.4.13. CAPWAP Timers 6.2. Join Response
The CAPWAP Timers message element is defined in Section 7.3.3. 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.
7.4.14. AC Name with Index After determining that a WTP should join the AC, the AC creates
session state containing the WTP address, port and session ID, sets
the WaitJoin timer for the session, sends the Join Response message
to the WTP.
The AC Name with Index message element is defined in Section 7.2.3. The WTP, receiving a Join Response message checks for success or
failure. If the message indicates success, the WTP clears the
WaitJoin timer for the session and proceeds to the Configure or Image
Data state. Otherwise, the WTP enters the CAPWAP reset state,
resulting in shutdown of the DTLS session.
7.4.15. WTP Fallback If the WaitJoin Timer expires prior to reception of the Join Response
message, the WTP MUST terminate the handshake, deallocate associated
session state and transition to the Discover state.
The WTP Fallback message element is defined in Section 7.3.6. If an invalid (malformed) Join Response message is received, the WTP
SHOULD log an informative message detailing the error. This error
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
may (if it is so configured) attempt to join with an alternative AC.
7.4.16. Idle Timeout The following message elements MAY be included in the Join Response
message.
The Idle Timeout message element is defined in Section 7.3.7. o Result Code, see Section 4.4.29
7.4.17. Timestamp o AC IPv4 List, see Section 4.4.2
The Timestamp message element is sent by the AC to to synchronize the o AC IPv6 List, see Section 4.4.3
WTP's clock.
0 1 2 3 o Session ID, see Section 4.4.30
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD for Timestamp 7. Control Channel Management
Length: 4 The Control Channel Management messages are used by the WTP and AC to
maintain a control communication channel.
Timestamp: The AC's current time, allowing all of the WTPs to be 7.1. Echo Request
time synchronized in the format defined by Network Time Protocol
(NTP) in RFC 1305 [10].
7.5. Configuration Update Response The Echo Request message is a keep alive mechanism for CAPWAP control
messages.
Echo Request messages are sent periodically by a WTP in the Run state
(see Section 2.3) to determine the state of the connection between
the WTP and the AC. The Echo Request message is sent by the WTP when
the Heartbeat timer expires. The WTP MUST start its
NeighborDeadInterval timer when the Heartbeat timer expires.
The Echo Request message carries no message elements.
When an AC receives an Echo Request message it responds with an Echo
Response message.
7.2. Echo Response
The Echo Response message acknowledges the Echo Request message, and
is only processed while in the Run state (see Section 2.3).
An Echo Response message is sent by an AC after receiving an Echo
Request message. After transmitting the Echo Response message, the
AC SHOULD reset its Heartbeat timer to expire in the value configured
for EchoInterval. If another Echo Request message or other control
message is not received by the AC when the timer expires, the AC
SHOULD consider the WTP to be no longer be reachable.
The Echo Response message carries no message elements.
When a WTP receives an Echo Response message it stops the
NeighborDeadInterval timer, and initializes the Heartbeat timer to
the EchoInterval.
If the NeighborDeadInterval timer expires prior to receiving an Echo
Response message, or other control message, the WTP enters the Idle
state.
8. WTP Configuration Management
Wireless Termination Point Configuration messages are used to
exchange configuration information between the AC and the WTP.
8.1. Configuration Consistency
The CAPWAP protocol provides flexibility in how WTP configuration is
managed. A WTP has two options:
1. The WTP retains no configuration and accepts the configuration
provided by the AC.
2. The WTP retains the configuration of parameters provided by the AC
that are non-default values.
If the WTP opts to save configuration locally, the CAPWAP protocol
state machine defines the Configure state, which allows for
configuration exchange. In the Configure state, the WTP sends its
current configuration overrides to the AC via the Configuration
Status message. A configuration override is a parameter that is non-
default. One example is that in the CAPWAP protocol, the default
antenna configuration is internal omni antenna. A WTP that either
has no internal antennas, or has been explicitly configured by the AC
to use external antennas, sends its antenna configuration during the
configure phase, allowing the AC to become aware of the WTP's current
configuration.
Once the WTP has provided its configuration to the AC, the AC sends
its own configuration. This allows the WTP to inherit the
configuration and policies from the AC.
An AC maintains a copy of each active WTP's configuration. There is
no need for versioning or other means to identify configuration
changes. If a WTP becomes inactive, the AC MAY delete the
configuration associated with it. If a WTP fails, and connects to a
new AC, it provides its overridden configuration parameters, allowing
the new AC to be aware of the WTP's configuration.
This model allows for resiliency in case of an AC failure, that
another AC can provide service to the WTP. In this scenario, the new
AC would be automatically updated with WTP configuration changes,
eliminating the need for inter-AC communication or the need for all
ACs to be aware of the configuration of all WTPs in the network.
Once the CAPWAP protocol enters the Run state, the WTPs begin to
provide service. It is quite common for administrators to require
that configuration changes be made while the network is operational.
Therefore, the Configuration Update Request is sent by the AC to the
WTP to make these changes at run-time.
8.1.1. Configuration Flexibility
The CAPWAP protocol provides the flexibility to configure and manage
WTPs of varying design and functional characteristics. When a WTP
first discovers an AC, it provides primary functional information
relating to its type of MAC and to the nature of frames to be
exchanged. The AC configures the WTP appropriately. The AC also
establishes corresponding internal operations to deal with the WTP
according to its functionalities.
8.2. Configuration Status
The Configuration Status message is sent by a WTP to deliver its
current configuration to its AC.
Configuration Status messages are sent by a WTP while in the
Configure state.
The Configuration Status message carries binding specific message
elements. Refer to the appropriate binding for the definition of
this structure.
When an AC receives a Configuration Status message it will act upon
the content of the packet and respond to the WTP with a Configuration
Status Response message.
The Configuration Status message includes multiple Administrative
State message Elements. There is one such message element for the
WTP, and one message element per radio in the WTP.
The following message elements MUST be included in the Configuration
Status message.
o AC Name, see Section 4.4.4
o AC Name with Index, see Section 4.4.5
o Radio Administrative State, see Section 4.4.28
o Statistics Timer, see Section 4.4.31
o WTP Board Data, see Section 4.4.33
o WTP Static IP Address Information, see Section 4.4.44
o WTP Reboot Statistics, see Section 4.4.43
8.3. Configuration Status Response
The Configuration Status Response message is sent by an AC and
provides a mechanism for the AC to override a WTP's requested
configuration.
Configuration Status Response messages are sent by an AC after
receiving a Configure Request message.
The Configuration Status Response message carries binding specific
message elements. Refer to the appropriate binding for the
definition of this structure.
When a WTP receives a Configuration Status Response message it acts
upon the content of the message, as appropriate. If the
Configuration Status Response message includes a Change State Event
message element that causes a change in the operational state of one
of the Radio, the WTP will transmit a Change State Event to the AC,
as an acknowledgement of the change in state.
The following message elements MUST be included in the Configuration
Status Response message.
o AC IPv4 List, see Section 4.4.2
o AC IPv6 List, see Section 4.4.3
o CAPWAP Timers, see Section 4.4.10
o Change State Event, see Section 4.4.11
o Decryption Error Report Period, see Section 4.4.15
o Idle Timeout, see Section 4.4.22
o WTP Fallback, see Section 4.4.35
8.4. Configuration Update Request
Configure Update Request messages are sent by the AC to provision the
WTP while in the Run state. This is used to modify the configuration
of the WTP while it is operational.
When an AC receives a Configuration Update Request message it will
respond with a Configuration Update Response message, with the
appropriate Result Code.
One or more of the following message elements MAY be included in the
Configuration Update message.
o AC IPv4 List, see Section 4.4.2
o AC IPv6 List, see Section 4.4.3
o AC Name with Index, see Section 4.4.5
o AC Timestamp, see Section 4.4.6
o Add MAC ACL Entry, see Section 4.4.7
o Add Static MAC ACL Entry, see Section 4.4.9
o CAPWAP Timers, see Section 4.4.10
o Change State Event, see Section 4.4.11
o Decryption Error Report Period, see Section 4.4.15
o Delete MAC ACL Entry, see Section 4.4.16
o Delete Static MAC ACL Entry, see Section 4.4.18
o Idle Timeout, see Section 4.4.22
o Location Data, see Section 4.4.26
o Radio Administrative State, see Section 4.4.28
o Statistics Timer, see Section 4.4.31
o WTP Fallback, see Section 4.4.35
o WTP Name, see Section 4.4.42
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 Configure Update Response message the result When an AC receives a Configure Update Response message the result
code indicates if the WTP successfully accepted the configuration. code indicates if the WTP successfully accepted the configuration.
The following subsections define the message elements that must be The following message element MUST be present in the Configuration
present in the Configuration Update message. Update message.
7.5.1. Result Code
The Result Code message element value is a 32-bit integer value,
indicating the result of the request operation corresponding to the
sequence number in the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for Result Code
Length: 4 Result Code, see Section 4.4.29
Result Code: The following values are defined: The following message elements MAY be present in the Configuration
Update message.
0 Success o AC IPv4 List, see Section 4.4.2
1 Failure (AC List message element MUST be present) o AC IPv6 List, see Section 4.4.3
7.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 operational state.
The Change State Event Request message is sent by the WTP when it The Change State Event Request message is sent by the WTP when it
receives a Configuration Response message that includes a Change receives a Configuration Response message that includes a Change
State Event message element. It is also sent when the WTP detects an State Event message element. It is also sent when the WTP detects an
operational failure with a radio. The Change State Event Request operational failure with a radio. The Change State Event Request
message may be sent in either the Configure or Run state (see message may be sent in either the Configure or Run state (see
Section 2.2. Section 2.3.
When an AC receives a Change State Event message it will respond with When an AC receives a Change State Event message it will respond with
a Change State Event Response message and make any necessary a Change State Event Response message and make any necessary
modifications to internal WTP data structures. modifications to internal WTP data structures.
The following subsections define the message elements that must be The following message elements MUST be present in the Change State
present in the Change State Event Request message. Event Request message.
7.6.1. Change State Event
The Change State Event message element is defined in Section 7.3.2. o Change State Event message element, see Section 4.4.11
7.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 by a WTP after receiving a A Change State Event Response message is by a WTP after receiving a
Change State Event Request message. 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.
Its purpose is to acknowledge the receipt of the Change State Event Its purpose is to acknowledge the receipt of the Change State Event
Request message. Request message.
The WTP does not need to perform any special processing of the Change The WTP does not need to perform any special processing of the Change
State Event Response message. State Event Response message.
7.8. Clear Config Indication 8.8. Clear Config Indication
The Clear Config Indication message is used to reset a WTP's The Clear Config Indication message is used to reset a WTP's
configuration. configuration.
The Clear Config Indication message is sent by an AC to request that The Clear Config Indication message is sent by an AC to request that
a WTP reset its configuration to the manufacturing default a WTP reset its configuration to the manufacturing default
configuration. The Clear Config Indication message is sent while in configuration. The Clear Config Indication message is sent while in
the Run CAPWAP state. the Run CAPWAP state.
The Clear Config Indication message carries no message elements. The Clear Config Indication message carries no message elements.
When a WTP receives a Clear Config Indication message it resets its When a WTP receives a Clear Config Indication message it resets its
configuration to the manufacturing default configuration. configuration to the manufacturing default configuration.
8. 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.
8.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
ensure that the image being run on each WTP is appropriate. ensure that the image being run on each WTP is appropriate.
Image Data Request messages are exchanged between the WTP and the AC Image Data Request messages are exchanged between the WTP and the AC
to download a new program image to the WTP. to download a new firmware image to the WTP. When a WTP or AC
receives an Image Data Request message it will respond with an Image
When a WTP or AC receives an Image Data Request message it will Data Response message. The message elements contained within the
respond with an Image Data Response message. Image Data Request is required in order to determine the intent of
the request. Note that only one message element may be present in
The format of the Image Data and Image Download message elements are any given Image Data Request message.
described in the following subsections.
8.1.1. Image Download
The image download message element is sent by the WTP to the AC and
contains the image filename. The value is a variable length byte
string. The string is NOT zero terminated.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filename ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 32 for Image Download
Length: >= 1
Filename: A variable length string containing the filename to
download.
8.1.2. Image Data
The image data message element is present in the Image Data Request
message sent by the AC and contains the following fields.
0 1 2 3 The decision that new firmware is to downloaded to the WTP can occur
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 in one of two methods:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Checksum | Image Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Image Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 33 for Image Data When the WTP joins the AC, and each exchange their software
revision, the WTP may opt to initiate a firmware download by
sending an Image Data Request, which contains an Image Filename
message element.
Length: >= 4 (allows 0 length element if last data unit is 1024 Once the WTP is in the CAPWAP state, it is possible for the AC to
bytes) cause the WTP to initiate a firmware download by initiating an
Image Data Request, with the Initiate Download message element.
The WTP would then transmit the Image Filename message element to
start the download process.
Opcode: An 8-bit value representing the transfer opcode. The Regardless of how the download was initiated, once the AC receives an
following values are supported: Image Data Request with the Image Filename message element, it begins
the transfer process by transmitting its own request with the Image
Data message element. This continues until the whole firmware image
has been transfered.
3 - Image data is included The following message elements MAY be included in the Image Data
Request Message.
5 - An error occurred. Transfer is aborted o Image Data, see Section 4.4.23
Checksum: A 16-bit value containing a checksum of the image data o Image Filename, see Section 4.4.24
that follows
Image Data: The Image Data field contains 1024 characters, unless o Initiate Download, see Section 4.4.25
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
is sent.
8.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.
The Image Data Response message carries no message elements. The Image Data Response message carries no message elements.
No action is necessary on receipt. No action is necessary on receipt.
8.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 and then reinitialize itself.
8.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 Reset Response message carries no message elements. Its purpose
is to acknowledge the receipt of the Reset Request message. is to acknowledge the receipt of the Reset Request message.
When an AC receives a Reset Response message, it is notified that the When an AC receives a Reset Response message, it is notified that the
WTP will reinitialize its operation. WTP will reinitialize its operation.
8.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 described 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.
8.5.1. Decryption Error Report o Decryption Error