Network Working Group P. Calhoun, Ed.
Request for Comments: 5415 Cisco Systems, Inc.
Category: Standards Track M. Montemurro, Ed.
Research In Motion
D. Stanley, Ed.
Aruba Networks
March 2009
Network Working Group P. Calhoun, Ed.
Request for Comments: 5415 Cisco Systems, Inc.
Category: Standards Track M. Montemurro, Ed.
Research In Motion
D. Stanley, Ed.
Aruba Networks
March 2009
Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
无线接入点（CAPWAP）协议规范的控制和配置
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies.
本规范定义了无线接入点（CAPWAP）协议的控制和供应，以满足RFC 4564中CAPWAP工作组定义的目标。CAPWAP协议设计灵活，可用于多种无线技术。本文档介绍基本CAPWAP协议，而单独的绑定扩展将使其能够与其他无线技术一起使用。
Table of Contents
目录
1. Introduction ....................................................7
1.1. Goals ......................................................8
1.2. Conventions Used in This Document ..........................9
1.3. Contributing Authors .......................................9
1.4. Terminology ...............................................10
2. Protocol Overview ..............................................11
2.1. Wireless Binding Definition ...............................12
2.2. CAPWAP Session Establishment Overview .....................13
2.3. CAPWAP State Machine Definition ...........................15
2.3.1. CAPWAP Protocol State Transitions ..................17
2.3.2. CAPWAP/DTLS Interface ..............................31
2.4. Use of DTLS in the CAPWAP Protocol ........................33
2.4.1. DTLS Handshake Processing ..........................33
2.4.2. DTLS Session Establishment .........................35
2.4.3. DTLS Error Handling ................................35
2.4.4. DTLS Endpoint Authentication and Authorization .....36
3. CAPWAP Transport ...............................................40
3.1. UDP Transport .............................................40
3.2. UDP-Lite Transport ........................................41
3.3. AC Discovery ..............................................41
3.4. Fragmentation/Reassembly ..................................42
3.5. MTU Discovery .............................................43
4. CAPWAP Packet Formats ..........................................43
4.1. CAPWAP Preamble ...........................................46
4.2. CAPWAP DTLS Header ........................................46
4.3. CAPWAP Header .............................................47
4.4. CAPWAP Data Messages ......................................50
4.4.1. CAPWAP Data Channel Keep-Alive .....................51
4.4.2. Data Payload .......................................52
4.4.3. Establishment of a DTLS Data Channel ...............52
4.5. CAPWAP Control Messages ...................................52
4.5.1. Control Message Format .............................53
4.5.2. Quality of Service .................................56
4.5.3. Retransmissions ....................................57
4.6. CAPWAP Protocol Message Elements ..........................58
4.6.1. AC Descriptor ......................................61
1. Introduction ....................................................7
1.1. Goals ......................................................8
1.2. Conventions Used in This Document ..........................9
1.3. Contributing Authors .......................................9
1.4. Terminology ...............................................10
2. Protocol Overview ..............................................11
2.1. Wireless Binding Definition ...............................12
2.2. CAPWAP Session Establishment Overview .....................13
2.3. CAPWAP State Machine Definition ...........................15
2.3.1. CAPWAP Protocol State Transitions ..................17
2.3.2. CAPWAP/DTLS Interface ..............................31
2.4. Use of DTLS in the CAPWAP Protocol ........................33
2.4.1. DTLS Handshake Processing ..........................33
2.4.2. DTLS Session Establishment .........................35
2.4.3. DTLS Error Handling ................................35
2.4.4. DTLS Endpoint Authentication and Authorization .....36
3. CAPWAP Transport ...............................................40
3.1. UDP Transport .............................................40
3.2. UDP-Lite Transport ........................................41
3.3. AC Discovery ..............................................41
3.4. Fragmentation/Reassembly ..................................42
3.5. MTU Discovery .............................................43
4. CAPWAP Packet Formats ..........................................43
4.1. CAPWAP Preamble ...........................................46
4.2. CAPWAP DTLS Header ........................................46
4.3. CAPWAP Header .............................................47
4.4. CAPWAP Data Messages ......................................50
4.4.1. CAPWAP Data Channel Keep-Alive .....................51
4.4.2. Data Payload .......................................52
4.4.3. Establishment of a DTLS Data Channel ...............52
4.5. CAPWAP Control Messages ...................................52
4.5.1. Control Message Format .............................53
4.5.2. Quality of Service .................................56
4.5.3. Retransmissions ....................................57
4.6. CAPWAP Protocol Message Elements ..........................58
4.6.1. AC Descriptor ......................................61
4.6.2. AC IPv4 List .......................................64
4.6.3. AC IPv6 List .......................................64
4.6.4. AC Name ............................................65
4.6.5. AC Name with Priority ..............................65
4.6.6. AC Timestamp .......................................66
4.6.7. Add MAC ACL Entry ..................................66
4.6.8. Add Station ........................................67
4.6.9. CAPWAP Control IPv4 Address ........................68
4.6.10. CAPWAP Control IPv6 Address .......................68
4.6.11. CAPWAP Local IPv4 Address .........................69
4.6.12. CAPWAP Local IPv6 Address .........................69
4.6.13. CAPWAP Timers .....................................70
4.6.14. CAPWAP Transport Protocol .........................71
4.6.15. Data Transfer Data ................................72
4.6.16. Data Transfer Mode ................................73
4.6.17. Decryption Error Report ...........................73
4.6.18. Decryption Error Report Period ....................74
4.6.19. Delete MAC ACL Entry ..............................74
4.6.20. Delete Station ....................................75
4.6.21. Discovery Type ....................................75
4.6.22. Duplicate IPv4 Address ............................76
4.6.23. Duplicate IPv6 Address ............................77
4.6.24. Idle Timeout ......................................78
4.6.25. ECN Support .......................................78
4.6.26. Image Data ........................................79
4.6.27. Image Identifier ..................................79
4.6.28. Image Information .................................80
4.6.29. Initiate Download .................................81
4.6.30. Location Data .....................................81
4.6.31. Maximum Message Length ............................81
4.6.32. MTU Discovery Padding .............................82
4.6.33. Radio Administrative State ........................82
4.6.34. Radio Operational State ...........................83
4.6.35. Result Code .......................................84
4.6.36. Returned Message Element ..........................85
4.6.37. Session ID ........................................86
4.6.38. Statistics Timer ..................................87
4.6.39. Vendor Specific Payload ...........................87
4.6.40. WTP Board Data ....................................88
4.6.41. WTP Descriptor ....................................89
4.6.42. WTP Fallback ......................................92
4.6.43. WTP Frame Tunnel Mode .............................92
4.6.44. WTP MAC Type ......................................93
4.6.45. WTP Name ..........................................94
4.6.46. WTP Radio Statistics ..............................94
4.6.47. WTP Reboot Statistics .............................96
4.6.48. WTP Static IP Address Information .................97
4.7. CAPWAP Protocol Timers ....................................98
4.6.2. AC IPv4 List .......................................64
4.6.3. AC IPv6 List .......................................64
4.6.4. AC Name ............................................65
4.6.5. AC Name with Priority ..............................65
4.6.6. AC Timestamp .......................................66
4.6.7. Add MAC ACL Entry ..................................66
4.6.8. Add Station ........................................67
4.6.9. CAPWAP Control IPv4 Address ........................68
4.6.10. CAPWAP Control IPv6 Address .......................68
4.6.11. CAPWAP Local IPv4 Address .........................69
4.6.12. CAPWAP Local IPv6 Address .........................69
4.6.13. CAPWAP Timers .....................................70
4.6.14. CAPWAP Transport Protocol .........................71
4.6.15. Data Transfer Data ................................72
4.6.16. Data Transfer Mode ................................73
4.6.17. Decryption Error Report ...........................73
4.6.18. Decryption Error Report Period ....................74
4.6.19. Delete MAC ACL Entry ..............................74
4.6.20. Delete Station ....................................75
4.6.21. Discovery Type ....................................75
4.6.22. Duplicate IPv4 Address ............................76
4.6.23. Duplicate IPv6 Address ............................77
4.6.24. Idle Timeout ......................................78
4.6.25. ECN Support .......................................78
4.6.26. Image Data ........................................79
4.6.27. Image Identifier ..................................79
4.6.28. Image Information .................................80
4.6.29. Initiate Download .................................81
4.6.30. Location Data .....................................81
4.6.31. Maximum Message Length ............................81
4.6.32. MTU Discovery Padding .............................82
4.6.33. Radio Administrative State ........................82
4.6.34. Radio Operational State ...........................83
4.6.35. Result Code .......................................84
4.6.36. Returned Message Element ..........................85
4.6.37. Session ID ........................................86
4.6.38. Statistics Timer ..................................87
4.6.39. Vendor Specific Payload ...........................87
4.6.40. WTP Board Data ....................................88
4.6.41. WTP Descriptor ....................................89
4.6.42. WTP Fallback ......................................92
4.6.43. WTP Frame Tunnel Mode .............................92
4.6.44. WTP MAC Type ......................................93
4.6.45. WTP Name ..........................................94
4.6.46. WTP Radio Statistics ..............................94
4.6.47. WTP Reboot Statistics .............................96
4.6.48. WTP Static IP Address Information .................97
4.7. CAPWAP Protocol Timers ....................................98
4.7.1. ChangeStatePendingTimer ............................98
4.7.2. DataChannelKeepAlive ...............................98
4.7.3. DataChannelDeadInterval ............................99
4.7.4. DataCheckTimer .....................................99
4.7.5. DiscoveryInterval ..................................99
4.7.6. DTLSSessionDelete ..................................99
4.7.7. EchoInterval .......................................99
4.7.8. IdleTimeout ........................................99
4.7.9. ImageDataStartTimer ...............................100
4.7.10. MaxDiscoveryInterval .............................100
4.7.11. ReportInterval ...................................100
4.7.12. RetransmitInterval ...............................100
4.7.13. SilentInterval ...................................100
4.7.14. StatisticsTimer ..................................100
4.7.15. WaitDTLS .........................................101
4.7.16. WaitJoin .........................................101
4.8. CAPWAP Protocol Variables ................................101
4.8.1. AdminState ........................................101
4.8.2. DiscoveryCount ....................................101
4.8.3. FailedDTLSAuthFailCount ...........................101
4.8.4. FailedDTLSSessionCount ............................101
4.8.5. MaxDiscoveries ....................................102
4.8.6. MaxFailedDTLSSessionRetry .........................102
4.8.7. MaxRetransmit .....................................102
4.8.8. RetransmitCount ...................................102
4.8.9. WTPFallBack .......................................102
4.9. WTP Saved Variables ......................................102
4.9.1. AdminRebootCount ..................................102
4.9.2. FrameEncapType ....................................102
4.9.3. LastRebootReason ..................................103
4.9.4. MacType ...........................................103
4.9.5. PreferredACs ......................................103
4.9.6. RebootCount .......................................103
4.9.7. Static IP Address .................................103
4.9.8. WTPLinkFailureCount ...............................103
4.9.9. WTPLocation .......................................103
4.9.10. WTPName ..........................................103
5. CAPWAP Discovery Operations ...................................103
5.1. Discovery Request Message ................................103
5.2. Discovery Response Message ...............................105
5.3. Primary Discovery Request Message ........................106
5.4. Primary Discovery Response ...............................107
6. CAPWAP Join Operations ........................................108
6.1. Join Request .............................................108
6.2. Join Response ............................................110
7. Control Channel Management ....................................111
7.1. Echo Request .............................................111
7.2. Echo Response ............................................112
4.7.1. ChangeStatePendingTimer ............................98
4.7.2. DataChannelKeepAlive ...............................98
4.7.3. DataChannelDeadInterval ............................99
4.7.4. DataCheckTimer .....................................99
4.7.5. DiscoveryInterval ..................................99
4.7.6. DTLSSessionDelete ..................................99
4.7.7. EchoInterval .......................................99
4.7.8. IdleTimeout ........................................99
4.7.9. ImageDataStartTimer ...............................100
4.7.10. MaxDiscoveryInterval .............................100
4.7.11. ReportInterval ...................................100
4.7.12. RetransmitInterval ...............................100
4.7.13. SilentInterval ...................................100
4.7.14. StatisticsTimer ..................................100
4.7.15. WaitDTLS .........................................101
4.7.16. WaitJoin .........................................101
4.8. CAPWAP Protocol Variables ................................101
4.8.1. AdminState ........................................101
4.8.2. DiscoveryCount ....................................101
4.8.3. FailedDTLSAuthFailCount ...........................101
4.8.4. FailedDTLSSessionCount ............................101
4.8.5. MaxDiscoveries ....................................102
4.8.6. MaxFailedDTLSSessionRetry .........................102
4.8.7. MaxRetransmit .....................................102
4.8.8. RetransmitCount ...................................102
4.8.9. WTPFallBack .......................................102
4.9. WTP Saved Variables ......................................102
4.9.1. AdminRebootCount ..................................102
4.9.2. FrameEncapType ....................................102
4.9.3. LastRebootReason ..................................103
4.9.4. MacType ...........................................103
4.9.5. PreferredACs ......................................103
4.9.6. RebootCount .......................................103
4.9.7. Static IP Address .................................103
4.9.8. WTPLinkFailureCount ...............................103
4.9.9. WTPLocation .......................................103
4.9.10. WTPName ..........................................103
5. CAPWAP Discovery Operations ...................................103
5.1. Discovery Request Message ................................103
5.2. Discovery Response Message ...............................105
5.3. Primary Discovery Request Message ........................106
5.4. Primary Discovery Response ...............................107
6. CAPWAP Join Operations ........................................108
6.1. Join Request .............................................108
6.2. Join Response ............................................110
7. Control Channel Management ....................................111
7.1. Echo Request .............................................111
7.2. Echo Response ............................................112
8. WTP Configuration Management ..................................112
8.1. Configuration Consistency ................................112
8.1.1. Configuration Flexibility .........................113
8.2. Configuration Status Request .............................114
8.3. Configuration Status Response ............................115
8.4. Configuration Update Request .............................116
8.5. Configuration Update Response ............................117
8.6. Change State Event Request ...............................117
8.7. Change State Event Response ..............................118
8.8. Clear Configuration Request ..............................119
8.9. Clear Configuration Response .............................119
9. Device Management Operations ..................................120
9.1. Firmware Management ......................................120
9.1.1. Image Data Request ................................124
9.1.2. Image Data Response ...............................125
9.2. Reset Request ............................................126
9.3. Reset Response ...........................................127
9.4. WTP Event Request ........................................127
9.5. WTP Event Response .......................................128
9.6. Data Transfer ............................................128
9.6.1. Data Transfer Request .............................130
9.6.2. Data Transfer Response ............................131
10. Station Session Management ...................................131
10.1. Station Configuration Request ...........................131
10.2. Station Configuration Response ..........................132
11. NAT Considerations ...........................................132
12. Security Considerations ......................................134
12.1. CAPWAP Security .........................................134
12.1.1. Converting Protected Data into Unprotected Data ..135
12.1.2. Converting Unprotected Data into
Protected Data (Insertion) .......................135
12.1.3. Deletion of Protected Records ....................135
12.1.4. Insertion of Unprotected Records .................135
12.1.5. Use of MD5 .......................................136
12.1.6. CAPWAP Fragmentation .............................136
12.2. Session ID Security .....................................136
12.3. Discovery or DTLS Setup Attacks .........................137
12.4. Interference with a DTLS Session ........................137
12.5. CAPWAP Pre-Provisioning .................................138
12.6. Use of Pre-Shared Keys in CAPWAP ........................139
12.7. Use of Certificates in CAPWAP ...........................140
12.8. Use of MAC Address in CN Field ..........................140
12.9. AAA Security ............................................141
12.10. WTP Firmware ...........................................141
13. Operational Considerations ...................................141
14. Transport Considerations .....................................142
15. IANA Considerations ..........................................143
15.1. IPv4 Multicast Address ..................................143
8. WTP Configuration Management ..................................112
8.1. Configuration Consistency ................................112
8.1.1. Configuration Flexibility .........................113
8.2. Configuration Status Request .............................114
8.3. Configuration Status Response ............................115
8.4. Configuration Update Request .............................116
8.5. Configuration Update Response ............................117
8.6. Change State Event Request ...............................117
8.7. Change State Event Response ..............................118
8.8. Clear Configuration Request ..............................119
8.9. Clear Configuration Response .............................119
9. Device Management Operations ..................................120
9.1. Firmware Management ......................................120
9.1.1. Image Data Request ................................124
9.1.2. Image Data Response ...............................125
9.2. Reset Request ............................................126
9.3. Reset Response ...........................................127
9.4. WTP Event Request ........................................127
9.5. WTP Event Response .......................................128
9.6. Data Transfer ............................................128
9.6.1. Data Transfer Request .............................130
9.6.2. Data Transfer Response ............................131
10. Station Session Management ...................................131
10.1. Station Configuration Request ...........................131
10.2. Station Configuration Response ..........................132
11. NAT Considerations ...........................................132
12. Security Considerations ......................................134
12.1. CAPWAP Security .........................................134
12.1.1. Converting Protected Data into Unprotected Data ..135
12.1.2. Converting Unprotected Data into
Protected Data (Insertion) .......................135
12.1.3. Deletion of Protected Records ....................135
12.1.4. Insertion of Unprotected Records .................135
12.1.5. Use of MD5 .......................................136
12.1.6. CAPWAP Fragmentation .............................136
12.2. Session ID Security .....................................136
12.3. Discovery or DTLS Setup Attacks .........................137
12.4. Interference with a DTLS Session ........................137
12.5. CAPWAP Pre-Provisioning .................................138
12.6. Use of Pre-Shared Keys in CAPWAP ........................139
12.7. Use of Certificates in CAPWAP ...........................140
12.8. Use of MAC Address in CN Field ..........................140
12.9. AAA Security ............................................141
12.10. WTP Firmware ...........................................141
13. Operational Considerations ...................................141
14. Transport Considerations .....................................142
15. IANA Considerations ..........................................143
15.1. IPv4 Multicast Address ..................................143
15.2. IPv6 Multicast Address ..................................144
15.3. UDP Port ................................................144
15.4. CAPWAP Message Types ....................................144
15.5. CAPWAP Header Flags .....................................144
15.6. CAPWAP Control Message Flags ............................145
15.7. CAPWAP Message Element Type .............................145
15.8. CAPWAP Wireless Binding Identifiers .....................145
15.9. AC Security Types .......................................146
15.10. AC DTLS Policy .........................................146
15.11. AC Information Type ....................................146
15.12. CAPWAP Transport Protocol Types ........................146
15.13. Data Transfer Type .....................................147
15.14. Data Transfer Mode .....................................147
15.15. Discovery Types ........................................147
15.16. ECN Support ............................................148
15.17. Radio Admin State ......................................148
15.18. Radio Operational State ................................148
15.19. Radio Failure Causes ...................................148
15.20. Result Code ............................................149
15.21. Returned Message Element Reason ........................149
15.22. WTP Board Data Type ....................................149
15.23. WTP Descriptor Type ....................................149
15.24. WTP Fallback Mode ......................................150
15.25. WTP Frame Tunnel Mode ..................................150
15.26. WTP MAC Type ...........................................150
15.27. WTP Radio Stats Failure Type ...........................151
15.28. WTP Reboot Stats Failure Type ..........................151
16. Acknowledgments ..............................................151
17. References ...................................................151
17.1. Normative References ....................................151
17.2. Informative References ..................................153
15.2. IPv6 Multicast Address ..................................144
15.3. UDP Port ................................................144
15.4. CAPWAP Message Types ....................................144
15.5. CAPWAP Header Flags .....................................144
15.6. CAPWAP Control Message Flags ............................145
15.7. CAPWAP Message Element Type .............................145
15.8. CAPWAP Wireless Binding Identifiers .....................145
15.9. AC Security Types .......................................146
15.10. AC DTLS Policy .........................................146
15.11. AC Information Type ....................................146
15.12. CAPWAP Transport Protocol Types ........................146
15.13. Data Transfer Type .....................................147
15.14. Data Transfer Mode .....................................147
15.15. Discovery Types ........................................147
15.16. ECN Support ............................................148
15.17. Radio Admin State ......................................148
15.18. Radio Operational State ................................148
15.19. Radio Failure Causes ...................................148
15.20. Result Code ............................................149
15.21. Returned Message Element Reason ........................149
15.22. WTP Board Data Type ....................................149
15.23. WTP Descriptor Type ....................................149
15.24. WTP Fallback Mode ......................................150
15.25. WTP Frame Tunnel Mode ..................................150
15.26. WTP MAC Type ...........................................150
15.27. WTP Radio Stats Failure Type ...........................151
15.28. WTP Reboot Stats Failure Type ..........................151
16. Acknowledgments ..............................................151
17. References ...................................................151
17.1. Normative References ....................................151
17.2. Informative References ..................................153
This document describes the CAPWAP protocol, a standard, interoperable protocol that enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). The CAPWAP protocol is defined to be independent of Layer 2 (L2) technology, and meets the objectives in "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4564].
本文档介绍CAPWAP协议，这是一种标准的、可互操作的协议，使访问控制器（AC）能够管理无线终端点（WTP）的集合。CAPWAP协议被定义为独立于第2层（L2）技术，并满足“无线接入点（CAPWAP）的控制和供应目标”[RFC4564]中的目标。
The emergence of centralized IEEE 802.11 Wireless Local Area Network (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by an Access Controller (AC), suggested that a standards-based, interoperable protocol could radically simplify the deployment and management of wireless networks. WTPs require a set of dynamic management and control functions related to their primary task of connecting the wireless and wired mediums. Traditional protocols for managing WTPs are either manual static configuration via HTTP, proprietary Layer 2-specific or non-existent (if the WTPs are self-contained). An IEEE 802.11 binding is defined in [RFC5416] to support use of the CAPWAP protocol with IEEE 802.11 WLAN networks.
集中式IEEE 802.11无线局域网（WLAN）体系结构的出现，其中简单的IEEE 802.11 WTP由接入控制器（AC）管理，表明基于标准的可互操作协议可以从根本上简化无线网络的部署和管理。WTP需要一组与连接无线和有线媒体的主要任务相关的动态管理和控制功能。用于管理WTP的传统协议要么是通过HTTP手动静态配置，要么是专有的第2层特定协议，要么是不存在的（如果WTP是自包含的）。[RFC5416]中定义了IEEE 802.11绑定，以支持在IEEE 802.11 WLAN网络中使用CAPWAP协议。
CAPWAP assumes a network configuration consisting of multiple WTPs communicating via the Internet Protocol (IP) to an AC. WTPs are viewed as remote radio frequency (RF) interfaces controlled by the AC. The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control). In Split MAC mode, all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. As shown in Figure 1, the wireless frames received from a mobile device, which is referred to in this specification as a Station (STA), are directly encapsulated by the WTP and forwarded to the AC.
CAPWAP采用由多个WTP组成的网络配置，通过互联网协议（IP）与AC通信。WTP被视为由AC控制的远程射频（RF）接口。CAPWAP协议支持两种操作模式：拆分和本地MAC（介质访问控制）。在分割MAC模式下，所有L2无线数据和管理帧通过CAPWAP协议封装，并在AC和WTP之间交换。如图1所示，从移动设备接收的无线帧（在本规范中称为站（STA））由WTP直接封装并转发到AC。
+-+ wireless frames +-+
| |--------------------------------| |
| | +-+ | |
| |--------------| |---------------| |
| |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
+-+ wireless frames +-+
| |--------------------------------| |
| | +-+ | |
| |--------------| |---------------| |
| |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
Figure 1: Representative CAPWAP Architecture for Split MAC
图1：拆分MAC的代表性CAPWAP体系结构
The Local MAC mode of operation allows for the data frames to be either locally bridged or tunneled as 802.3 frames. The latter implies that the WTP performs the 802.11 Integration function. In either case, the L2 wireless management frames are processed locally
本地MAC操作模式允许数据帧作为802.3帧进行本地桥接或隧道传输。后者意味着WTP执行802.11集成功能。在任一种情况下，本地处理L2无线管理帧
by the WTP and then forwarded to the AC. Figure 2 shows the Local MAC mode, in which a station transmits a wireless frame that is encapsulated in an 802.3 frame and forwarded to the AC.
由WTP发送，然后转发到AC。图2显示了本地MAC模式，在该模式下，站点发送封装在802.3帧中并转发到AC的无线帧。
+-+wireless frames +-+ 802.3 frames +-+
| |----------------| |--------------| |
| | | | | |
| |----------------| |--------------| |
| |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
+-+wireless frames +-+ 802.3 frames +-+
| |----------------| |--------------| |
| | | | | |
| |----------------| |--------------| |
| |wireless PHY/ | | CAPWAP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
Figure 2: Representative CAPWAP Architecture for Local MAC
图2：本地MAC的代表性CAPWAP体系结构
Provisioning WTPs with security credentials and managing which WTPs are authorized to provide service are traditionally handled by proprietary solutions. Allowing these functions to be performed from a centralized AC in an interoperable fashion increases manageability and allows network operators to more tightly control their wireless network infrastructure.
传统上，通过专有解决方案为WTP提供安全凭据和管理授权提供服务的WTP。允许以可互操作的方式从集中式AC执行这些功能，可提高可管理性，并允许网络运营商更严格地控制其无线网络基础设施。
The goals for the CAPWAP protocol are listed below:
CAPWAP协议的目标如下所示：
1. To centralize the authentication and policy enforcement functions for a wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs.
1. 集中无线网络的身份验证和策略实施功能。AC还可以提供用户通信的集中桥接、转发和加密。通过将网络处理硅的功能应用于无线网络（如有线局域网），这些功能的集中化将降低成本并提高效率。
2. To enable shifting of the higher-level protocol processing from the WTP. This leaves the time-critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs, which are subject to severe cost pressure.
2. 启用从WTP转移更高级别的协议处理。这使得WTP中的无线控制和访问的时间关键型应用程序得以有效利用WTP中可用的计算能力，而WTP面临着严重的成本压力。
3. To provide an extensible protocol that is not bound to a specific wireless technology. Extensibility is provided via a generic encapsulation and transport mechanism, enabling the CAPWAP protocol to be applied to many access point types in the future, via a specific wireless binding.
3. 提供不绑定到特定无线技术的可扩展协议。可扩展性通过通用封装和传输机制提供，使CAPWAP协议能够在将来通过特定的无线绑定应用于多种接入点类型。
The CAPWAP protocol concerns itself solely with the interface between the WTP and the AC. Inter-AC and station-to-AC communication are strictly outside the scope of this document.
CAPWAP协议仅涉及WTP和AC之间的接口。AC间和站间通信严格不在本文件范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section lists and acknowledges the authors of significant text and concepts included in this specification.
本节列出并确认本规范中包含的重要文本和概念的作者。
The CAPWAP Working Group selected the Lightweight Access Point Protocol (LWAPP) [LWAPP] to be used as the basis of the CAPWAP protocol specification. The following people are authors of the LWAPP document:
CAPWAP工作组选择轻量级接入点协议（LWAP）[LWAP]作为CAPWAP协议规范的基础。以下人员是LWAPP文档的作者：
Bob O'Hara Email: bob.ohara@computer.org
鲍勃·奥哈拉电子邮件：鲍勃。ohara@computer.org
Pat Calhoun, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-902-3240, Email: pcalhoun@cisco.com
思科系统公司Pat Calhoun，地址：加利福尼亚州圣何塞市西塔斯曼大道170号，电话：+1408-902-3240，电子邮件：pcalhoun@cisco.com
Rohit Suri, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-5548, Email: rsuri@cisco.com
思科系统公司Rohit Suri，地址：加利福尼亚州圣何塞市西塔斯曼大道170号，电话：+1408-853-5548，电子邮件：rsuri@cisco.com
Nancy Cam Winget, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-0532, Email: ncamwing@cisco.com
Nancy Cam Winget，思科系统公司，地址：加利福尼亚州圣何塞市西塔斯曼大道170号，电话：+1 408-853-0532，电子邮件：ncamwing@cisco.com
Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
斯科特·凯利，阿鲁巴网络公司，加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089电话：+1408-754-8408，电子邮件：skelly@arubanetworks.com
Michael Glenn Williams, Nokia, Inc. 313 Fairchild Drive, Mountain View, CA 94043 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com
迈克尔·格伦·威廉姆斯，诺基亚公司，地址：加利福尼亚州山景城飞兆半导体大道313号94043电话：+1650-714-7758，电子邮件：Michael.G。Williams@Nokia.com
Sue Hares, Green Hills Software 825 Victors Way, Suite 100, Ann Arbor, MI 48108 Phone: +1 734 222 1610, Email: shares@ndzh.com
Sue Hares，青山软件公司密歇根州安阿伯市胜利者路825号100套房48108电话：+1 734 222 1610，电子邮件：shares@ndzh.com
Datagram Transport Layer Security (DTLS) [RFC4347] is used as the security solution for the CAPWAP protocol. The following people are authors of significant DTLS-related text included in this document:
数据报传输层安全性（DTLS）[RFC4347]用作CAPWAP协议的安全解决方案。以下人员是本文件中重要DTLS相关文本的作者：
Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408 Email: skelly@arubanetworks.com
斯科特·凯利，阿鲁巴网络公司，加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089电话：+1408-754-8408电子邮件：skelly@arubanetworks.com
Eric Rescorla, Network Resonance 2483 El Camino Real, #212,Palo Alto CA, 94303 Email: ekr@networkresonance.com
Eric Rescorla，网络共振2483 El Camino Real，#212，加利福尼亚州帕洛阿尔托，94303电子邮件：ekr@networkresonance.com
The concept of using DTLS to secure the CAPWAP protocol was part of the Secure Light Access Point Protocol (SLAPP) proposal [SLAPP]. The following people are authors of the SLAPP proposal:
使用DTLS保护CAPWAP协议的概念是安全光接入点协议（SLAPP）提案[SLAPP]的一部分。以下人员是SLAP提案的作者：
Partha Narasimhan, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-480-4716 Email: partha@arubanetworks.com
加利福尼亚州桑尼维尔市克罗斯曼大道1322号阿鲁巴网络公司Partha Narasimhan 94089电话：+1 408-480-4716电子邮件：partha@arubanetworks.com
Dan Harkins Trapeze Networks 5753 W. Las Positas Blvd, Pleasanton, CA 94588 Phone: +1-925-474-2212 EMail: dharkins@trpz.com
Dan Harkins吊架网络美国加利福尼亚州普莱森顿拉斯波西塔斯大道5753号，邮编94588电话：+1-925-474-2212电子邮件：dharkins@trpz.com
Subbu Ponnuswamy, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-1213 Email: subbu@arubanetworks.com
Subbu Ponnuswamy，阿鲁巴网络公司，加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089电话：+1 408-754-1213电子邮件：subbu@arubanetworks.com
The following individuals contributed significant security-related text to the document [RFC5418]:
以下人员为文件[RFC5418]提供了重要的安全相关文本：
T. Charles Clancy, Laboratory for Telecommunications Sciences, 8080 Greenmead Drive, College Park, MD 20740 Phone: +1 240-373-5069, Email: clancy@ltsnet.net
T.Charles Clancy，美国马里兰州大学公园格林米德大道8080号电信科学实验室，邮编20740电话：+1 240-373-5069，电子邮件：clancy@ltsnet.net
Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: scott@hyperthought.com
斯科特·凯利，阿鲁巴网络公司，加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089电话：+1408-754-8408，电子邮件：scott@hyperthought.com
Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein.
访问控制器（AC）：提供WTP访问数据平面、控制平面、管理平面或其中组合中网络基础设施的网络实体。
CAPWAP Control Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC control port, WTP control port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Control packets are sent and received.
CAPWAP控制通道：由AC IP地址、WTP IP地址、AC控制端口、WTP控制端口和传输层协议（UDP或UDP Lite）定义的双向流，通过该协议发送和接收CAPWAP控制数据包。
CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Data packets are sent and received.
CAPWAP数据通道：由AC IP地址、WTP IP地址、AC数据端口、WTP数据端口和传输层协议（UDP或UDP Lite）定义的双向流，通过该协议发送和接收CAPWAP数据包。
Station (STA): A device that contains an interface to a wireless medium (WM).
工作站（STA）：包含无线媒体（WM）接口的设备。
Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and wireless Physical Layer (PHY) to transmit and receive station traffic for wireless access networks.
无线终端点（WTP）：包含RF天线和无线物理层（PHY）的物理或网络实体，用于发送和接收无线接入网络的站点流量。
This document uses additional terminology defined in [RFC3753].
本文件使用了[RFC3753]中定义的其他术语。
The CAPWAP protocol is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS. The underlying security-related protocol mechanisms of TLS have been successfully deployed for many years.
CAPWAP协议是通过CAPWAP协议传输机制定义AC和WTP控制和数据平面通信的通用协议。CAPWAP控制消息和可选的CAPWAP数据消息使用数据报传输层安全性（DTLS）[RFC4347]进行保护。DTLS是基于TLS的标准跟踪IETF协议。TLS的底层安全相关协议机制已成功部署多年。
The CAPWAP protocol transport layer carries two types of payload, CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data messages encapsulate forwarded wireless frames. CAPWAP protocol Control messages are management messages exchanged between a WTP and an AC. The CAPWAP Data and Control packets are sent over separate UDP ports. Since both data and control packets can exceed the Maximum Transmission Unit (MTU) length, the payload of a CAPWAP Data or Control message can be fragmented. The fragmentation behavior is defined in Section 3.
CAPWAP协议传输层承载两种类型的有效负载：CAPWAP数据消息和CAPWAP控制消息。CAPWAP数据消息封装转发的无线帧。CAPWAP协议控制消息是WTP和AC之间交换的管理消息。CAPWAP数据和控制数据包通过单独的UDP端口发送。由于数据和控制数据包都可能超过最大传输单元（MTU）长度，因此CAPWAP数据或控制消息的有效负载可能会被分割。碎片行为在第3节中有定义。
The CAPWAP Protocol begins with a Discovery phase. The WTPs send a Discovery Request message, causing any Access Controller (AC) receiving the message to respond with a Discovery Response message. From the Discovery Response messages received, a WTP selects an AC with which to establish a secure DTLS session. In order to establish the secure DTLS connection, the WTP will need some amount of pre-provisioning, which is specified in Section 12.5. CAPWAP protocol messages will be fragmented to the maximum length discovered to be supported by the network.
CAPWAP协议从发现阶段开始。WTP发送发现请求消息，使接收该消息的任何访问控制器（AC）响应发现响应消息。从接收到的发现响应消息中，WTP选择一个AC，与之建立安全DTLS会话。为了建立安全的DTLS连接，WTP将需要一定量的预配置，这在第12.5节中有规定。CAPWAP协议消息将被分段到网络支持的最大长度。
Once the WTP and the AC have completed DTLS session establishment, a configuration exchange occurs in which both devices agree on version information. During this exchange, the WTP may receive provisioning settings. The WTP is then enabled for operation.
一旦WTP和AC完成DTLS会话建立，就会发生配置交换，其中两个设备在版本信息上达成一致。在此交换期间，WTP可能会接收设置。然后启用WTP进行操作。
When the WTP and AC have completed the version and provision exchange and the WTP is enabled, the CAPWAP protocol is used to encapsulate the wireless data frames sent between the WTP and AC. The CAPWAP protocol will fragment the L2 frames if the size of the encapsulated wireless user data (Data) or protocol control (Management) frames causes the resulting CAPWAP protocol packet to exceed the MTU supported between the WTP and AC. Fragmented CAPWAP packets are reassembled to reconstitute the original encapsulated payload. MTU Discovery and Fragmentation are described in Section 3.
当WTP和AC完成版本和配置交换且WTP启用时，CAPWAP协议用于封装WTP和AC之间发送的无线数据帧。如果封装的无线用户数据（数据）或协议控制（管理）的大小不同，CAPWAP协议将分割L2帧帧导致生成的CAPWAP协议数据包超过WTP和AC之间支持的MTU。碎片化的CAPWAP数据包被重新组装，以重建原始封装的有效负载。第3节介绍了MTU发现和碎片化。
The CAPWAP protocol provides for the delivery of commands from the AC to the WTP for the management of stations that are communicating with the WTP. This may include the creation of local data structures in the WTP for the stations and the collection of statistical information about the communication between the WTP and the stations. The CAPWAP protocol provides a mechanism for the AC to obtain statistical information collected by the WTP.
CAPWAP协议提供了从AC到WTP的命令传输，用于管理与WTP通信的站点。这可以包括在WTP中为站点创建本地数据结构，以及收集关于WTP和站点之间的通信的统计信息。CAPWAP协议为AC提供了获取WTP收集的统计信息的机制。
The CAPWAP protocol provides for a keep-alive feature that preserves the communication channel between the WTP and AC. If the AC fails to appear alive, the WTP will try to discover a new AC.
CAPWAP协议提供了保持活动的功能，该功能保留了WTP和AC之间的通信通道。如果AC无法显示为活动状态，WTP将尝试发现新的AC。
The CAPWAP protocol is independent of a specific WTP radio technology, as well its associated wireless link layer protocol. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST follow the binding requirements defined for that technology.
CAPWAP协议独立于特定的WTP无线电技术及其相关的无线链路层协议。CAPWAP协议的元素旨在以标准方式满足每种无线技术的特定需求。特定无线技术的CAPWAP协议的实施必须遵循为该技术定义的绑定要求。
When defining a binding for wireless technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. At a minimum, a binding MUST provide:
在定义无线技术的绑定时，作者必须包括特定于技术的消息的任何必要定义以及这些消息的所有特定于技术的消息元素。至少，绑定必须提供：
1. The definition for a binding-specific Statistics message element, carried in the WTP Event Request message.
1. 特定于绑定的统计信息元素的定义，包含在WTP事件请求消息中。
2. A message element carried in the Station Configuration Request message to configure station information on the WTP.
2. 站点配置请求消息中包含的消息元素，用于在WTP上配置站点信息。
3. A WTP Radio Information message element carried in the Discovery, Primary Discovery, and Join Request and Response messages, indicating the binding-specific radio types supported at the WTP and AC.
3. 在发现、主发现以及连接请求和响应消息中携带的WTP无线电信息消息元素，指示WTP和AC支持的绑定特定无线电类型。
If technology-specific message elements are required for any of the existing CAPWAP messages defined in this specification, they MUST also be defined in the technology binding document.
如果本规范中定义的任何现有CAPWAP消息需要特定于技术的消息元素，则还必须在技术绑定文档中定义这些元素。
The naming of binding-specific message elements MUST begin with the name of the technology type, e.g., the binding for IEEE 802.11, provided in [RFC5416], begins with "IEEE 802.11".
绑定特定消息元素的命名必须以技术类型的名称开头，例如，[RFC5416]中提供的IEEE 802.11绑定以“IEEE 802.11”开头。
The CAPWAP binding concept MUST also be used in any future specifications that add functionality to either the base CAPWAP protocol specification, or any published CAPWAP binding specification. A separate WTP Radio Information message element MUST be created to properly advertise support for the specification. This mechanism allows for future protocol extensibility, while providing the necessary capabilities advertisement, through the WTP Radio Information message element, to ensure WTP/AC interoperability.
CAPWAP绑定概念还必须在将来的任何规范中使用，这些规范将功能添加到基本CAPWAP协议规范或任何已发布的CAPWAP绑定规范中。必须创建单独的WTP无线电信息消息元素，以正确宣传对规范的支持。该机制允许将来的协议扩展，同时通过WTP无线电信息消息元素提供必要的功能，以确保WTP/AC互操作性。
This section describes the session establishment process message exchanges between a CAPWAP WTP and AC. 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. Note that DTLS allows certain messages to be aggregated into a single frame, which is denoted via an asterisk in Figure 3.
本节描述CAPWAP WTP和AC之间的会话建立过程消息交换。带注释的梯形图显示右侧的AC，左侧的WTP，并假设使用证书进行DTLS身份验证。第2.3节详细描述了CAPWAP协议状态机。请注意，DTLS允许将某些消息聚合到单个帧中，在图3中用星号表示。
============ ============
WTP AC
============ ============
[----------- begin optional discovery ------------]
============ ============
WTP AC
============ ============
[----------- begin optional discovery ------------]
Discover Request
------------------------------------>
Discover Response
<------------------------------------
Discover Request
------------------------------------>
Discover Response
<------------------------------------
[----------- end optional discovery ------------]
[----------- end optional discovery ------------]
(-- begin DTLS handshake --)
（-开始DTLS握手--）
ClientHello
------------------------------------>
ClientHello
------------------------------------>
HelloVerifyRequest (with cookie)
<------------------------------------
HelloVerifyRequest (with cookie)
<------------------------------------
ClientHello (with cookie)
------------------------------------>
ServerHello,
Certificate,
ServerHelloDone*
<------------------------------------
ClientHello (with cookie)
------------------------------------>
ServerHello,
Certificate,
ServerHelloDone*
<------------------------------------
(-- WTP callout for AC authorization --)
（-AC授权的WTP调用--）
Certificate (optional),
ClientKeyExchange,
CertificateVerify (optional),
ChangeCipherSpec,
Finished*
------------------------------------>
Certificate (optional),
ClientKeyExchange,
CertificateVerify (optional),
ChangeCipherSpec,
Finished*
------------------------------------>
(-- AC callout for WTP authorization --)
（-WTP授权的AC标注--）
ChangeCipherSpec,
Finished*
<------------------------------------
ChangeCipherSpec,
Finished*
<------------------------------------
(-- DTLS session is established now --)
（-DTLS会话现在已建立--）
Join Request
------------------------------------>
Join Response
<------------------------------------
[-- Join State Complete --]
Join Request
------------------------------------>
Join Response
<------------------------------------
[-- Join State Complete --]
(-- assume image is up to date --)
（-假设图像是最新的--）
Configuration Status Request
------------------------------------>
Configuration Status Response
<------------------------------------
[-- Configure State Complete --]
Configuration Status Request
------------------------------------>
Configuration Status Response
<------------------------------------
[-- Configure State Complete --]
Change State Event Request
------------------------------------>
Change State Event Response
<------------------------------------
[-- Data Check State Complete --]
Change State Event Request
------------------------------------>
Change State Event Response
<------------------------------------
[-- Data Check State Complete --]
(-- enter RUN state --)
（-进入运行状态--）
: :
: :
Echo Request
------------------------------------>
Echo Response
<------------------------------------
Echo Request
------------------------------------>
Echo Response
<------------------------------------
: :
: :
Event Request
------------------------------------>
Event Response
<------------------------------------
Event Request
------------------------------------>
Event Response
<------------------------------------
: :
: :
Figure 3: CAPWAP Control Protocol Exchange
图3:CAPWAP控制协议交换
At the end of the illustrated CAPWAP message exchange, the AC and WTP are securely exchanging CAPWAP Control messages. This illustration is provided to clarify protocol operation, and does not include any possible error conditions. Section 2.3 provides a detailed description of the corresponding state machine.
在图示的CAPWAP消息交换结束时，AC和WTP正在安全地交换CAPWAP控制消息。本图旨在阐明协议操作，不包括任何可能的错误情况。第2.3节提供了相应状态机的详细说明。
The following state diagram represents the lifecycle of a WTP-AC 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 (see Section 2.3.2.1) and notifications (see Section 2.3.2.2). 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.
以下状态图表示WTP-AC会话的生命周期。CAPWAP协议使用DTL导致两个名义上分离但紧密绑定的状态机并列。DTLS和CAPWAP状态机通过由命令（见第2.3.2.1节）和通知（见第2.3.2.2节）组成的API进行耦合。DTLS状态机中的某些转换由来自CAPWAP状态机的命令触发，而CAPWAP状态机中的某些转换由来自DTLS状态机的通知触发。
/-------------------------------------\
| /-------------------------\|
| p| ||
| q+----------+ r +------------+ ||
| | Run |-->| Reset |-\||
| +----------+ +------------+ |||
n| o ^ ^ ^ s|||
+------------+--------/ | | |||
| Data Check | /-------/ | |||
+------------+<-------\ | | |||
| | | |||
/------------------+--------\ | |||
f| m| h| j v k| |||
+--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data ||||
+--------+ n +-----------+ +--------------+|||
^ |g i| l| |||
| | \-------------------\ | |||
| \--------------------------------------\| | |||
\------------------------\ || | |||
/--------------<----------------+---------------\ || | |||
| /------------<----------------+-------------\ | || | |||
| | 4 |d t| | vv v vvv
| | +----------------+ +--------------+ +-----------+
| | | DTLS Setup | | DTLS Connect |-->| DTLS TD |
/-|-|---+----------------+ +--------------+ e +-----------+
| | | |$ ^ ^ |5 ^6 ^ ^ |w
v v v | | | | \-------\ | | |
| | | | | | \---------\ | | /-----------/ |
| | | | | \--\ | | | | |
| | | | | | | | | | |
| | | v 3| 1 |% # v | |a |b v
| | \->+------+-->+------+ +-----------+ +--------+
| | | Idle | | Disc | | Authorize | | Dead |
| | +------+<--+------+ +-----------+ +--------+
| | ^ 0^ 2 |!
| | | | | +-------+
*| |u | \---------+---| Start |
| | |@ | +-------+
| \->+---------+<------/
\--->| Sulking |
+---------+&
/-------------------------------------\
| /-------------------------\|
| p| ||
| q+----------+ r +------------+ ||
| | Run |-->| Reset |-\||
| +----------+ +------------+ |||
n| o ^ ^ ^ s|||
+------------+--------/ | | |||
| Data Check | /-------/ | |||
+------------+<-------\ | | |||
| | | |||
/------------------+--------\ | |||
f| m| h| j v k| |||
+--------+ +-----------+ +--------------+|||
| Join |---->| Configure | | Image Data ||||
+--------+ n +-----------+ +--------------+|||
^ |g i| l| |||
| | \-------------------\ | |||
| \--------------------------------------\| | |||
\------------------------\ || | |||
/--------------<----------------+---------------\ || | |||
| /------------<----------------+-------------\ | || | |||
| | 4 |d t| | vv v vvv
| | +----------------+ +--------------+ +-----------+
| | | DTLS Setup | | DTLS Connect |-->| DTLS TD |
/-|-|---+----------------+ +--------------+ e +-----------+
| | | |$ ^ ^ |5 ^6 ^ ^ |w
v v v | | | | \-------\ | | |
| | | | | | \---------\ | | /-----------/ |
| | | | | \--\ | | | | |
| | | | | | | | | | |
| | | v 3| 1 |% # v | |a |b v
| | \->+------+-->+------+ +-----------+ +--------+
| | | Idle | | Disc | | Authorize | | Dead |
| | +------+<--+------+ +-----------+ +--------+
| | ^ 0^ 2 |!
| | | | | +-------+
*| |u | \---------+---| Start |
| | |@ | +-------+
| \->+---------+<------/
\--->| Sulking |
+---------+&
Figure 4: CAPWAP Integrated State Machine
图4:CAPWAP集成状态机
The CAPWAP protocol state machine, depicted above, is used by both the AC and the WTP. In cases where states are not shared (i.e., not implemented in one or the other of the AC or WTP), this is explicitly
上述CAPWAP协议状态机由AC和WTP使用。在状态未共享的情况下（即，未在AC或WTP的一个或另一个中实现），这是明确的
called out in the transition descriptions below. For every state defined, only certain messages are permitted to be sent and received. The CAPWAP Control message definitions specify the state(s) in which each message is valid.
在下面的转换描述中调用。对于定义的每个状态，只允许发送和接收某些消息。CAPWAP控制消息定义指定每条消息的有效状态。
Since the WTP only communicates with a single AC, it only has a single instance of the CAPWAP state machine. The state machine works differently on the AC since it communicates with many WTPs. The AC uses the concept of three threads. Note that the term thread used here does not necessarily imply that implementers must use threads, but it is one possible way of implementing the AC's state machine.
由于WTP仅与单个AC通信，因此它只有一个CAPWAP状态机实例。状态机在AC上的工作方式不同，因为它与许多WTP通信。AC使用三个线程的概念。注意，这里使用的术语thread并不一定意味着实现者必须使用线程，但它是实现AC的状态机的一种可能方式。
Listener Thread: The AC's Listener thread handles inbound DTLS session establishment requests, through the DTLSListen command. Upon creation, the Listener thread starts in the DTLS Setup state. Once a DTLS session has been validated, which occurs when the state machine enters the "Authorize" state, the Listener thread creates a WTP session-specific Service thread and state context. The state machine transitions in Figure 4 are represented by numerals. It is necessary for the AC to protect itself against various attacks that exist with non-authenticated frames. See Section 12 for more information.
侦听器线程：AC的侦听器线程通过DTLSListen命令处理入站DTLS会话建立请求。创建时，侦听器线程在DTLS设置状态下启动。一旦验证了DTLS会话（当状态机进入“授权”状态时发生），侦听器线程就会创建WTP会话特定的服务线程和状态上下文。图4中的状态机转换由数字表示。AC有必要保护自己免受存在于非认证帧中的各种攻击。更多信息请参见第12节。
Discovery Thread: The AC's Discovery thread is responsible for receiving, and responding to, Discovery Request messages. The state machine transitions in Figure 4 are represented by numerals. Note that the Discovery thread does not maintain any per-WTP-specific context information, and a single state context exists. It is necessary for the AC to protect itself against various attacks that exist with non-authenticated frames. See Section 12 for more information.
发现线程：AC的发现线程负责接收和响应发现请求消息。图4中的状态机转换由数字表示。请注意，发现线程不维护任何特定于每个WTP的上下文信息，并且存在单个状态上下文。AC有必要保护自己免受存在于非认证帧中的各种攻击。更多信息请参见第12节。
Service Thread: The AC's Service thread handles the per-WTP states, and one such thread exists per-WTP connection. This thread is created by the Listener thread when the Authorize state is reached. When created, the Service thread inherits a copy of the state machine context from the Listener thread. When communication with the WTP is complete, the Service thread is terminated and all associated resources are released. The state machine transitions in Figure 4 are represented by alphabetic and punctuation characters.
服务线程：AC的服务线程处理每个WTP状态，每个WTP连接存在一个这样的线程。此线程由侦听器线程在达到授权状态时创建。创建时，服务线程从侦听器线程继承状态机上下文的副本。当与WTP的通信完成时，服务线程被终止，所有相关资源被释放。图4中的状态机转换由字母和标点符号表示。
This section describes the various state transitions, and the events that cause them. This section does not discuss interactions between DTLS- and CAPWAP-specific states. Those interactions, and DTLS-specific states and transitions, are discussed in Section 2.3.2.
本节介绍各种状态转换以及导致它们的事件。本节不讨论DTLS和CAPWAP特定状态之间的交互。第2.3.2节讨论了这些相互作用以及DTL特定状态和转换。
Start to Idle (0): This transition occurs once device initialization is complete.
启动到空闲（0）：一旦设备初始化完成，就会发生此转换。
WTP: This state transition is used to start the WTP's CAPWAP state machine.
WTP：此状态转换用于启动WTP的CAPWAP状态机。
AC: The AC creates the Discovery and Listener threads and starts the CAPWAP state machine.
AC：AC创建发现线程和侦听线程，并启动CAPWAP状态机。
Idle to Discovery (1): This transition occurs to support the CAPWAP discovery process.
空闲到发现（1）：此转换用于支持CAPWAP发现过程。
WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request message (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 4.7). The WTP resets the DiscoveryCount counter to zero (0) (see Section 4.8). The WTP also clears all information from ACs it may have received during a previous Discovery phase.
WTP：WTP在发送第一条发现请求消息之前进入发现状态（参见第5.1节）。进入该状态后，WTP设置DiscoveryInterval计时器（见第4.7节）。WTP将DiscoveryCount计数器重置为零（0）（参见第4.8节）。WTP还清除它在前一发现阶段可能从ACs接收到的所有信息。
AC: This state transition is executed by the AC's Discovery thread, and occurs when a Discovery Request message is received. The AC SHOULD respond with a Discovery Response message (see Section 5.2).
AC：此状态转换由AC的发现线程执行，并在接收到发现请求消息时发生。AC应以发现响应消息进行响应（见第5.2节）。
Discovery to Discovery (#): In the Discovery state, the WTP determines to which AC to connect.
发现到发现（#）：在发现状态下，WTP确定要连接到哪个AC。
WTP: This transition occurs when the DiscoveryInterval timer expires. If the WTP is configured with a list of ACs, it transmits a Discovery Request message to every AC from which it has not received a Discovery Response message. For every transition to this event, the WTP increments the DiscoveryCount counter. See Section 5.1 for more information on how the WTP knows the ACs to which it should transmit the Discovery Request messages. The WTP restarts the DiscoveryInterval timer whenever it transmits Discovery Request messages.
WTP：此转换在DiscoveryInterval计时器过期时发生。如果WTP配置了一个ACs列表，则它会向尚未收到发现响应消息的每个AC发送发现请求消息。对于此事件的每次转换，WTP都会增加DiscoveryCount计数器。请参阅第5.1节，了解WTP如何知道其应将发现请求消息传输到的ACs的更多信息。每当WTP发送发现请求消息时，它都会重新启动DiscoveryInterval计时器。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
Discovery to Idle (2): This transition occurs on the AC's Discovery thread when the Discovery processing is complete.
发现到空闲（2）：当发现处理完成时，此转换在AC的发现线程上发生。
WTP: This is an invalid state transition for the WTP.
WTP：这是WTP的无效状态转换。
AC: This state transition is executed by the AC's Discovery thread when it has transmitted the Discovery Response, in response to a Discovery Request.
AC：此状态转换由AC的发现线程在发送发现响应时执行，以响应发现请求。
Discovery to Sulking (!): This transition occurs on a WTP when AC Discovery fails.
发现到生气（！）：当AC发现失败时，此转换在WTP上发生。
WTP: The WTP enters this state when the DiscoveryInterval timer expires and the DiscoveryCount variable is equal to the MaxDiscoveries variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP protocol messages MUST be ignored.
WTP：当DiscoveryInterval计时器过期且DiscoveryCount变量等于MaxDiscoverys变量时，WTP进入此状态（参见第4.8节）。进入此状态后，WTP必须启动SILENTERVAL定时器。处于生气状态时，必须忽略所有接收到的CAPWAP协议消息。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
Sulking to Idle (@): This transition occurs on a WTP when it must restart the Discovery phase.
闷闷不乐到空闲（@）：当WTP必须重新启动发现阶段时，此转换在WTP上发生。
WTP: The WTP enters this state when the SilentInterval timer (see Section 4.7) expires. The FailedDTLSSessionCount, DiscoveryCount, and FailedDTLSAuthFailCount counters are reset to zero.
WTP：当SILENTERVAL定时器（见第4.7节）过期时，WTP进入该状态。FailedDTLSessionCount、DiscoveryCount和FailedDTLSAuthFailCount计数器重置为零。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
Sulking to Sulking (&): The Sulking state provides the silent period, minimizing the possibility for Denial-of-Service (DoS) attacks.
闷闷不乐（&）：闷闷不乐状态提供了静默期，将拒绝服务（DoS）攻击的可能性降至最低。
WTP: All packets received from the AC while in the sulking state are ignored.
WTP：在生气状态下从AC接收的所有数据包都将被忽略。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
Idle to DTLS Setup (3): This transition occurs to establish a secure DTLS session with the peer.
空闲到DTLS设置（3）：此转换用于与对等方建立安全的DTLS会话。
WTP: The WTP initiates this transition by invoking the DTLSStart command (see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC and the WaitDTLS timer is started (see Section 4.7). When the Discovery phase is bypassed, it is assumed the WTP has locally configured ACs.
WTP：WTP通过调用DTLSStart命令（参见第2.3.2.1节）启动此转换，该命令使用所选AC启动DTLS会话建立，并启动WaitDTLS计时器（参见第4.7节）。绕过发现阶段时，假定WTP已在本地配置了ACs。
AC: Upon entering the Idle state from the Start state, the newly created Listener thread automatically transitions to the DTLS Setup and invokes the DTLSListen command (see Section 2.3.2.1), and the WaitDTLS timer is started (see Section 4.7).
AC：从开始状态进入空闲状态后，新创建的侦听器线程自动转换到DTLS设置并调用DTLSListen命令（请参见第2.3.2.1节），WaitDTLS计时器启动（请参见第4.7节）。
Discovery to DTLS Setup (%): This transition occurs to establish a secure DTLS session with the peer.
发现到DTLS设置（%）：发生此转换是为了与对等方建立安全的DTLS会话。
WTP: The WTP initiates this transition by invoking the DTLSStart command (see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC. The decision of to which AC to connect is the result of the Discovery phase, which is described in Section 3.3.
WTP：WTP通过调用DTLSStart命令（参见第2.3.2.1节）启动此转换，该命令使用所选AC启动DTLS会话建立。连接到哪个AC的决定是发现阶段的结果，如第3.3节所述。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
DTLS Setup to Idle ($): This transition occurs when the DTLS connection setup fails.
DTLS设置为空闲（$）：此转换在DTLS连接设置失败时发生。
WTP: The WTP initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired.
WTP：当WTP收到来自DTLS的DTLSEstablishFail通知（参见第2.3.2.2节）且FailedDTLSessionCount或FailedDTLSAuthFailCount计数器未达到MaxFailedDTLSessionRetry变量的值（参见第4.8节）时，WTP启动此状态转换。此错误通知中止安全DTLS会话建立。收到此通知时，FailedDTLSessionCount计数器将递增。如果WaitDTLS计时器已过期，也会发生此状态转换。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
DTLS Setup to Sulking (*): This transition occurs when repeated attempts to set up the DTLS connection have failed.
DTLS设置为生气（*）：当多次尝试设置DTLS连接失败时，会发生此转换。
WTP: The WTP enters this state when the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP and DTLS protocol messages received MUST be ignored.
WTP：当FailedDTLSessionCount或FailedDTLSAuthFailCount计数器达到MaxFailedDTLSessionRetry变量的值时，WTP进入此状态（参见第4.8节）。进入此状态后，WTP必须启动SILENTERVAL定时器。在生气状态下，必须忽略所有接收到的CAPWAP和DTLS协议消息。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS Session failed to be established.
DTLS设置到DTLS设置（4）：当无法建立DTLS会话时，会发生此转换。
WTP: This is an invalid state transition for the WTP.
WTP：这是WTP的无效状态转换。
AC: The AC's Listener initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. The Listener thread then invokes the DTLSListen command (see Section 2.3.2.1).
AC：当AC的侦听器从DTLS接收到DTLSEstablishFail通知时，会启动此状态转换（请参阅第2.3.2.2节）。此错误通知中止安全DTLS会话建立。收到此通知时，FailedDTLSessionCount计数器将递增。侦听器线程随后调用DTLSListen命令（请参阅第2.3.2.1节）。
DTLS Setup to Authorize (5): This transition occurs when an incoming DTLS session is being established, and the DTLS stack needs authorization to proceed with the session establishment.
DTLS设置为授权（5）：在建立传入DTLS会话时发生此转换，DTLS堆栈需要授权才能继续建立会话。
WTP: This state transition occurs when the WTP receives the DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon entering this state, the WTP performs an authorization check against the AC credentials. See Section 2.4.4 for more information on AC authorization.
WTP：当WTP收到DTLSPeerAuthorize通知时，发生这种状态转换（参见第2.3.2.2节）。进入此状态后，WTP将根据AC凭据执行授权检查。有关AC授权的更多信息，请参见第2.4.4节。
AC: This state transition is handled by the AC's Listener thread when the DTLS module initiates the DTLSPeerAuthorize notification (see Section 2.3.2.2). The Listener thread forks an instance of the Service thread, along with a copy of the state context. Once created, the Service thread performs an authorization check against the WTP credentials. See Section 2.4.4 for more information on WTP authorization.
AC：当DTLS模块启动DTLSPeerAuthorize通知时，该状态转换由AC的侦听器线程处理（参见第2.3.2.2节）。侦听器线程分叉服务线程的实例以及状态上下文的副本。创建后，服务线程将根据WTP凭据执行授权检查。有关WTP授权的更多信息，请参见第2.4.4节。
Authorize to DTLS Setup (6): This transition is executed by the Listener thread to enable it to listen for new incoming sessions.
授权给DTLS设置（6）：此转换由侦听器线程执行，以使其能够侦听新的传入会话。
WTP: This is an invalid state transition for the WTP.
WTP：这是WTP的无效状态转换。
AC: This state transition occurs when the AC's Listener thread has created the WTP context and the Service thread. The Listener thread then invokes the DTLSListen command (see Section 2.3.2.1).
AC：当AC的侦听器线程创建了WTP上下文和服务线程时，就会发生这种状态转换。侦听器线程随后调用DTLSListen命令（请参阅第2.3.2.1节）。
Authorize to DTLS Connect (a): This transition occurs to notify the DTLS stack that the session should be established.
授权给DTLS连接（a）：发生此转换是为了通知DTLS堆栈应该建立会话。
WTP: This state transition occurs when the WTP has successfully authorized the AC's credentials (see Section 2.4.4). This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1).
WTP：当WTP已成功授权AC的凭证时，会发生这种状态转换（见第2.4.4节）。这是通过调用DTLSAccept DTLS命令来完成的（参见第2.3.2.1节）。
AC: This state transition occurs when the AC has successfully authorized the WTP's credentials (see Section 2.4.4). This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1).
AC：当AC成功授权WTP的凭证时，会发生这种状态转换（见第2.4.4节）。这是通过调用DTLSAccept DTLS命令来完成的（参见第2.3.2.1节）。
Authorize to DTLS Teardown (b): This transition occurs to notify the DTLS stack that the session should be aborted.
授权给DTLS拆卸（b）：发生此转换是为了通知DTLS堆栈应该中止会话。
WTP: This state transition occurs when the WTP has been unable to authorize the AC, using the AC credentials. The WTP then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：当WTP无法使用AC凭据授权AC时，会发生此状态转换。然后，WTP通过调用DTLSAbortSession命令中止DTLS会话（参见第2.3.2.1节）。如果WaitDTLS计时器已过期，也会发生此状态转换。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: This state transition occurs when the AC has been unable to authorize the WTP, using the WTP credentials. The AC then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：当AC无法使用WTP凭据授权WTP时，会发生此状态转换。AC然后通过调用DTLSAbortSession命令中止DTLS会话（参见第2.3.2.1节）。如果WaitDTLS计时器已过期，也会发生此状态转换。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Session failed to be established.
DTLS连接到DTLS拆卸（c）：当无法建立DTLS会话时，会发生此转换。
WTP: This state transition occurs when the WTP receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this transition occurs due to the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount is incremented; otherwise, the FailedDTLSSessionCount counter is incremented. This state transition also occurs if the WaitDTLS timer has expired. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：当WTP收到DTLSAborted或DTLSAuthenticateFail通知（参见第2.3.2.2节）时，会发生此状态转换，表明DTLS会话未成功建立。由于DTLSAuthenticateFail通知而发生此转换时，FailedDTLSAuthenticateFailCount将增加；否则，FailedDTLSessionCount计数器将递增。如果WaitDTLS计时器已过期，也会发生此状态转换。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: This state transition occurs when the AC receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established, and both of the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This state transition also occurs if the WaitDTLS timer has expired. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：当AC接收到DTLSAborted或DTLSAuthenticateTail通知（请参阅第2.3.2.2节）时，会发生此状态转换，这表明DTLS会话未成功建立，并且FailedDTLSAuthFailCount和FailedDTLSessionCount计数器均未达到MaxFailedDTLSessionRetry变量的值（参见第4.8节）。如果WaitDTLS计时器已过期，也会发生此状态转换。AC启动DTLSSessionDelete计时器（参见第4.7.6节）。
DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established.
DTLS连接到加入（d）：成功建立DTLS会话时发生此转换。
WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the
WTP：当WTP收到DTLSEstablished通知（参见第2.3.2.2节）表示DTLS会话已成功建立时，会发生此状态转换。收到此通知后
FailedDTLSSessionCount counter is set to zero. The WTP enters the Join state by transmitting the Join Request to the AC. The WTP stops the WaitDTLS timer.
FailedDTLSessionCount计数器设置为零。WTP通过向AC发送加入请求进入加入状态。WTP停止WaitDTLS计时器。
AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The AC stops the WaitDTLS timer, and starts the WaitJoin timer.
AC：当AC收到DTLS已建立的通知（参见第2.3.2.2节）时，会发生这种状态转换，表明DTLS会话已成功建立。收到此通知时，FailedDTLSessionCount计数器设置为零。AC停止WaitDTLS计时器，并启动WaitJoin计时器。
Join to DTLS Teardown (e): This transition occurs when the join process has failed.
连接到DTLS拆卸（e）：当连接过程失败时，会发生此转换。
WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, or if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：当WTP收到包含错误的结果代码消息元素的加入响应消息时，或者如果AC在加入响应消息中提供的映像标识符不同于WTP当前运行的固件版本，并且WTP在其非易失性内存中具有请求的映像，则会发生此状态转换。这导致WTP启动DTLSShutdown命令（见第2.3.2.1节）。如果WTP接收到以下DTLS通知之一，也会发生此转换：DTLSAborted、DTLSRemobleyFailure或DTLSPeerDisconnect。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: This state transition occurs either if the WaitJoin timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：如果WaitJoin计时器过期，或者如果AC发送带有包含错误的结果代码消息元素的Join响应消息，则会发生此状态转换。这导致AC启动DTLSShutdown命令（见第2.3.2.1节）。如果AC接收到以下DTLS通知之一，也会发生此转换：DTLSAborted、DTLSRemobleyFailure或DTLSPeerDisconnect。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
Join to Image Data (f): This state transition is used by the WTP and the AC to download executable firmware.
连接到映像数据（f）：WTP和AC使用此状态转换下载可执行固件。
WTP: The WTP enters the Image Data state when it receives a successful Join Response message and determines that the software version in the Image Identifier message element is not the same as its currently running image. The WTP also detects that the requested image version is not currently available in the WTP's non-volatile storage (see Section 9.1 for a full description of the firmware download process). The WTP initializes the EchoInterval timer (see
WTP：当WTP收到成功加入响应消息并确定Image Identifier message元素中的软件版本与其当前运行的映像不同时，WTP将进入映像数据状态。WTP还检测到请求的映像版本当前在WTP的非易失性存储器中不可用（有关固件下载过程的完整说明，请参阅第9.1节）。WTP初始化EchoInterval计时器（请参阅
Section 4.7), and transmits the Image Data Request message (see Section 9.1.1) requesting the start of the firmware download.
第4.7节），并传输图像数据请求消息（见第9.1.1节），请求开始固件下载。
AC: This state transition occurs when the AC receives the Image Data Request message from the WTP, after having sent its Join Response to the WTP. The AC stops the WaitJoin timer. The AC MUST transmit an Image Data Response message (see Section 9.1.2) to the WTP, which includes a portion of the firmware.
AC：当AC向WTP发送其加入响应后，从WTP接收到图像数据请求消息时，会发生此状态转换。空调停止WaitJoin定时器。AC必须向WTP发送图像数据响应消息（见第9.1.2节），WTP包括一部分固件。
Join to Configure (g): This state transition is used by the WTP and the AC to exchange configuration information.
连接到配置（g）：WTP和AC使用此状态转换来交换配置信息。
WTP: The WTP enters the Configure state when it receives a successful Join Response message, and determines that the included Image Identifier message element is the same as its currently running image. The WTP transmits the Configuration Status Request message (see Section 8.2) to the AC with message elements describing its current configuration.
WTP：WTP在接收到成功加入响应消息时进入配置状态，并确定包含的映像标识符消息元素与其当前运行的映像相同。WTP向AC发送配置状态请求消息（见第8.2节），其中包含描述其当前配置的消息元素。
AC: This state transition occurs when it receives the Configuration Status Request message from the WTP (see Section 8.2), which MAY include specific message elements to override the WTP's configuration. The AC stops the WaitJoin timer. The AC transmits the Configuration Status Response message (see Section 8.3) and starts the ChangeStatePendingTimer timer (see Section 4.7).
AC：当接收到来自WTP的配置状态请求消息（见第8.2节）时，该状态转换发生，该消息可能包括覆盖WTP配置的特定消息元素。空调停止WaitJoin定时器。AC传输配置状态响应消息（见第8.3节）并启动ChangeStatePendingTimer定时器（见第4.7节）。
Configure to Reset (h): This state transition is used to reset the connection either due to an error during the configuration phase, or when the WTP determines it needs to reset in order for the new configuration to take effect. The CAPWAP Reset command is used to indicate to the peer that it will initiate a DTLS teardown.
配置重置（h）：此状态转换用于重置由于配置阶段中的错误导致的连接，或者当WTP确定需要重置以使新配置生效时，重置连接。CAPWAP Reset命令用于向对等方指示它将启动DTLS拆卸。
WTP: The WTP enters the Reset state when it receives a Configuration Status Response message indicating an error or when it determines that a reset of the WTP is required, due to the characteristics of a new configuration.
WTP：当WTP收到指示错误的配置状态响应消息时，或当它确定由于新配置的特性需要重置WTP时，WTP进入重置状态。
AC: The AC transitions to the Reset state when it receives a Change State Event message from the WTP that contains an error for which AC policy does not permit the WTP to provide service. This state transition also occurs when the AC ChangeStatePendingTimer timer expires.
AC：当AC从WTP接收到包含AC策略不允许WTP提供服务的错误的更改状态事件消息时，AC转换为重置状态。当AC ChangeStatePendingTimer计时器过期时，也会发生此状态转换。
Configure to DTLS Teardown (i): This transition occurs when the configuration process aborts due to a DTLS error.
配置为DTLS拆卸（i）：当配置过程因DTLS错误而中止时，会发生此转换。
WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTP在收到以下DTLS通知之一时进入此状态：DTLSAborted、DTLSRebulizayFailure或DTLSPeerDisconnect（参见第2.3.2.2节）。如果WTP频繁收到DTLSDECAPFAILE通知，它可能会中断DTLS会话。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：AC在收到以下DTLS通知之一时进入此状态：DTLSAborted、DTLSRebulationFailure或DTLSPeerDisconnect（参见第2.3.2.2节）。如果AC频繁收到DTLSDECAPFAILE通知，它可能会中断DTLS会话。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
Image Data to Image Data (j): The Image Data state is used by the WTP and the AC during the firmware download phase.
图像数据到图像数据（j）：在固件下载阶段，WTP和AC使用图像数据状态。
WTP: The WTP enters the Image Data state when it receives an Image Data Response message indicating that the AC has more data to send. This state transition also occurs when the WTP receives the subsequent Image Data Requests, at which time it resets the ImageDataStartTimer time to ensure it receives the next expected Image Data Request from the AC. This state transition can also occur when the WTP's EchoInterval timer (see Section 4.7.7) expires, in which case the WTP transmits an Echo Request message (see Section 7.1), and resets its EchoInterval timer. The state transition also occurs when the WTP receives an Echo Response from the AC (see Section 7.2).
WTP：WTP在收到图像数据响应消息时进入图像数据状态，该消息指示AC有更多数据要发送。当WTP接收到后续图像数据请求时，也会发生此状态转换，此时它会重置ImageDataStartTimer时间，以确保从AC接收到下一个预期的图像数据请求。当WTP的EchoInterval计时器（见第4.7.7节）过期时，也会发生此状态转换，在这种情况下，WTP发送回显请求消息（见第7.1节），并重置其回显间隔计时器。当WTP接收到来自AC的回声响应时，也会发生状态转换（参见第7.2节）。
AC: This state transition occurs when the AC receives the Image Data Response message from the WTP while already in the Image Data state. This state transition also occurs when the AC receives an Echo Request (see Section 7.1) from the WTP, in which case it responds with an Echo Response (see Section 7.2), and resets its EchoInterval timer (see Section 4.7.7).
AC：当AC在已处于图像数据状态时从WTP接收到图像数据响应消息时，会发生此状态转换。当AC收到来自WTP的回音请求（见第7.1节）时，也会发生这种状态转换，在这种情况下，AC会用回音响应（见第7.2节）进行响应，并重置其回音间隔计时器（见第4.7.7节）。
Image Data to Reset (k): This state transition is used to reset the DTLS connection prior to restarting the WTP after an image download.
要重置的图像数据（k）：此状态转换用于在图像下载后重新启动WTP之前重置DTLS连接。
WTP: When an image download completes, or if the ImageDataStartTimer timer expires, the WTP enters the Reset state. The WTP MAY also transition to this state upon receiving an Image Data Response message from the AC (see Section 9.1.2) indicating a failure.
WTP：当图像下载完成时，或者如果ImageDataStartTimer计时器过期，WTP将进入重置状态。WTP也可以在从AC接收到指示故障的图像数据响应消息（见第9.1.2节）后转换到该状态。
AC: The AC enters the Reset state either when the image transfer has successfully completed or an error occurs during the image download process.
AC：当图像传输成功完成或图像下载过程中出现错误时，AC进入重置状态。
Image Data to DTLS Teardown (l): This transition occurs when the firmware download process aborts due to a DTLS error.
图像数据到DTLS拆卸（l）：当固件下载过程因DTLS错误而中止时，会发生此转换。
WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTP在收到以下DTLS通知之一时进入此状态：DTLSAborted、DTLSRebulizayFailure或DTLSPeerDisconnect（参见第2.3.2.2节）。如果WTP频繁收到DTLSDECAPFAILE通知，它可能会中断DTLS会话。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：AC在收到以下DTLS通知之一时进入此状态：DTLSAborted、DTLSRebulationFailure或DTLSPeerDisconnect（参见第2.3.2.2节）。如果AC频繁收到DTLSDECAPFAILE通知，它可能会中断DTLS会话。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
Configure to Data Check (m): This state transition occurs when the WTP and AC confirm the configuration.
配置到数据检查（m）：此状态转换在WTP和AC确认配置时发生。
WTP: The WTP enters this state when it receives a successful Configuration Status Response message from the AC. The WTP transmits the Change State Event Request message (see Section 8.6).
WTP：当WTP收到来自AC的成功配置状态响应消息时，WTP进入该状态。WTP发送变更状态事件请求消息（见第8.6节）。
AC: This state transition occurs when the AC receives the Change State Event Request message (see Section 8.6) from the WTP. The AC responds with a Change State Event Response message (see Section 8.7). The AC MUST start the DataCheckTimer timer and stops the ChangeStatePendingTimer timer (see Section 4.7).
AC：当AC从WTP接收到变更状态事件请求消息（见第8.6节）时，发生状态转换。空调用一条变更状态事件响应消息进行响应（见第8.7节）。AC必须启动DataCheckTimer定时器并停止ChangeStatePendingTimer定时器（见第4.7节）。
Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange.
数据检查到DTLS拆卸（n）：此转换发生在WTP未完成数据检查交换时。
WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP retransmission timeout occurs. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：如果WTP在CAPWAP重新传输超时发生之前未收到更改状态事件响应消息，则会发生此状态转换。如果基础可靠传输的重新传输计数计数器已达到MaxRetransmit变量，则WTP也会转换到此状态（请参阅第4.7节）。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: The AC enters this state when the DataCheckTimer timer expires (see Section 4.7). The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：当DataCheckTimer计时器过期时，AC进入该状态（参见第4.7节）。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
Data Check to Run (o): This state transition occurs when the linkage between the control and data channels is established, causing the WTP and AC to enter their normal state of operation.
数据检查运行（o）：当控制通道和数据通道之间建立链接时，会发生此状态转换，导致WTP和AC进入正常运行状态。
WTP: The WTP enters this state when it receives a successful Change State Event Response message from the AC. The WTP initiates the data channel, which MAY require the establishment of a DTLS session, starts the DataChannelKeepAlive timer (see Section 4.7.2) and transmits a Data Channel Keep-Alive packet (see Section 4.4.1). The WTP then starts the EchoInterval timer and DataChannelDeadInterval timer (see Section 4.7).
WTP：当WTP收到来自AC的成功更改状态事件响应消息时，WTP进入该状态。WTP启动数据通道，可能需要建立DTLS会话，启动DataChannelKeepAlive计时器（见第4.7.2节），并传输数据通道保持活动数据包（见第4.4.1节）。然后，WTP启动EchoInterval定时器和DataChannelDeadInterval定时器（参见第4.7节）。
AC: This state transition occurs when the AC receives the Data Channel Keep-Alive packet (see Section 4.4.1), with a Session ID message element matching that included by the WTP in the Join Request message. The AC disables the DataCheckTimer timer. Note that if AC policy is to require the data channel to be encrypted, this process would also require the establishment of a data channel DTLS session. Upon receiving the Data Channel Keep-Alive packet, the AC transmits its own Data Channel Keep Alive packet.
AC：当AC接收到数据通道保持活动数据包（见第4.4.1节）时，该状态转换发生，会话ID消息元素与WTP在加入请求消息中包含的会话ID消息元素匹配。AC禁用数据检查计时器。请注意，如果AC策略要求对数据通道进行加密，则此过程还需要建立数据通道DTLS会话。在接收到数据信道保持活动分组时，AC发送其自己的数据信道保持活动分组。
Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down.
运行到DTLS拆卸（p）：当DTLS堆栈中发生错误，导致DTLS会话被拆卸时，会发生此状态转换。
WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：WTP在收到以下DTLS通知之一时进入此状态：DTLSAborted、DTLSRebulizayFailure或DTLSPeerDisconnect（参见第2.3.2.2节）。如果WTP频繁收到DTLSDECAPFAILE通知，它可能会中断DTLS会话。如果基础可靠传输的重新传输计数计数器已达到MaxRetransmit变量，则WTP也会转换到此状态（请参阅第4.7节）。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect (see Section 2.3.2.2). The AC MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). This state transition also occurs when the AC's EchoInterval timer (see Section 4.7.7) expires. The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：AC在收到以下DTLS通知之一时进入此状态：DTLSAborted、DTLSRebulationFailure或DTLSPeerDisconnect（参见第2.3.2.2节）。如果AC频繁收到DTLSDECAPFAILE通知，它可能会中断DTLS会话。如果基础可靠传输的重新传输计数计数器已达到MaxRetransmit变量，则AC将转换到此状态（请参阅第4.7节）。当AC的EchoInterval定时器（见第4.7.7节）到期时，也会发生这种状态转换。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
Run to Run (q): This is the normal state of operation.
运行到运行（q）：这是正常的运行状态。
WTP: This is the WTP's normal state of operation. The WTP resets its EchoInterval timer whenever it transmits a request to the AC. There are many events that result in this state transition:
WTP：这是WTP的正常运行状态。WTP在向AC发送请求时重置其EchoInterval计时器。有许多事件导致此状态转换：
Configuration Update: The WTP receives a Configuration Update Request message (see Section 8.4). The WTP MUST respond with a Configuration Update Response message (see Section 8.5).
配置更新：WTP接收配置更新请求消息（见第8.4节）。WTP必须响应配置更新响应消息（见第8.5节）。
Change State Event: The WTP receives a Change State Event Response message, or determines that it must initiate a Change State Event Request message, as a result of a failure or change in the state of a radio.
更改状态事件：WTP接收更改状态事件响应消息，或确定它必须启动更改状态事件请求消息，因为无线电状态发生故障或更改。
Echo Request: The WTP sends an Echo Request message (Section 7.1) or receives the corresponding Echo Response message, (see Section 7.2) from the AC. When the WTP receives the Echo Response, it resets its EchoInterval timer (see Section 4.7.7).
回波请求：WTP从AC发送回波请求消息（第7.1节）或接收相应的回波响应消息（见第7.2节）。当WTP接收回波响应时，它重置其回波间隔计时器（见第4.7.7节）。
Clear Config Request: The WTP receives a Clear Configuration Request message (see Section 8.8) and MUST generate a corresponding Clear Configuration Response message (see Section 8.9). The WTP MUST reset its configuration back to manufacturer defaults.
清除配置请求：WTP收到清除配置请求消息（见第8.8节），必须生成相应的清除配置响应消息（见第8.9节）。WTP必须将其配置重置回制造商默认值。
WTP Event: The WTP sends a WTP Event Request message, delivering information to the AC (see Section 9.4). The WTP receives a WTP Event Response message from the AC (see Section 9.5).
WTP事件：WTP发送一条WTP事件请求消息，向AC传递信息（见第9.4节）。WTP从AC接收WTP事件响应消息（见第9.5节）。
Data Transfer: The WTP sends a Data Transfer Request or Data Transfer Response message to the AC (see Section 9.6). The WTP receives a Data Transfer Request or Data Transfer Response message from the AC (see Section 9.6). Upon receipt of a Data Transfer Request, the WTP transmits a Data Transfer Response to the AC.
数据传输：WTP向AC发送数据传输请求或数据传输响应消息（见第9.6节）。WTP从AC接收数据传输请求或数据传输响应消息（见第9.6节）。在收到数据传输请求后，WTP向AC发送数据传输响应。
Station Configuration Request: The WTP receives a Station Configuration Request message (see Section 10.1), to which it MUST respond with a Station Configuration Response message (see Section 10.2).
车站配置请求：WTP收到车站配置请求消息（见第10.1节），必须用车站配置响应消息（见第10.2节）对其作出响应。
AC: This is the AC's normal state of operation. Note that the receipt of any Request from the WTP causes the AC to reset its EchoInterval timer (see Section 4.7.7).
空调：这是空调的正常工作状态。请注意，收到WTP的任何请求会导致AC重置其EchoInterval计时器（见第4.7.7节）。
Configuration Update: The AC sends a Configuration Update Request message (see Section 8.4) to the WTP to update its configuration. The AC receives a Configuration Update Response message (see Section 8.5) from the WTP.
配置更新：AC向WTP发送配置更新请求消息（见第8.4节），以更新其配置。AC从WTP接收配置更新响应消息（见第8.5节）。
Change State Event: The AC receives a Change State Event Request message (see Section 8.6), to which it MUST respond with the Change State Event Response message (see Section 8.7).
变更状态事件：AC收到变更状态事件请求消息（见第8.6节），必须使用变更状态事件响应消息（见第8.7节）对其作出响应。
Echo Request: The AC receives an Echo Request message (see Section 7.1), to which it MUST respond with an Echo Response message (see Section 7.2).
回显请求：AC接收回显请求消息（见第7.1节），必须使用回显响应消息（见第7.2节）对其作出响应。
Clear Config Response: The AC sends a Clear Configuration Request message (see Section 8.8) to the WTP to clear its configuration. The AC receives a Clear Configuration Response message from the WTP (see Section 8.9).
清除配置响应：AC向WTP发送清除配置请求消息（见第8.8节），以清除其配置。AC从WTP接收到一条明确的配置响应消息（见第8.9节）。
WTP Event: The AC receives a WTP Event Request message from the WTP (see Section 9.4) and MUST generate a corresponding WTP Event Response message (see Section 9.5).
WTP事件：AC从WTP接收WTP事件请求消息（见第9.4节），并且必须生成相应的WTP事件响应消息（见第9.5节）。
Data Transfer: The AC sends a Data Transfer Request or Data Transfer Response message to the WTP (see Section 9.6). The AC receives a Data Transfer Request
数据传输：AC向WTP发送数据传输请求或数据传输响应消息（见第9.6节）。AC接收数据传输请求
or Data Transfer Response message from the WTP (see Section 9.6). Upon receipt of a Data Transfer Request, the AC transmits a Data Transfer Response to the WTP.
或来自WTP的数据传输响应消息（见第9.6节）。收到数据传输请求后，AC向WTP发送数据传输响应。
Station Configuration Request: The AC sends a Station Configuration Request message (see Section 10.1) or receives the corresponding Station Configuration Response message (see Section 10.2) from the WTP.
车站配置请求：AC从WTP发送车站配置请求消息（见第10.1节）或接收相应的车站配置响应消息（见第10.2节）。
Run to Reset (r): This state transition is used when either the AC or WTP tears down the connection. This may occur as part of normal operation, or due to error conditions.
运行重置（r）：当AC或WTP断开连接时，使用此状态转换。这可能是正常操作的一部分，也可能是由于错误情况。
WTP: The WTP enters the Reset state when it receives a Reset Request message from the AC.
WTP：当WTP收到来自AC的重置请求消息时，WTP进入重置状态。
AC: The AC enters the Reset state when it transmits a Reset Request message to the WTP.
AC：AC向WTP发送重置请求消息时进入重置状态。
Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete to terminate the DTLS session.
重置为DTLS拆卸：当CAPWAP重置完成以终止DTLS会话时，会发生此转换。
WTP: This state transition occurs when the WTP transmits a Reset Response message. The WTP does not invoke the DTLSShutdown command (see Section 2.3.2.1). The WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
WTP：当WTP发送重置响应消息时，会发生此状态转换。WTP不调用DTLSShutdown命令（见第2.3.2.1节）。WTP启动DTLSSessionDelete计时器（见第4.7.6节）。
AC: This state transition occurs when the AC receives a Reset Response message. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). The AC starts the DTLSSessionDelete timer (see Section 4.7.6).
AC：当AC收到重置响应消息时，会发生此状态转换。这导致AC启动DTLSShutdown命令（见第2.3.2.1节）。AC启动DTLSSessionDelete定时器（见第4.7.6节）。
DTLS Teardown to Idle (t): This transition occurs when the DTLS session has been shut down.
DTLS拆卸到空闲（t）：此转换在DTLS会话关闭时发生。
WTP: This state transition occurs when the WTP has successfully cleaned up all resources associated with the control plane DTLS session, or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shut down, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared.
WTP：当WTP已成功清除与控制平面DTLS会话相关的所有资源，或者DTLSSessionDelete计时器（参见第4.7.6节）过期时，会发生此状态转换。如果为数据平面建立了DTLS会话，则数据平面DTLS会话也将关闭，并释放所有资源。为状态机的当前实例设置的任何计时器也将被清除。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
DTLS Teardown to Sulking (u): This transition occurs when repeated attempts to setup the DTLS connection have failed.
DTLS拆卸到生气（u）：当重复尝试设置DTLS连接失败时，会发生此转换。
WTP: The WTP enters this state when the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP and DTLS protocol messages received MUST be ignored.
WTP：当FailedDTLSessionCount或FailedDTLSAuthFailCount计数器达到MaxFailedDTLSessionRetry变量的值时，WTP进入此状态（参见第4.8节）。进入此状态后，WTP必须启动SILENTERVAL定时器。在生气状态下，必须忽略所有接收到的CAPWAP和DTLS协议消息。
AC: This is an invalid state transition for the AC.
AC：这是AC的无效状态转换。
DTLS Teardown to Dead (w): This transition occurs when the DTLS session has been shut down.
DTLS断开到死（w）：此转换在DTLS会话关闭时发生。
WTP: This is an invalid state transition for the WTP.
WTP：这是WTP的无效状态转换。
AC: This state transition occurs when the AC has successfully cleaned up all resources associated with the control plane DTLS session , or if the DTLSSessionDelete timer (see Section 4.7.6) expires. The data plane DTLS session is also shut down, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. The AC's Service thread is terminated.
AC：当AC已成功清除与控制平面DTLS会话相关的所有资源，或者DTLSSessionDelete计时器（见第4.7.6节）过期时，会发生此状态转换。如果为数据平面建立了DTLS会话，则数据平面DTLS会话也将关闭，并释放所有资源。为状态机的当前实例设置的任何计时器也将被清除。AC的服务线程被终止。
This section describes the DTLS Commands used by CAPWAP, and the notifications received from DTLS to the CAPWAP protocol stack.
本节介绍CAPWAP使用的DTLS命令，以及从DTLS接收到CAPWAP协议栈的通知。
Six commands are defined for the CAPWAP to DTLS API. These "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.
为CAPWAP到DTLS API定义了六个命令。这些“命令”是概念性的，可以作为一个或多个函数调用来实现。提供此API定义是为了澄清集成CAPWAP状态机的DTL和CAPWAP组件之间的交互。
Below is a list of the minimal command APIs:
以下是最小命令API的列表：
o DTLSStart is sent to the DTLS component to cause a DTLS session to be established. Upon invoking the DTLSStart command, the WaitDTLS timer is started. The WTP initiates this DTLS command, as the AC does not initiate DTLS sessions.
o DTLSStart被发送到DTLS组件以建立DTLS会话。调用DTLSStart命令后，WaitDTLS计时器启动。WTP启动此DTLS命令，因为AC不启动DTLS会话。
o DTLSListen is sent to the DTLS component to allow the DTLS component to listen for incoming DTLS session requests.
o DTLSListen被发送到DTLS组件，以允许DTLS组件侦听传入的DTLS会话请求。
o DTLSAccept is sent to the DTLS component to allow the DTLS session establishment to continue successfully.
o DTLSAccept被发送到DTLS组件，以允许DTLS会话建立成功继续。
o DTLSAbortSession is sent to the DTLS component to cause the session that is in the process of being established to be aborted. This command is also sent when the WaitDTLS timer expires. When this command is executed, the FailedDTLSSessionCount counter is incremented.
o DTLSAbortSession被发送到DTLS组件，以使正在建立的会话中止。WaitDTLS计时器过期时也会发送此命令。执行此命令时，FailedDTLSessionCount计数器将递增。
o DTLSShutdown is sent to the DTLS component to cause session teardown.
o DTLSShutdown被发送到DTLS组件以导致会话断开。
o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU size used by the DTLS component. See Section 3.5 for more information on MTU Discovery. The default size is 1468 bytes.
o DTLSMtuUpdate由CAPWAP组件发送，以修改DTLS组件使用的MTU大小。有关MTU发现的更多信息，请参见第3.5节。默认大小为1468字节。
DTLS notifications are defined for the DTLS to CAPWAP API. These "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. It is important to note that the notifications listed below MAY cause the CAPWAP state machine to jump from one state to another using a state transition not listed in Section 2.3.1. When a notification listed below occurs, the target CAPWAP state shown in Figure 4 becomes the current state.
DTLS通知是为DTLS到CAPWAP API定义的。这些“通知”是概念性的，可以通过多种方式实现（例如，作为函数返回值）。提供此API定义是为了澄清集成CAPWAP状态机的DTL和CAPWAP组件之间的交互。需要注意的是，下面列出的通知可能会导致CAPWAP状态机使用第2.3.1节中未列出的状态转换从一种状态跳到另一种状态。当出现下面列出的通知时，图4所示的目标CAPWAP状态变为当前状态。
Below is a list of the API notifications:
以下是API通知列表：
o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS session establishment once the peer's identity has been received. This notification MAY be used by the CAPWAP component to authorize the session, based on the peer's identity. The authorization process will lead to the CAPWAP component initiating either the DTLSAccept or DTLSAbortSession commands.
o 在DTLS会话建立期间，一旦接收到对等方的身份，DTLSPeerAuthorize就会发送到CAPWAP组件。CAPWAP组件可根据对等方的身份使用此通知来授权会话。授权过程将导致CAPWAP组件启动DTLSAccept或DTLSAbortSession命令。
o DTLSEstablished is sent to the CAPWAP component to indicate that a secure channel now exists, using the parameters provided during the DTLS initialization process. When this notification is received, the FailedDTLSSessionCount counter is reset to zero. When this notification is received, the WaitDTLS timer is stopped.
o DTLSEstablished被发送到CAPWAP组件，以使用DTLS初始化过程中提供的参数指示安全通道现在存在。收到此通知后，FailedDTLSessionCount计数器将重置为零。收到此通知后，WaitDTLS计时器停止。
o DTLSEstablishFail is sent when the DTLS session establishment has failed, either due to a local error or due to the peer rejecting the session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented.
o 当DTLS会话建立失败时（由于本地错误或由于对等方拒绝会话建立），会发送DTLSEstablishFail。收到此通知时，FailedDTLSessionCount计数器将递增。
o DTLSAuthenticateFail is sent when DTLS session establishment has failed due to an authentication error. When this notification is received, the FailedDTLSAuthFailCount counter is incremented.
o 当DTLS会话建立由于身份验证错误而失败时，将发送DTLSAuthenticateFail。收到此通知时，FailedDTLSAuthFailCount计数器将递增。
o DTLSAborted is sent to the CAPWAP component to indicate that session abort (as requested by CAPWAP) is complete; this occurs to confirm a DTLS session abort or when the WaitDTLS timer expires. When this notification is received, the WaitDTLS timer is stopped.
o DTLSABORD发送到CAPWAP组件，以指示会话中止（根据CAPWAP的请求）已完成；当确认DTLS会话中止或WaitDTLS计时器过期时，会发生这种情况。收到此通知后，WaitDTLS计时器停止。
o DTLSReassemblyFailure MAY be sent to the CAPWAP component to indicate DTLS fragment reassembly failure.
o DTLS重组失败可发送至CAPWAP组件，以指示DTLS片段重组失败。
o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP module to indicate an encryption/authentication failure. This notification is intended for informative purposes only, and is not intended to cause a change in the CAPWAP state machine (see Section 12.4).
o DTLSDecapFailure可能被发送到CAPWAP模块，以指示脱封失败。DTLSDecapFailure可发送至CAPWAP模块，以指示加密/身份验证失败。本通知仅用于提供信息，不用于改变CAPWAP状态机（见第12.4节）。
o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the DTLS session has been torn down. Note that this notification is only received if the DTLS session has been established.
o DTLSPeerDisconnect被发送到CAPWAP组件，以指示DTLS会话已中断。请注意，仅当DTLS会话已建立时，才会收到此通知。
DTLS is used as a tightly integrated, secure wrapper for the CAPWAP protocol. In this document, DTLS and CAPWAP are discussed as nominally distinct entities; 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.
DTLS被用作CAPWAP协议的一个紧密集成的安全包装器。在本文件中，DTL和CAPWAP作为名义上不同的实体进行讨论；然而，它们是紧密耦合的，甚至可能不可分割地实现。由于目前有DTLS库实现，并且由于安全协议（如IPsec、TLS）通常在广泛可用的加速硬件中实现，因此在本文档中保持模块化区别既方便又具有前瞻性。
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.
本节详细介绍了DTLS模块和CAPWAP模块之间的交互，通过“命令”（CAPWAP到DTLS）和“通知”（DTLS到CAPWAP）进行，因为它们在正常操作过程中会遇到。
Details of the DTLS handshake process are specified in [RFC4347]. This section describes the interactions between the DTLS session establishment process and the CAPWAP protocol. Note that the conceptual DTLS state is shown below to help understand the point at which the DTLS states transition. In the normal case, the DTLS handshake will proceed as shown in Figure 5. (NOTE: this example uses certificates, but pre-shared keys are also supported.)
[RFC4347]中规定了DTLS握手过程的详细信息。本节介绍DTLS会话建立过程和CAPWAP协议之间的交互。请注意，下面显示了概念性DTLS状态，以帮助理解DTLS状态转换的点。在正常情况下，DTLS握手将如图5所示进行。（注意：本例使用证书，但也支持预共享密钥。）
============ ============
WTP AC
============ ============
ClientHello ------>
<------ HelloVerifyRequest
(with cookie)
============ ============
WTP AC
============ ============
ClientHello ------>
<------ HelloVerifyRequest
(with cookie)
ClientHello ------>
(with cookie)
<------ ServerHello
<------ Certificate
<------ ServerHelloDone
ClientHello ------>
(with cookie)
<------ ServerHello
<------ Certificate
<------ ServerHelloDone
(WTP callout for AC authorization occurs in CAPWAP Auth state)
（AC授权的WTP调用发生在CAPWAP身份验证状态下）
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished ------>
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished ------>
(AC callout for WTP authorization occurs in CAPWAP Auth state)
（用于WTP授权的AC调用在CAPWAP身份验证状态下发生）
ChangeCipherSpec
<------ Finished
ChangeCipherSpec
<------ Finished
Figure 5: DTLS Handshake
图5:DTLS握手
DTLS, as specified, provides its own retransmit timers with an exponential back-off. [RFC4347] does not specify how long retransmissions should continue. Consequently, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module.
如指定的那样，DTLS提供了自己的具有指数回退的重传计时器。[RFC4347]未指定重新传输应持续多长时间。因此，不完整DTLS握手的超时完全由CAPWAP模块负责。
The DTLS implementation used by CAPWAP MUST support TLS Session Resumption. Session resumption is typically used to establish the DTLS session used for the data channel. Since the data channel uses different port numbers than the control channel, the DTLS implementation on the WTP MUST provide an interface that allows the CAPWAP module to request session resumption despite the use of the different port numbers (TLS implementations usually attempt session resumption only when connecting to the same IP address and port number). Note that session resumption is not guaranteed to occur, and a full DTLS handshake may occur instead.
CAPWAP使用的DTLS实现必须支持TLS会话恢复。会话恢复通常用于建立用于数据通道的DTLS会话。由于数据通道使用的端口号与控制通道不同，因此WTP上的DTLS实现必须提供一个接口，允许CAPWAP模块在使用不同端口号的情况下请求会话恢复（TLS实现通常仅在连接到相同的IP地址和端口号时才尝试会话恢复）。请注意，会话恢复不一定会发生，可能会发生完全DTLS握手。
The DTLS implementation used by CAPWAP MUST use replay detection, per Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles retransmissions by re-encrypting lost frames, any duplicate DTLS frames are either unintentional or malicious and should be silently discarded.
根据[RFC4347]第3.3节，CAPWAP使用的DTLS实现必须使用重播检测。由于CAPWAP协议通过对丢失的帧进行重新加密来处理重传，因此任何重复的DTLS帧都是无意的或恶意的，应该悄悄地丢弃。
The WTP, either through the Discovery process or through pre-configuration, determines to which AC to connect. The WTP uses the DTLSStart command to request that a secure connection be established to the selected AC. Prior to initiation of the DTLS handshake, the WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS timer. If the DTLSEstablished notification is not received prior to timer expiration, the DTLS session is aborted by issuing the DTLSAbortSession DTLS command. This notification causes the CAPWAP module to transition to the Idle state. Upon receiving a DTLSEstablished notification, the WaitDTLS timer is deactivated.
WTP通过发现过程或预配置确定要连接到哪个AC。WTP使用DTLSStart命令请求与所选AC建立安全连接。在启动DTLS握手之前，WTP设置WaitDTLS计时器。在调用DTLSStart或DTLSListen命令时，WTP和AC分别设置WaitDTLS计时器。如果在计时器过期之前未收到DTLSEstablished通知，则通过发出DTLSAbortSession DTLS命令中止DTLS会话。此通知导致CAPWAP模块转换到空闲状态。收到DTLSEstablished通知后，WaitDTLS计时器将停用。
If the AC or WTP does not respond to any DTLS handshake messages sent by its peer, the DTLS specification calls for the message to be retransmitted. Note that during the handshake, when both the AC and the WTP are expecting additional handshake messages, they both retransmit if an expected message has not been received (note that retransmissions for CAPWAP Control messages work differently: all CAPWAP Control messages are either requests or responses, and the peer who sent the request is responsible for retransmissions).
如果AC或WTP不对其对等方发送的任何DTLS握手消息做出响应，则DTLS规范将要求重新传输该消息。请注意，在握手过程中，当AC和WTP都需要额外的握手消息时，如果没有收到预期的消息，它们都会重新传输（请注意，CAPWAP控制消息的重传工作方式不同：所有CAPWAP控制消息都是请求或响应，发送请求的对等方负责重传）。
If the WTP or the AC does not receive an expected DTLS handshake message despite of retransmissions, the WaitDTLS timer will eventually expire, and the session will be terminated. This can happen if communication between the peers has completely failed, or if one of the peers sent a DTLS Alert message that was lost in transit (DTLS does not retransmit Alert messages).
如果WTP或AC在重新传输后仍未收到预期的DTLS握手消息，则WaitDTLS计时器最终将过期，会话将终止。如果对等方之间的通信完全失败，或者其中一个对等方发送了在传输过程中丢失的DTLS警报消息（DTLS不重新传输警报消息），则可能发生这种情况。
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, and SHOULD treat the message as though no cookie were present.
如果cookie无法验证，这可能表示WTP错误，也可能表示DoS攻击。因此，应尽量减少交流资源的利用。AC可能会记录一条指示故障的消息，并应将该消息视为不存在cookie。
Since DTLS Handshake messages are potentially larger than the maximum record size, DTLS supports fragmenting of Handshake messages across multiple records. There are several potential causes of re-assembly
由于DTLS握手消息可能大于最大记录大小，因此DTLS支持跨多个记录对握手消息进行分段。有几种可能导致重新组装的原因
errors, including overlapping and/or lost fragments. The DTLS component MUST send a DTLSReassemblyFailure notification to the CAPWAP component. Whether precise information is given along with notification is an implementation issue, and hence is beyond the scope of this document. Upon receipt of such an error, the CAPWAP component SHOULD log an appropriate error message. Whether processing continues or the DTLS session is terminated is implementation dependent.
错误，包括重叠和/或丢失的片段。DTLS组件必须向CAPWAP组件发送DTLSRebulationFailure通知。是否随通知一起提供准确信息是一个实施问题，因此超出了本文件的范围。收到此类错误后，CAPWAP组件应记录相应的错误消息。处理是否继续或DTLS会话是否终止取决于实现。
DTLS decapsulation errors consist of three types: decryption errors, 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, decryption failures are reported as authentication failures. The DTLS component MUST provide a DTLSDecapFailure notification to the CAPWAP component 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.
DTLS解除封装错误包括三种类型：解密错误、身份验证错误和格式错误的DTLS记录头。由于DTLS在封装之前对数据进行身份验证，因此如果解密失败，则在不首先尝试对数据包进行身份验证的情况下很难检测到这一点。如果身份验证失败，也可能出现解密错误，但不能保证。解密失败被报告为身份验证失败，而不是试图推导（并要求实现）检测解密失败的算法。发生此类错误时，DTLS组件必须向CAPWAP组件提供DTLSDecapFailure通知。如果检测到格式不正确的DTLS记录头，则应悄悄丢弃数据包，并且接收方可能会记录错误消息。
There is currently only one encapsulation error defined: MTU exceeded. As part of DTLS session establishment, the CAPWAP component informs the DTLS component of the MTU size. This may be dynamically modified at any time when the CAPWAP component sends the DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). The value provided to the DTLS stack is the result of the MTU Discovery process, which is described in Section 3.5. The DTLS component returns this notification to the CAPWAP component whenever a transmission request will result in a packet that exceeds the MTU.
当前仅定义了一个封装错误：超出MTU。作为DTLS会话建立的一部分，CAPWAP组件通知DTLS组件MTU大小。当CAPWAP组件向DTLS组件发送DTLSMtuUpdate命令时，可以随时动态修改该命令（请参见第2.3.2.1节）。提供给DTLS堆栈的值是MTU发现过程的结果，如第3.5节所述。当传输请求将导致数据包超过MTU时，DTLS组件将此通知返回给CAPWAP组件。
DTLS supports endpoint authentication with certificates or pre-shared keys. The TLS algorithm suites for each endpoint authentication method are described below.
DTLS支持使用证书或预共享密钥进行端点身份验证。每个端点身份验证方法的TLS算法套件如下所述。
CAPWAP implementations only use cipher suites that are recommended for use with DTLS, see [DTLS-DESIGN]. At present, the following algorithms MUST be supported when using certificates for CAPWAP authentication:
CAPWAP实施仅使用推荐用于DTLS的密码套件，请参阅[DTLS-DESIGN]。目前，在使用证书进行CAPWAP身份验证时，必须支持以下算法：
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_RSA_与_AES_128_CBC_SHA[RFC5246]
The following algorithms SHOULD be supported when using certificates:
使用证书时应支持以下算法：
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_DHE_RSA_与_AES_128_CBC_SHA[RFC5246]
The following algorithms MAY be supported when using certificates:
使用证书时，可能支持以下算法：
o TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_RSA_与_AES_256_CBC_SHA[RFC5246]
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_RSA_与_AES_256_CBC_SHA[RFC5246]
Additional ciphers MAY be defined in subsequent CAPWAP specifications.
其他密码可在后续CAPWAP规范中定义。
Pre-shared keys present significant challenges from a security perspective, and for that reason, their use is strongly discouraged. Several methods for authenticating with pre-shared keys are defined [RFC4279], and we focus on the following two:
从安全角度来看，预共享密钥存在重大挑战，因此，强烈反对使用它们。定义了几种使用预共享密钥进行身份验证的方法[RFC4279]，我们主要关注以下两种方法：
o Pre-Shared Key (PSK) key exchange algorithm - simplest method, ciphersuites use only symmetric key algorithms.
o 预共享密钥（PSK）密钥交换算法-最简单的方法，密码套件仅使用对称密钥算法。
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 DHE_PSK密钥交换算法-使用PSK对Diffie-Hellman交换进行身份验证。这些密码套件对字典攻击提供了一些额外的保护，还提供了完美的前向保密（PFS）。
The first approach (plain PSK) is susceptible to passive dictionary attacks; hence, while this algorithm MUST 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.
第一种方法（普通PSK）容易受到被动字典攻击；因此，虽然必须支持该算法，但在选择该方法时应特别小心。特别是，不应使用用户可读的密码短语，并且应强烈反对使用简短的PSK。
The following cryptographic algorithms MUST be supported when using pre-shared keys:
使用预共享密钥时，必须支持以下加密算法：
o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_PSK_与_AES_128_CBC_SHA[RFC5246]
o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246]
o TLS_DHE_PSK_与_AES_128_CBC_SHA[RFC5246]
The following algorithms MAY be supported when using pre-shared keys:
使用预共享密钥时，可能支持以下算法：
o TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_PSK_与_AES_256_CBC_SHA[RFC5246]
o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246]
o TLS_DHE_PSK_与_AES_256_CBC_SHA[RFC5246]
Additional ciphers MAY be defined in following CAPWAP specifications.
其他密码可在以下CAPWAP规范中定义。
Certificate authorization by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may 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.509 certificates MUST include the Extended Key Usage (EKU) certificate extension [RFC5280].
需要AC和WTP的证书授权，以便只有AC可以执行AC的功能，并且只有WTP可以执行WTP的功能。对AC或WTP的功能限制要求AC使用的证书必须与WTP使用的证书区分开来。为了实现这一区别，x.509证书必须包括扩展密钥使用（EKU）证书扩展[RFC5280]。
The EKU field indicates one or more purposes for which a certificate may be used. It is an essential part in authorization. Its syntax is described in [RFC5280] and [ISO.9834-1.1993] and is as follows:
EKU字段表示证书可用于的一个或多个目的。它是授权的一个重要部分。其语法如[RFC5280]和[ISO.9834-1.1993]所述，如下所示：
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
KeyPurposeId ::= OBJECT IDENTIFIER
Here we define two KeyPurposeId values, one for the WTP and one for the AC. Inclusion of one of these two values indicates a certificate is authorized for use by a WTP or AC, respectively. These values are formatted as id-kp fields.
在这里，我们定义了两个KeyPurposeId值，一个用于WTP，一个用于AC。包含这两个值中的一个表示证书分别被WTP或AC授权使用。这些值的格式为id kp字段。
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
All capwap devices MUST support the ExtendedKeyUsage certificate extension if it is present in a certificate. If the extension is present, then the certificate MUST have either the id-kp-capwapAC or the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. Similarly, if the extension is present, a device MUST have the id-kp-capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP.
如果证书中存在ExtendedKeyUsage证书扩展，则所有capwap设备必须支持该扩展。如果存在扩展名，则证书必须具有id kp capwapAC或id kp ANYEXTENDKEYUSAGE KEYPUSIONID作为AC。类似地，如果存在扩展名，则设备必须具有id kp capwapWTP或id kp ANYEXTENDKEYUSAGE KEYPUSIONID作为WTP。
Part of the CAPWAP certificate validation process includes ensuring that the proper EKU is included and allowing the CAPWAP session to be established only if the extension properly represents the device. For instance, an AC SHOULD NOT accept a connection request from another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is present in the certificate.
CAPWAP证书验证过程的一部分包括确保包含正确的EKU，并且仅当扩展正确表示设备时才允许建立CAPWAP会话。例如，AC不应接受来自另一AC的连接请求，因此必须验证证书中是否存在id kp capwapWTP EKU。
CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device.
CAPWAP实施必须支持证书，其中WTP和AC的通用名称（CN）是该设备的MAC地址。
The MAC address MUST be encoded in the PrintableString format, using the well-recognized MAC address format of 01:23:45:67:89:ab. The CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs], and WiMAX [WiMAX]. See Section 12.8 for more information on the use of the MAC address in the CN field.
MAC地址必须使用公认的MAC地址格式01:23:45:67:89:ab以可打印字符串格式编码。CN字段可能包含EUI-48[EUI-48]或EUI-64[EUI-64]MAC地址格式。CN领域的这种看似非常规的使用与其他标准是一致的，这些标准依赖于在制造过程中提供的设备证书，如分组电缆[PacketCable]、电缆实验室[CableLabs]和WiMAX[WiMAX]。有关在CN字段中使用MAC地址的更多信息，请参见第12.8节。
ACs and WTPs MUST authorize (e.g., through access control lists) certificates of devices to which they are connecting, e.g., based on the issuer, MAC address, or organizational information specified in the certificate. The identities specified in the certificates bind a particular DTLS session to a specific pair of mutually authenticated and authorized MAC addresses. The particulars of authorization filter construction are implementation details which are, for the most part, not within the scope of this specification. However, at minimum, all devices MUST verify that the appropriate EKU bit is set according to the role of the peer device (AC versus WTP), and that the issuer of the certificate is appropriate for the domain in question.
ACs和WTP必须授权（例如，通过访问控制列表）其所连接设备的证书，例如，基于证书中指定的颁发者、MAC地址或组织信息。证书中指定的标识将特定DTLS会话绑定到一对特定的相互验证和授权的MAC地址。授权过滤器构造的细节是实现细节，大部分不在本规范的范围内。但是，至少所有设备必须验证是否根据对等设备的角色（AC与WTP）设置了适当的EKU位，以及证书的颁发者是否适合所讨论的域。
When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST contain the "PSK identity hint" field and the ClientKeyExchange message MUST contain the "PSK identity" field. These fields are used to help the WTP select the appropriate PSK for use with the AC, and then indicate to the AC which key is being used. When PSKs are provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for the key MUST be specified.
当DTLS使用PSK密码套件时，ServerKeyExchange消息必须包含“PSK标识提示”字段，ClientKeyExchange消息必须包含“PSK标识”字段。这些字段用于帮助WTP选择与AC一起使用的适当PSK，然后向AC指示正在使用的钥匙。将PSK提供给WTPs和ACs时，必须指定密钥的PSK提示和PSK标识。
The PSK Hint SHOULD uniquely identify the AC and the PSK Identity SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints and identities be the ASCII HEX-formatted MAC addresses of the respective devices, since each pairwise combination of WTP and AC SHOULD have a unique PSK. The PSK Hint and Identity SHOULD be sufficient to perform authorization, as simply having knowledge of a PSK does not necessarily imply authorization.
PSK提示应唯一标识AC，PSK标识应唯一标识WTP。建议这些提示和标识为相应设备的ASCII十六进制格式MAC地址，因为WTP和AC的每个成对组合都应该具有唯一的PSK。PSK提示和标识应该足以执行授权，因为仅仅了解PSK并不一定意味着授权。
If a single PSK is being used for multiple devices on a CAPWAP network, which is NOT RECOMMENDED, the PSK Hint and Identity can no longer be a MAC address, so appropriate hints and identities SHOULD be selected to identify the group of devices to which the PSK is provisioned.
如果CAPWAP网络上的多个设备使用单个PSK（不推荐），则PSK提示和标识不能再是MAC地址，因此应选择适当的提示和标识来标识向其提供PSK的设备组。
Communication between a WTP and an AC is established using the standard UDP client/server model. The CAPWAP protocol supports both UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, UDP is used for the CAPWAP Control and Data channels.
WTP和AC之间的通信是使用标准UDP客户机/服务器模型建立的。CAPWAP协议支持UDP和UDP Lite[RFC3828]传输协议。在IPv4上运行时，UDP用于CAPWAP控制和数据通道。
When run over IPv6, the CAPWAP Control channel always uses UDP, while the CAPWAP Data channel may use either UDP or UDP-Lite. UDP-Lite is the default transport protocol for the CAPWAP Data channel. However, if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is used for the CAPWAP Data channel.
在IPv6上运行时，CAPWAP控制通道始终使用UDP，而CAPWAP数据通道可以使用UDP或UDP Lite。UDP Lite是CAPWAP数据通道的默认传输协议。但是，如果发现了中间盒或IPv4到IPv6网关，则会将UDP用于CAPWAP数据通道。
This section describes how the CAPWAP protocol is carried over IP and UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol message element, Section 4.6.14, describes the rules to use in determining which transport protocol is to be used.
本节介绍如何通过IP和UDP/UDP Lite传输协议传输CAPWAP协议。CAPWAP传输协议消息元素第4.6.14节描述了确定使用哪种传输协议时使用的规则。
In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which they received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port.
为了使CAPWAP与网络中潜在的中间盒兼容，CAPWAP实施必须从接收来自给定对等方流量的同一端口发送返回流量。此外，CAPWAP节点生成的任何未经请求的请求必须在同一端口上发送。
One of the CAPWAP protocol requirements is to allow a WTP to reside behind a middlebox, firewall, and/or Network Address Translation (NAT) device. Since a CAPWAP session is initiated by the WTP (client) to the well-known UDP port of the AC (server), the use of UDP is a logical choice. When CAPWAP is run over IPv4, the UDP checksum field in CAPWAP packets MUST be set to zero.
CAPWAP协议要求之一是允许WTP驻留在中间盒、防火墙和/或网络地址转换（NAT）设备后面。由于CAPWAP会话是由WTP（客户端）启动到AC（服务器）的众所周知的UDP端口，因此使用UDP是一种合乎逻辑的选择。当CAPWAP通过IPv4运行时，CAPWAP数据包中的UDP校验和字段必须设置为零。
CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP Control channel, as defined in Section 1.4. The CAPWAP control port at the AC is the well-known UDP port 5246. The CAPWAP control port at the WTP can be any port selected by the WTP.
从WTP发送到AC的CAPWAP协议控制数据包使用第1.4节中定义的CAPWAP控制信道。AC上的CAPWAP控制端口是众所周知的UDP端口5246。WTP上的CAPWAP控制端口可以是WTP选择的任何端口。
CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP Data channel, as defined in Section 1.4. The CAPWAP data port at the AC is the well-known UDP port 5247. If an AC permits the administrator to change the CAPWAP control port, the CAPWAP data port MUST be the next consecutive port number. The CAPWAP data port at the WTP can be any port selected by the WTP.
从WTP发送到AC的CAPWAP协议数据包使用第1.4节中定义的CAPWAP数据通道。AC上的CAPWAP数据端口是众所周知的UDP端口5247。如果AC允许管理员更改CAPWAP控制端口，则CAPWAP数据端口必须是下一个连续的端口号。WTP上的CAPWAP数据端口可以是WTP选择的任何端口。
When CAPWAP is run over IPv6, UDP-Lite is the default transport protocol, which reduces the checksum processing required for each packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP-Lite is used, the checksum field MUST have a coverage of 8 [RFC3828].
当CAPWAP通过IPv6运行时，UDP Lite是默认的传输协议，它减少了每个数据包所需的校验和处理（与通过IPv6使用UDP[RFC2460]）。使用UDP Lite时，校验和字段的覆盖率必须为8[RFC3828]。
UDP-Lite uses the same port assignments as UDP.
UDP Lite使用与UDP相同的端口分配。
The AC Discovery phase allows the WTP to determine which ACs are available and choose the best AC with which to establish a CAPWAP session. The Discovery phase occurs when the WTP enters the optional Discovery state. A WTP does not need to complete the AC Discovery phase if it uses a pre-configured AC. This section details the mechanism used by a WTP to dynamically discover candidate ACs.
AC发现阶段允许WTP确定哪些AC可用，并选择与之建立CAPWAP会话的最佳AC。当WTP进入可选发现状态时，将发生发现阶段。如果WTP使用预配置的AC，则不需要完成AC发现阶段。本节详细介绍WTP动态发现候选AC所使用的机制。
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 discovering the AC, without requiring that multicast services are enabled in the network.
WTP和AC通常不在同一IP子网（广播域）中。发生这种情况时，WTP必须能够发现AC，而不需要在网络中启用多播服务。
When the WTP attempts to establish communication with an AC, it sends the Discovery Request message and receives the Discovery Response message from the AC(s). The WTP MUST send the Discovery Request message to either the limited broadcast IP address (255.255.255.255), the well-known CAPWAP multicast address (224.0.1.140), or to the unicast IP address of the AC. For IPv6 networks, since broadcast does not exist, the use of "All ACs multicast address" (FF0X:0:0:0:0: 0:0:18C) is used instead. Upon receipt of the Discovery Request message, the AC sends a Discovery Response message to the unicast IP address of the WTP, regardless of whether the Discovery Request message was sent as a broadcast, multicast, or unicast message.
当WTP尝试与AC建立通信时，它发送发现请求消息并从AC接收发现响应消息。WTP必须将发现请求消息发送到有限的广播IP地址（255.255.255.255）、众所周知的CAPWAP多播地址（224.0.1.140）或AC的单播IP地址。对于IPv6网络，由于广播不存在，因此使用“所有ACs多播地址”（FF0X:0:0:0:0:0:0:0:18C）。在接收到发现请求消息时，AC向WTP的单播IP地址发送发现响应消息，而不管发现请求消息是作为广播、多播还是单播消息发送的。
WTP use of a limited IP broadcast, multicast, or unicast IP address is implementation dependent. ACs, on the other hand, MUST support broadcast, multicast, and unicast discovery.
WTP使用有限的IP广播、多播或单播IP地址取决于实现。另一方面，ACs必须支持广播、多播和单播发现。
When a WTP transmits a Discovery Request message to a unicast address, the WTP must first obtain the IP address of the AC. Any static configuration of an AC's IP address on the WTP non-volatile storage is implementation dependent. However, additional dynamic schemes are possible, for example:
当WTP向单播地址发送发现请求消息时，WTP必须首先获取AC的IP地址。WTP非易失性存储器上AC IP地址的任何静态配置取决于实现。但是，也可以使用其他动态方案，例如：
DHCP: See [RFC5417] for more information on the use of DHCP to discover AC IP addresses.
DHCP：有关使用DHCP查找AC IP地址的更多信息，请参阅[RFC5417]。
DNS: The WTP MAY support use of DNS Service Records (SRVs) [RFC2782] to discover the AC address(es). In this case, the WTP first obtains (e.g., from local configuration) the correct domain name suffix (e.g., "example.com") and performs an SRV lookup with Service name "capwap-control" and Proto "udp". Thus, the name resolved in DNS would be, e.g., "_capwap-control._udp.example.com". Note that the SRV record MAY specify a non-default port number for the control channel; the port number for the data channel is the next port number (control channel port + 1).
DNS：WTP可能支持使用DNS服务记录（SRV）[RFC2782]来发现AC地址。在这种情况下，WTP首先获得（例如，从本地配置）正确的域名后缀（例如，“example.com”），并使用服务名“capwap control”和Proto“udp”执行SRV查找。因此，在DNS中解析的名称将是，例如，“capwap-control.\u udp.example.com”。注意，SRV记录可以为控制信道指定非默认端口号；数据通道的端口号是下一个端口号（控制通道端口+1）。
An AC MAY also communicate alternative ACs to the WTP within the Discovery Response message through the AC IPv4 List (see Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses provided in these two message elements are intended to help the WTP discover additional ACs through means other than those listed above.
AC还可以通过AC IPv4列表（参见第4.6.2节）和AC IPv6列表（参见第4.6.2节）在发现响应消息内将备选AC与WTP通信。这两个消息元素中提供的地址旨在帮助WTP通过上述以外的方式发现其他ACs。
The AC Name with Priority message element (see Section 4.6.5) is used to communicate a list of preferred ACs to the WTP. The WTP SHOULD attempt to utilize the ACs listed in the order provided by the AC. The Name-to-IP Address mapping is handled via the Discovery message exchange, in which the ACs provide their identity in the AC Name (see Section 4.6.4) message element in the Discovery Response message.
带有优先级消息元素的AC名称（见第4.6.5节）用于向WTP传达首选AC列表。WTP应尝试利用AC提供的顺序中列出的ACs。名称到IP地址的映射通过发现消息交换进行处理，其中ACs在发现响应消息中的AC名称（见第4.6.4节）消息元素中提供其身份。
Once the WTP has received Discovery Response messages from the candidate ACs, it MAY use other factors to determine the preferred AC. For instance, each binding defines a WTP Radio Information message element (see Section 2.1), which the AC includes in Discovery Response messages. The presence of one or more of these message elements is used to identify the CAPWAP bindings supported by the AC. A WTP MAY connect to an AC based on the supported bindings advertised.
一旦WTP从候选AC接收到发现响应消息，它可以使用其他因素来确定首选AC。例如，每个绑定定义了WTP无线电信息消息元素（参见第2.1节），AC将其包括在发现响应消息中。这些消息元素中的一个或多个元素的存在用于标识AC支持的CAPWAP绑定。WTP可以基于所发布的支持绑定连接到AC。
While fragmentation and reassembly services are provided by IP, the CAPWAP protocol also provides such services. Environments where the CAPWAP protocol is used involve firewall, NAT, and "middlebox" devices, which tend to drop IP fragments to minimize possible DoS attacks. By providing fragmentation and reassembly at the application layer, any fragmentation required due to the tunneling component of the CAPWAP protocol becomes transparent to these intermediate devices. Consequently, the CAPWAP protocol can be used in any network topology including firewall, NAT, and middlebox devices.
虽然碎片和重组服务由IP提供，但CAPWAP协议也提供此类服务。使用CAPWAP协议的环境包括防火墙、NAT和“中间盒”设备，这些设备倾向于丢弃IP片段以最小化可能的DoS攻击。通过在应用层提供碎片和重组，CAPWAP协议的隧道组件所需的任何碎片对这些中间设备都是透明的。因此，CAPWAP协议可用于任何网络拓扑，包括防火墙、NAT和中间盒设备。
It is important to note that the fragmentation mechanism employed by CAPWAP has known limitations and deficiencies, which are similar to those described in [RFC4963]. The limited size of the Fragment ID field (see Section 4.3) can cause wrapping of the field, and hence cause fragments from different datagrams to be incorrectly spliced together (known as "mis-associated"). For example, a 100Mpbs link with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP implementers are warned to properly size their buffers for reassembly purposes based on the expected wireless technology throughput.
需要注意的是，CAPWAP采用的碎片机制具有已知的局限性和缺陷，这些局限性和缺陷与[RFC4963]中描述的相似。片段ID字段的有限大小（见第4.3节）可能会导致字段的包装，从而导致来自不同数据报的片段错误地拼接在一起（称为“错误关联”）。例如，MTU为1500的100Mpbs链路（导致1450字节的碎片）将在8秒内导致碎片ID字段换行。因此，CAPWAP实施者被警告根据预期的无线技术吞吐量适当调整缓冲区大小，以便重新组装。
CAPWAP implementations SHOULD perform MTU Discovery (see Section 3.5), which can avoid the need for fragmentation. At the time of writing of this specification, most enterprise switching and routing infrastructure were capable of supporting "mini-jumbo" frames (1800 bytes), which eliminates the need for fragmentation (assuming the station's MTU is 1500 bytes). The need for fragmentation typically continues to exist when the WTP communicates with the AC over a Wide Area Network (WAN). Therefore, future versions of the CAPWAP protocol SHOULD consider either increasing the size of the Fragment ID field or providing alternative extensions.
CAPWAP实施应执行MTU发现（见第3.5节），这可以避免碎片化的需要。在编写本规范时，大多数企业交换和路由基础设施都能够支持“迷你巨型”帧（1800字节），从而消除了碎片化的需要（假设站点的MTU为1500字节）。当WTP通过广域网（WAN）与AC通信时，通常仍然存在碎片需求。因此，CAPWAP协议的未来版本应该考虑增加片段ID字段的大小或提供替代扩展。
Once a WTP has discovered the AC with which it wishes to establish a CAPWAP session, it SHOULD perform a Path MTU (PMTU) discovery. One recommendation for performing PMTU discovery is to have the WTP transmit Discovery Request (see Section 5.1) messages, and include the MTU Discovery Padding message element (see Section 4.6.32). The actual procedures used for PMTU discovery are described in [RFC1191] for IPv4; for IPv6, [RFC1981] SHOULD be used. Alternatively, implementers MAY use the procedures defined in [RFC4821]. The WTP SHOULD also periodically re-evaluate the PMTU using the guidelines provided in these two RFCs, using the Primary Discovery Request (see Section 5.3) along with the MTU Discovery Padding message element (see Section 4.6.32). When the MTU is initially known, or updated in the case where an existing session already exists, the discovered PMTU is used to configure the DTLS component (see Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit the MTU, defined in Section 3.4.
一旦WTP发现它希望与之建立CAPWAP会话的AC，它应该执行路径MTU（PMTU）发现。执行PMTU发现的一个建议是使用WTP传输发现请求（见第5.1节）消息，并包括MTU发现填充消息元素（见第4.6.32节）。对于IPv4，[RFC1191]中描述了用于PMTU发现的实际过程；对于IPv6，应使用[RFC1981]。或者，实施者可以使用[RFC4821]中定义的程序。WTP还应使用这两个RFC中提供的指南，使用主发现请求（见第5.3节）以及MTU发现填充消息元素（见第4.6.32节），定期重新评估PMTU。当MTU最初已知，或在现有会话已存在的情况下更新时，发现的PMTU用于配置DTLS组件（参见第2.3.2.1节），而非DTLS帧需要分段以适应第3.4节中定义的MTU。
This section contains the CAPWAP protocol packet formats. A CAPWAP protocol packet consists of one or more CAPWAP Transport Layer packet headers followed by a CAPWAP message. The CAPWAP message can be either of type Control or Data, where Control packets carry
本节包含CAPWAP协议数据包格式。CAPWAP协议数据包由一个或多个CAPWAP传输层数据包头和一条CAPWAP消息组成。CAPWAP消息可以是Control类型，也可以是Data类型，其中Control数据包携带
signaling, and Data packets carry user payloads. The CAPWAP frame formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP Data and Control packets are defined below.
信令和数据包承载用户有效载荷。CAPWAP数据包和DTL封装的CAPWAP数据和控制包的CAPWAP帧格式定义如下。
The CAPWAP Control protocol includes two messages that are never protected by DTLS: the Discovery Request message and the Discovery Response message. These messages need to be in the clear to allow the CAPWAP protocol to properly identify and process them. The format of these packets are as follows:
CAPWAP控制协议包括两条从不受DTLS保护的消息：发现请求消息和发现响应消息。这些消息需要保持清晰，以允许CAPWAP协议正确识别和处理它们。这些数据包的格式如下：
CAPWAP Control Packet (Discovery Request/Response):
+-------------------------------------------+
| IP | UDP | CAPWAP | Control | Message |
| Hdr | Hdr | Header | Header | Element(s) |
+-------------------------------------------+
CAPWAP Control Packet (Discovery Request/Response):
+-------------------------------------------+
| IP | UDP | CAPWAP | Control | Message |
| Hdr | Hdr | Header | Header | Element(s) |
+-------------------------------------------+
All other CAPWAP Control protocol messages MUST be protected via the DTLS protocol, which ensures that the packets are both authenticated and encrypted. These packets include the CAPWAP DTLS Header, which is described in Section 4.2. The format of these packets is as follows:
所有其他CAPWAP控制协议消息必须通过DTLS协议进行保护，以确保数据包经过身份验证和加密。这些数据包包括CAPWAP DTLS报头，如第4.2节所述。这些数据包的格式如下：
CAPWAP Control Packet (DTLS Security Required):
+------------------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr |
+------------------------------------------------------------------+
\---------- authenticated -----------/
\------------- encrypted ------------/
CAPWAP Control Packet (DTLS Security Required):
+------------------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr |
+------------------------------------------------------------------+
\---------- authenticated -----------/
\------------- encrypted ------------/
The CAPWAP protocol allows optional protection of data packets, using DTLS. Use of data packet protection is determined by AC policy. When DTLS is utilized, the optional CAPWAP DTLS Header is present, which is described in Section 4.2. The format of CAPWAP Data packets is shown below:
CAPWAP协议允许使用DTL对数据包进行可选保护。数据包保护的使用由AC策略决定。使用DTLS时，会出现可选的CAPWAP DTLS标头，如第4.2节所述。CAPWAP数据包的格式如下所示：
CAPWAP Plain Text Data Packet :
+-------------------------------+
| IP | UDP | CAPWAP | Wireless |
| Hdr | Hdr | Header | Payload |
+-------------------------------+
CAPWAP Plain Text Data Packet :
+-------------------------------+
| IP | UDP | CAPWAP | Wireless |
| Hdr | Hdr | Header | Payload |
+-------------------------------+
DTLS Secured CAPWAP Data Packet:
+--------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr |
+--------------------------------------------------------+
\------ authenticated -----/
\------- encrypted --------/
DTLS Secured CAPWAP Data Packet:
+--------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr |
+--------------------------------------------------------+
\------ authenticated -----/
\------- encrypted --------/
UDP Header: All CAPWAP packets are encapsulated within either UDP, or UDP-Lite when used over IPv6. Section 3 defines the specific UDP or UDP-Lite usage.
UDP标头：在IPv6上使用时，所有CAPWAP数据包都封装在UDP或UDP Lite中。第3节定义了特定的UDP或UDP Lite用法。
CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are prefixed with the CAPWAP DTLS Header (see Section 4.2).
CAPWAP DTLS头：所有DTLS加密的CAPWAP协议数据包都以CAPWAP DTLS头为前缀（见第4.2节）。
DTLS Header: The DTLS Header provides authentication and encryption services to the CAPWAP payload it encapsulates. This protocol is defined in [RFC4347].
DTLS标头：DTLS标头为其封装的CAPWAP有效负载提供身份验证和加密服务。该协议在[RFC4347]中定义。
CAPWAP Header: All CAPWAP protocol packets use a common header that immediately follows the CAPWAP preamble or DTLS Header. The CAPWAP Header is defined in Section 4.3.
CAPWAP头：所有CAPWAP协议数据包都使用紧跟在CAPWAP前导或DTLS头之后的公共头。第4.3节定义了CAPWAP标头。
Wireless Payload: A CAPWAP protocol packet that contains a wireless payload is a CAPWAP Data packet. The CAPWAP protocol does not specify the format of the wireless payload, which is defined by the appropriate wireless standard. Additional information is in Section 4.4.
无线有效载荷：包含无线有效载荷的CAPWAP协议包是CAPWAP数据包。CAPWAP协议未指定无线有效负载的格式，该格式由相应的无线标准定义。更多信息见第4.4节。
Control Header: The CAPWAP protocol includes a signaling component, known as the CAPWAP Control protocol. All CAPWAP Control packets include a Control Header, which is defined in Section 4.5.1. CAPWAP Data packets do not contain a Control Header field.
控制头：CAPWAP协议包括一个信令组件，称为CAPWAP控制协议。所有CAPWAP控制数据包都包含一个控制头，其定义见第4.5.1节。CAPWAP数据包不包含控制头字段。
Message Elements: A CAPWAP Control packet includes one or more message elements, which are found immediately following the Control Header. These message elements are in a Type/Length/Value style header, defined in Section 4.6.
消息元素：CAPWAP控制数据包包含一个或多个消息元素，这些元素紧跟在控制头之后。这些消息元素位于第4.6节中定义的类型/长度/值样式标题中。
A CAPWAP implementation MUST be capable of receiving a reassembled CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY indicate that it supports a higher maximum message length, by
CAPWAP实现必须能够接收长度为4096字节的重组CAPWAP消息。CAPWAP实现可能表明它支持更高的最大消息长度，如下所示：
including the Maximum Message Length message element, see Section 4.6.31, in the Join Request message or the Join Response message.
在加入请求消息或加入响应消息中包括最大消息长度消息元素，见第4.6.31节。
The CAPWAP preamble is common to all CAPWAP transport headers and is used to identify the header type that immediately follows. The reason for this preamble is to avoid needing to perform byte comparisons in order to guess whether or not the frame is DTLS encrypted. It also provides an extensibility framework that can be used to support additional transport types. The format of the preamble is as follows:
CAPWAP前导码对于所有CAPWAP传输头都是通用的，用于标识紧跟其后的头类型。此前导码的原因是为了避免为了猜测帧是否是DTLS加密的而需要执行字节比较。它还提供了一个可扩展性框架，可用于支持其他传输类型。序言的格式如下：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version| Type |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version| Type |
+-+-+-+-+-+-+-+-+
Version: A 4-bit field that contains the version of CAPWAP used in this packet. The value for this specification is zero (0).
版本：一个4位字段，包含此数据包中使用的CAPWAP版本。此规范的值为零（0）。
Type: A 4-bit field that specifies the payload type that follows the UDP header. The following values are supported:
类型：一个4位字段，指定UDP标头后面的有效负载类型。支持以下值：
0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) immediately follows the UDP header. If the packet is received on the CAPWAP Data channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP Data packet. If received on the CAPWAP Control channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP Control packet. If the control packet is not a Discovery Request or Discovery Response packet, the packet MUST be dropped.
0-CAPWAP头。CAPWAP头（见第4.3节）紧跟在UDP头之后。如果通过CAPWAP数据通道接收到数据包，则CAPWAP堆栈必须将数据包视为明文CAPWAP数据包。如果通过CAPWAP控制通道接收，CAPWAP堆栈必须将数据包视为明文CAPWAP控制数据包。如果控制数据包不是发现请求或发现响应数据包，则必须丢弃该数据包。
1 - CAPWAP DTLS Header. The CAPWAP DTLS Header (and DTLS packet) immediately follows the UDP header (see Section 4.2).
1-CAPWAP DTLS标头。CAPWAP DTLS报头（和DTLS数据包）紧跟在UDP报头之后（见第4.2节）。
The CAPWAP DTLS Header is used to identify the packet as a DTLS encrypted packet. The first eight bits include the common CAPWAP Preamble. The remaining 24 bits are padding to ensure 4-byte alignment, and MAY be used in a future version of the protocol. The DTLS packet [RFC4347] always immediately follows this header. The format of the CAPWAP DTLS Header is as follows:
CAPWAP DTLS报头用于将数据包标识为DTLS加密数据包。前八位包括公共CAPWAP前导码。剩余的24位是填充，以确保4字节对齐，并可在未来版本的协议中使用。DTLS数据包[RFC4347]始终紧跟在该报头之后。CAPWAP DTLS标头的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble's Payload Type field MUST be set to one (1).
CAPWAP前导：第4.1节定义了CAPWAP前导。CAPWAP前导码的有效负载类型字段必须设置为一（1）。
Reserved: The 24-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
保留：24位字段保留供将来使用。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
All CAPWAP protocol messages are encapsulated using a common header format, regardless of the CAPWAP Control or CAPWAP Data transport used to carry the messages. However, certain flags are not applicable for a given transport. Refer to the specific transport section in order to determine which flags are valid.
所有CAPWAP协议消息都使用通用的报头格式进行封装，而与用于传输消息的CAPWAP控件或CAPWAP数据传输无关。但是，某些标志不适用于给定的传输。请参阅特定传输部分，以确定哪些标志有效。
Note that the optional fields defined in this section MUST be present in the precise order shown below.
请注意，本节中定义的可选字段必须按如下所示的精确顺序显示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Frag Offset |Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Radio MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Frag Offset |Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Radio MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble's Payload Type field MUST be set to zero (0). If the CAPWAP DTLS Header is present, the version number in both CAPWAP Preambles MUST match. The reason for this duplicate field is to avoid any possible tampering of the version field in the preamble that is not encrypted or authenticated.
CAPWAP前导：第4.1节定义了CAPWAP前导。CAPWAP前导码的有效负载类型字段必须设置为零（0）。如果存在CAPWAP DTLS标头，则两个CAPWAP序言中的版本号必须匹配。此重复字段的原因是避免对前导中未加密或未验证的版本字段进行任何可能的篡改。
HLEN: A 5-bit field containing the length of the CAPWAP transport header in 4-byte words (similar to IP header length). This length includes the optional headers.
HLEN：一个5位字段，包含CAPWAP传输头的长度（4字节字）（类似于IP头长度）。此长度包括可选的标题。
RID: A 5-bit field that contains the Radio ID number for this packet, whose value is between one (1) and 31. Given that MAC Addresses are not necessarily unique across physical radios in a WTP, the Radio Identifier (RID) field is used to indicate with which physical radio the message is associated.
RID：一个5位字段，包含此数据包的无线电ID号，其值介于1和31之间。假设MAC地址在WTP中的物理无线电之间不一定是唯一的，则无线电标识符（RID）字段用于指示消息与哪个物理无线电相关联。
WBID: A 5-bit field that is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The following values are defined:
WBID：一个5位字段，是无线绑定标识符。标识符将指示与无线电相关联的无线分组的类型。定义了以下值：
0 - Reserved
0-保留
1 - IEEE 802.11
1-IEEE 802.11
2 - Reserved
2-保留
3 - EPCGlobal [EPCGlobal]
3-EPCGlobal[EPCGlobal]
T: The Type 'T' bit indicates the format of the frame being transported in the payload. When this bit is set to one (1), the payload has the native frame format indicated by the WBID field. When this bit is zero (0), the payload is an IEEE 802.3 frame.
T：类型“T”位表示在有效负载中传输的帧的格式。当该位设置为一（1）时，有效负载具有由WBID字段指示的本机帧格式。当该位为零（0）时，有效负载为IEEE 802.3帧。
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 combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC.
F：片段“F”位指示此数据包是否为片段。当该位为一（1）时，数据包是一个片段，必须与其他相应片段组合，以重新组装WTP和AC之间交换的完整信息。
L: The Last 'L' bit is valid only if the 'F' bit is set and indicates whether the packet contains the last fragment of a fragmented exchange between WTP and AC. When this bit is one (1), the packet is the last fragment. When this bit is (zero) 0, the packet is not the last fragment.
L：仅当设置了“F”位并指示数据包是否包含WTP和AC之间碎片交换的最后一个片段时，最后一个“L”位才有效。当该位为一（1）时，数据包为最后一个片段。当该位为（零）0时，数据包不是最后一个片段。
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.
W：无线“W”位用于指定报头中是否存在可选的无线特定信息字段。值一（1）用于表示可选标头存在的事实。
M: The Radio MAC 'M' bit is used to indicate that the Radio MAC Address optional header is present. This is used to communicate the MAC address of the receiving radio.
M：无线电MAC“M”位用于指示存在无线电MAC地址可选报头。这用于传送接收无线电的MAC地址。
K: The Keep-Alive 'K' bit indicates the packet is a Data Channel Keep-Alive packet. This packet is used to map the data channel to the control channel for the specified Session ID and to maintain freshness of the data channel. The 'K' bit MUST NOT be set for data packets containing user data.
K：保持活动的“K”位表示该数据包是数据通道保持活动的数据包。此数据包用于将数据通道映射到指定会话ID的控制通道，并保持数据通道的新鲜度。不能为包含用户数据的数据包设置“K”位。
Flags: A set of reserved bits for future flags in the CAPWAP Header. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
标志：CAPWAP头中未来标志的一组保留位。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
Fragment ID: A 16-bit field whose value is assigned to each group of fragments making up a complete set. The Fragment ID space is managed individually for each direction for every WTP/AC pair. The value of Fragment ID is incremented with each new set of fragments. The Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments.
片段ID：一个16位字段，其值分配给构成完整集合的每组片段。针对每个WTP/AC对的每个方向分别管理片段ID空间。片段ID的值随着每个新片段集的增加而增加。使用最大值标识一组片段后，片段ID将换行为零。
Fragment Offset: A 13-bit field that indicates where in the payload this fragment belongs 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. Note that the CAPWAP protocol does not allow for overlapping fragments.
片段偏移量：一个13位字段，指示在重新组装期间该片段在有效负载中所属的位置。当“F”位设置为1时，此字段有效。片段偏移量以8个八位字节（64位）为单位测量。第一个片段的偏移量为零。请注意，CAPWAP协议不允许重叠片段。
Reserved: The 3-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
保留：3位字段保留供将来使用。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
Radio MAC Address: This optional field contains the MAC address of the radio receiving the packet. Because the native wireless frame format to IEEE 802.3 format causes the MAC address of the WTP's radio to be lost, this field allows the address to be communicated to the AC. This field is only present if the 'M' bit is set. The HLEN field assumes 4-byte alignment, and this field MUST be padded with zeroes (0x00) if it is not 4-byte aligned.
无线电MAC地址：此可选字段包含接收数据包的无线电的MAC地址。由于IEEE 802.3格式的本机无线帧格式会导致WTP无线电的MAC地址丢失，因此此字段允许将地址传送到AC。仅当设置了“M”位时，此字段才存在。HLEN字段采用4字节对齐方式，如果该字段没有4字节对齐，则必须用零（0x00）填充。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 length of the MAC address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: The MAC address of the receiving radio.
MAC地址：接收无线电的MAC地址。
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 WBID field in the CAPWAP Header is used to identify the format of the Wireless-Specific Information optional field. The HLEN field assumes 4-byte alignment, and this field MUST be padded with zeroes (0x00) if it is not 4-byte aligned.
无线特定信息：此可选字段包含特定于技术的信息，可用于携带每个数据包的无线信息。仅当设置了“W”位时，此字段才存在。CAPWAP标头中的WBID字段用于标识无线特定信息可选字段的格式。HLEN字段采用4字节对齐方式，如果该字段没有4字节对齐，则必须用零（0x00）填充。
The Wireless-Specific Information field uses the following format:
无线特定信息字段使用以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The 8-bit field contains the length of the data field, with a maximum size of 255.
长度：8位字段包含数据字段的长度，最大大小为255。
Data: Wireless-specific information, defined by the wireless-specific binding specified in the CAPWAP Header's WBID field.
数据：无线特定信息，由CAPWAP头的WBID字段中指定的无线特定绑定定义。
Payload: This field contains the header for a CAPWAP Data Message or CAPWAP Control Message, followed by the data contained in the message.
有效负载：此字段包含CAPWAP数据消息或CAPWAP控制消息的标题，后跟消息中包含的数据。
There are two different types of CAPWAP Data packets: CAPWAP Data Channel Keep-Alive packets and Data Payload packets. The first is used by the WTP to synchronize the control and data channels and to maintain freshness of the data channel. The second is used to transmit user payloads between the AC and WTP. This section describes both types of CAPWAP Data packet formats.
有两种不同类型的CAPWAP数据包：CAPWAP数据通道保持活动数据包和数据有效负载数据包。第一个用于WTP同步控制通道和数据通道，并保持数据通道的新鲜度。第二个用于在AC和WTP之间传输用户有效负载。本节介绍两种类型的CAPWAP数据包格式。
Both CAPWAP Data messages are transmitted on the CAPWAP Data channel.
两条CAPWAP数据消息均通过CAPWAP数据信道传输。
The CAPWAP Data Channel Keep-Alive packet is used to bind the CAPWAP control channel with the data channel, and to maintain freshness of the data channel, ensuring that the channel is still functioning. The CAPWAP Data Channel Keep-Alive packet is transmitted by the WTP when the DataChannelKeepAlive timer expires (see Section 4.7.2). When the CAPWAP Data Channel Keep-Alive packet is transmitted, the WTP sets the DataChannelDeadInterval timer.
CAPWAP数据通道保持活动数据包用于将CAPWAP控制通道与数据通道绑定，并保持数据通道的新鲜度，确保通道仍在运行。当DataChannelKeepAlive定时器到期时，WTP将发送CAPWAP数据信道保持活动数据包（见第4.7.2节）。当传输CAPWAP数据通道保持活动数据包时，WTP设置DataChannelDeadInterval定时器。
In the CAPWAP Data Channel Keep-Alive packet, all of the fields in the CAPWAP Header, except the HLEN field and the 'K' bit, are set to zero upon transmission. Upon receiving a CAPWAP Data Channel Keep-Alive packet, the AC transmits a CAPWAP Data Channel Keep-Alive packet back to the WTP. The contents of the transmitted packet are identical to the contents of the received packet.
在CAPWAP数据通道保持活动数据包中，CAPWAP报头中的所有字段（除HLEN字段和“K”位外）在传输时都设置为零。在接收到CAPWAP数据信道保持活动数据包后，AC将CAPWAP数据信道保持活动数据包发送回WTP。发送分组的内容与接收分组的内容相同。
Upon receiving a CAPWAP Data Channel Keep-Alive packet, the WTP cancels the DataChannelDeadInterval timer and resets the DataChannelKeepAlive timer. The CAPWAP Data Channel Keep-Alive packet is retransmitted by the WTP in the same manner as the CAPWAP Control messages. If the DataChannelDeadInterval timer expires, the WTP tears down the control DTLS session, and the data DTLS session if one existed.
收到CAPWAP数据通道保持活动数据包后，WTP取消DataChannelDeadInterval计时器并重置DataChannelKeepAlive计时器。WTP以与CAPWAP控制消息相同的方式重新传输CAPWAP数据通道保持活动数据包。如果DataChannelDeadInterval计时器过期，WTP将断开控制DTLS会话，如果存在数据DTLS会话，则断开数据DTLS会话。
The CAPWAP Data Channel Keep-Alive packet contains the following payload immediately following the CAPWAP Header (see Section 4.3).
CAPWAP数据通道保持活动数据包在CAPWAP头之后包含以下有效载荷（见第4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Element Length | Message Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Element Length | Message Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Element Length: The 16-bit Length field indicates the number of bytes following the CAPWAP Header, with a maximum size of 65535.
Message Element Length（消息元素长度）：16位长度字段表示CAPWAP标头后面的字节数，最大大小为65535。
Message Element[0..N]: The message element(s) carry the information pertinent to each of the CAPWAP Data Channel Keep-Alive message. The following message elements MUST be present in this CAPWAP message:
消息元素[0..N]：消息元素包含与每个CAPWAP数据通道保持活动消息相关的信息。此CAPWAP消息中必须包含以下消息元素：
Session ID, see Section 4.6.37.
会话ID，见第4.6.37节。
A CAPWAP protocol Data Payload packet encapsulates a forwarded wireless frame. The CAPWAP protocol defines two different modes of encapsulation: IEEE 802.3 and native wireless. IEEE 802.3 encapsulation requires that for 802.11 frames, the 802.11 *Integration* function be performed in the WTP. An IEEE 802.3- encapsulated user payload frame has the following format:
CAPWAP协议数据有效载荷包封装转发的无线帧。CAPWAP协议定义了两种不同的封装模式：IEEE 802.3和本机无线。IEEE 802.3封装要求对于802.11帧，在WTP中执行802.11*集成*功能。IEEE 802.3封装的用户有效负载帧具有以下格式：
+------------------------------------------------------+
| IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
+------------------------------------------------------+
+------------------------------------------------------+
| IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
+------------------------------------------------------+
The CAPWAP protocol also defines the native wireless encapsulation mode. The format of the encapsulated CAPWAP Data frame is subject to the rules defined by the specific wireless technology binding. Each wireless technology binding MUST contain a section entitled "Payload Encapsulation", which defines the format of the wireless payload that is encapsulated within CAPWAP Data packets.
CAPWAP协议还定义了本机无线封装模式。封装的CAPWAP数据帧的格式受特定无线技术绑定定义的规则约束。每个无线技术绑定必须包含一个标题为“有效负载封装”的部分，该部分定义了封装在CAPWAP数据包中的无线有效负载的格式。
For 802.3 payload frames, the 802.3 frame is encapsulated (excluding the IEEE 802.3 Preamble, Start Frame Delimiter (SFD), and Frame Check Sequence (FCS) fields). If the encapsulated frame would exceed the transport layer's MTU, the sender is responsible for the fragmentation of the frame, as specified in Section 3.4. The CAPWAP protocol can support IEEE 802.3 frames whose length is defined in the IEEE 802.3as specification [FRAME-EXT].
对于802.3有效负载帧，802.3帧被封装（不包括IEEE 802.3前导、开始帧定界符（SFD）和帧检查序列（FCS）字段）。如果封装的帧将超过传输层的MTU，则发送方应负责帧的碎片，如第3.4节所述。CAPWAP协议可支持长度在IEEE 802.3as规范[FRAME-EXT]中定义的IEEE 802.3帧。
If the AC and WTP are configured to tunnel the data channel over DTLS, the proper DTLS session must be initiated. To avoid having to reauthenticate and reauthorize an AC and WTP, the DTLS data channel SHOULD be initiated using the TLS session resumption feature [RFC5246].
如果AC和WTP配置为通过DTLS对数据通道进行隧道传输，则必须启动正确的DTLS会话。为避免必须对AC和WTP进行重新身份验证和重新身份验证，应使用TLS会话恢复功能[RFC5246]启动DTLS数据通道。
The AC DTLS implementation MUST NOT initiate a data channel session for a DTLS session for which there is no active control channel session.
AC DTLS实施不得为没有活动控制通道会话的DTLS会话启动数据通道会话。
The CAPWAP Control protocol provides a control channel between the WTP and the AC. Control messages are divided into the following message types:
CAPWAP控制协议在WTP和AC之间提供控制通道。控制消息分为以下消息类型：
Discovery: CAPWAP Discovery messages are used to identify potential ACs, their load and capabilities.
发现：CAPWAP发现消息用于识别潜在的ACs、其负载和功能。
Join: CAPWAP Join messages are used by a WTP to request service from an AC, and for the AC to respond to the WTP.
加入：WTP使用CAPWAP加入消息从AC请求服务，AC响应WTP。
Control Channel Management: CAPWAP Control channel management messages are used to maintain the control channel.
控制通道管理：CAPWAP控制通道管理消息用于维护控制通道。
WTP Configuration Management: The WTP Configuration messages are used by the AC to deliver a specific configuration to the WTP. Messages that retrieve statistics from a WTP are also included in WTP Configuration Management.
WTP配置管理：AC使用WTP配置消息向WTP交付特定配置。从WTP检索统计信息的消息也包含在WTP配置管理中。
Station Session Management: Station Session Management messages are used by the AC to deliver specific station policies to the WTP.
站点会话管理：AC使用站点会话管理消息向WTP传递特定的站点策略。
Device Management Operations: Device management operations are used to request and deliver a firmware image to the WTP.
设备管理操作：设备管理操作用于请求固件映像并将其传送到WTP。
Binding-Specific CAPWAP Management Messages: Messages in this category are used by the AC and the WTP to exchange protocol-specific CAPWAP management messages. These messages may or may not be used to change the link state of a station.
绑定特定CAPWAP管理消息：AC和WTP使用此类消息交换特定于协议的CAPWAP管理消息。这些消息可用于或不用于更改站点的链路状态。
Discovery, Join, Control Channel Management, WTP Configuration Management, and Station Session Management CAPWAP Control messages MUST be implemented. Device Management Operations messages MAY be implemented.
必须实施发现、加入、控制通道管理、WTP配置管理和站点会话管理CAPWAP控制消息。可以实现设备管理操作消息。
CAPWAP Control messages sent from the WTP to the AC indicate that the WTP is operational, providing an implicit keep-alive mechanism for the WTP. The Control Channel Management Echo Request and Echo Response messages provide an explicit keep-alive mechanism when other CAPWAP Control messages are not exchanged.
从WTP发送到AC的CAPWAP控制消息表明WTP可运行，为WTP提供隐式保持活动机制。当其他CAPWAP控制消息未交换时，控制信道管理回显请求和回显响应消息提供了一种明确的保持活动机制。
All CAPWAP Control messages are sent encapsulated within the CAPWAP Header (see Section 4.3). Immediately following the CAPWAP Header is the control header, which has the following format:
所有CAPWAP控制信息均封装在CAPWAP报头内发送（见第4.3节）。紧接着CAPWAP标头的是控制标头，其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq Num | Msg Element Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq Num | Msg Element Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type field identifies the function of the CAPWAP Control message. To provide extensibility, the Message Type field is comprised of an IANA Enterprise Number [RFC3232] and an enterprise-specific message type number. The first three octets contain the IANA Enterprise Number in network byte order, with zero used for CAPWAP base protocol (this specification) defined message types. The last octet is the enterprise-specific message type number, which has a range from 0 to 255.
消息类型字段标识CAPWAP控制消息的功能。为了提供可扩展性，消息类型字段由IANA企业编号[RFC3232]和特定于企业的消息类型编号组成。前三个八位字节包含网络字节顺序的IANA企业号，零用于CAPWAP基本协议（本规范）定义的消息类型。最后一个八位字节是特定于企业的消息类型编号，其范围为0到255。
The Message Type field is defined as:
消息类型字段定义为：
Message Type = IANA Enterprise Number * 256 + Enterprise Specific Message Type Number
消息类型=IANA企业编号*256+特定于企业的消息类型编号
The CAPWAP protocol reliability mechanism requires that messages be defined in pairs, consisting of both a Request and a Response message. The Response message MUST acknowledge the Request message. The assignment of CAPWAP Control Message Type Values always occurs in pairs. All Request messages have odd numbered Message Type Values, and all Response messages have even numbered Message Type Values. The Request value MUST be assigned first. As an example, assigning a Message Type Value of 3 for a Request message and 4 for a Response message is valid, while assigning a Message Type Value of 4 for a Response message and 5 for the corresponding Request message is invalid.
CAPWAP协议可靠性机制要求消息成对定义，由请求和响应消息组成。响应消息必须确认请求消息。CAPWAP控制消息类型值的分配始终成对进行。所有请求消息具有奇数编号的消息类型值，所有响应消息具有偶数编号的消息类型值。必须首先分配请求值。例如，为请求消息分配消息类型值3，为响应消息分配消息类型值4是有效的，而为响应消息分配消息类型值4，为相应的请求消息分配消息类型值5是无效的。
When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored.
当WTP或AC接收到带有无法识别的消息类型值字段且为奇数的消息时，消息类型值字段中的数字将递增1，并且带有包含递增值的消息类型值字段并包含具有该值的结果代码消息元素的响应消息（无法识别的请求）返回给所接收邮件的发件人。如果未知邮件类型为偶数，则忽略该邮件。
The valid values for CAPWAP Control Message Types are specified in the table below:
下表中指定了CAPWAP控制消息类型的有效值：
CAPWAP Control Message Message Type Value Discovery Request 1 Discovery Response 2 Join Request 3 Join Response 4 Configuration Status Request 5 Configuration Status Response 6 Configuration Update Request 7 Configuration Update Response 8 WTP Event Request 9 WTP Event Response 10 Change State Event Request 11 Change State Event Response 12 Echo Request 13 Echo Response 14 Image Data Request 15 Image Data Response 16 Reset Request 17 Reset Response 18 Primary Discovery Request 19 Primary Discovery Response 20 Data Transfer Request 21 Data Transfer Response 22 Clear Configuration Request 23 Clear Configuration Response 24 Station Configuration Request 25 Station Configuration Response 26
CAPWAP控制消息消息类型值发现请求1发现响应2加入请求3加入响应4配置状态请求5配置状态响应6配置更新请求7配置更新响应8 WTP事件请求9 WTP事件响应10更改状态事件请求11更改状态事件响应12回声请求13回波响应14图像数据请求15图像数据响应16复位请求17复位响应18主发现请求19主发现响应20数据传输请求21数据传输响应22清除配置请求23清除配置响应24站点配置请求25站点配置响应26
The Sequence Number field is an identifier value used to match Request and Response packets. When a CAPWAP packet with a Request Message Type Value is received, the value of the Sequence Number field is copied into the corresponding Response message.
序列号字段是用于匹配请求和响应数据包的标识符值。当接收到具有请求消息类型值的CAPWAP数据包时，序列号字段的值将复制到相应的响应消息中。
When a CAPWAP Control message is sent, the sender's internal sequence number counter is monotonically incremented, ensuring that no two pending Request messages have the same sequence number. The Sequence Number field wraps back to zero.
发送CAPWAP控制消息时，发送方的内部序列号计数器将单调递增，以确保没有两个挂起的请求消息具有相同的序列号。序列号字段返回到零。
The Length field indicates the number of bytes following the Sequence Number field.
长度字段表示序列号字段后面的字节数。
The Flags field MUST be set to zero.
“标志”字段必须设置为零。
The message element(s) carry the information pertinent to each of the control message types. Every control message in this specification specifies which message elements are permitted.
消息元素携带与每种控制消息类型相关的信息。本规范中的每个控制消息都指定允许哪些消息元素。
When a WTP or AC receives a CAPWAP message without a message element that is specified as mandatory for the CAPWAP message, then the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Missing Mandatory Message Element" is returned to the sender.
当WTP或AC接收到CAPWAP消息时，如果没有指定为CAPWAP消息必需的消息元素，则CAPWAP消息将被丢弃。如果收到的消息是请求消息，对应的响应消息包含消息元素，则向发送方返回相应的响应消息，其结果代码消息元素指示“失败-缺少强制消息元素”。
When a WTP or AC receives a CAPWAP message with a message element that the WTP or AC does not recognize, the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Unrecognized Message Element" and one or more Returned Message Element message elements is included, containing the unrecognized message element(s).
当WTP或AC接收到带有WTP或AC无法识别的消息元素的CAPWAP消息时，CAPWAP消息将被丢弃。如果接收到的消息是一条请求消息，对应的响应消息中包含消息元素，则包括一条相应的响应消息，其结果代码消息元素指示“故障-无法识别的消息元素”，以及一个或多个返回的消息元素，包含无法识别的消息元素。
The CAPWAP base protocol does not provide any Quality of Service (QoS) recommendations for use with the CAPWAP Data messages. Any wireless-specific CAPWAP binding specification that has QoS requirements MUST define the application of QoS to the CAPWAP Data messages.
CAPWAP基本协议不提供任何与CAPWAP数据消息一起使用的服务质量（QoS）建议。任何具有QoS要求的无线特定CAPWAP绑定规范都必须定义QoS对CAPWAP数据消息的应用。
The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two levels of ECN functionality: full functionality and limited functionality. CAPWAP ACs and WTPs SHALL implement the limited functionality and are RECOMMENDED to implement the full functionality described in [RFC3168].
IP报头还包括显式拥塞通知（ECN）位[RFC3168]。[RFC3168]第9.1.1节描述了ECN功能的两个级别：完整功能和有限功能。CAPWAP ACs和WTP应实现有限的功能，建议实现[RFC3168]中所述的全部功能。
It is recommended that CAPWAP Control messages be sent by both the AC and the WTP with an appropriate Quality-of-Service precedence value, ensuring that congestion in the network minimizes occurrences of CAPWAP Control channel disconnects. Therefore, a QoS-enabled CAPWAP device SHOULD use the following values:
建议AC和WTP以适当的服务质量优先值发送CAPWAP控制消息，以确保网络拥塞将CAPWAP控制通道断开的发生降至最低。因此，支持QoS的CAPWAP设备应使用以下值：
802.1Q: The priority tag of 7 SHOULD be used.
802.1Q：应使用优先级标签7。
DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which is described in [RFC2474]).
DSCP：应使用CS6每跳行为服务类，如[RFC2474]中所述。
The CAPWAP Control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1).
CAPWAP控制协议作为可靠的传输协议运行。对于每个请求消息，都定义了一条响应消息，用于确认收到请求消息。此外，控制头序列号字段用于将请求和响应消息配对（见第4.5.1节）。
Response messages are not explicitly acknowledged; therefore, if a Response message is not received, the original Request message is retransmitted.
未明确确认响应消息；因此，如果未接收到响应消息，则重新传输原始请求消息。
Implementations MUST keep track of the sequence number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same sequence number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message is received, meaning one where the sequence number is smaller, it MUST be ignored. A newer Request message, meaning one whose sequence number is larger, is processed as usual.
实现必须跟踪最后接收到的请求消息的序列号，并且必须缓存相应的响应消息。如果接收到具有相同序列号的重传，则必须在不重新处理请求的情况下重传缓存的响应消息。如果接收到较旧的请求消息，即序列号较小的消息，则必须忽略该消息。较新的请求消息（即序列号较大的消息）将照常处理。
Note: A sequence number is considered "smaller" when s1 is smaller than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2 and (s1-s2)>128).
注：当s1小于s2模256时，当且仅当（s1<s2和（s2-s1）<128）或（s1>s2和（s1-s2）>128）时，序列号被视为“更小”。
Both the WTP and the AC can only have a single request outstanding at any given time. Retransmitted Request messages MUST NOT be altered by the sender.
WTP和AC在任何给定时间都只能有一个未完成的请求。发送方不得更改重新传输的请求消息。
After transmitting a Request message, the RetransmitInterval (see Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are used to determine if the original Request message needs to be retransmitted. The RetransmitInterval timer is used the first time the Request is retransmitted. The timer is then doubled every
传输请求消息后，使用RetransmitInterval（参见第4.7节）计时器和MaxRetransmit（参见第4.8节）变量确定是否需要重新传输原始请求消息。重新传输间隔计时器在第一次重新传输请求时使用。然后，计时器每小时加倍一次
subsequent time the same Request message is retransmitted, up to MaxRetransmit but no more than half the EchoInterval timer (see Section 4.7.7). Response messages are not subject to these timers.
重新传输同一请求消息的后续时间，最长为MaxRetransmit，但不超过EchoInterval计时器的一半（见第4.7.7节）。响应消息不受这些计时器的限制。
If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new sequence number, and be treated as a new Request message by the receiver. Note that there is a high chance that both the WTP and the AC's sequence numbers will become out of sync.
如果发送方在到达MaxRetransmit-retransmissions之前停止重新传输请求消息（如第2.3.1节所述，这导致转换为DTLS-Teardown），则无法知道接收方是否接收并处理了请求。在大多数情况下，发送方不应该这样做，而是继续重新传输，直到收到响应消息，或者发生到DTLS分解的转换。但是，如果发送方确实决定使用新的或修改过的请求消息继续连接，则新消息必须具有新的序列号，并且接收方必须将其视为新的请求消息。请注意，WTP和AC的序列号很有可能不同步。
When a Request message is retransmitted, it MUST be re-encrypted via the DTLS stack. If the peer had received the Request message, and the corresponding Response message was lost, it is necessary to ensure that retransmitted Request messages are not identified as replays by the DTLS stack. Similarly, any cached Response messages that are retransmitted as a result of receiving a retransmitted Request message MUST be re-encrypted via DTLS.
重新传输请求消息时，必须通过DTLS堆栈对其重新加密。如果对等方已收到请求消息，且相应的响应消息丢失，则有必要确保DTLS堆栈不会将重新传输的请求消息标识为重播。类似地，由于接收到重新传输的请求消息而重新传输的任何缓存响应消息必须通过DTL重新加密。
Duplicate Response messages, identified by the Sequence Number field in the CAPWAP Control message header, SHOULD be discarded upon receipt.
重复的响应消息（由CAPWAP控制消息标题中的序列号字段标识）应在收到后丢弃。
This section defines the CAPWAP Protocol message elements that are included in CAPWAP protocol control messages.
本节定义CAPWAP协议控制消息中包含的CAPWAP协议消息元素。
Message elements are used to carry information needed in control messages. Every message element is identified by the Type Value field, defined below. The total length of the message elements is indicated in the message element's length field.
消息元素用于承载控制消息中所需的信息。每个消息元素都由下面定义的类型值字段标识。消息元素的总长度在消息元素的长度字段中指示。
All of the message element definitions in this document use a diagram similar to the one below in order to depict its format. Note that to simplify this specification, these diagrams do not include the header fields (Type and Length). The header field values are defined in the message element descriptions.
本文档中的所有消息元素定义都使用类似于下图的图表来描述其格式。请注意，为了简化此规范，这些图表不包括标题字段（类型和长度）。标题字段值在消息元素描述中定义。
Unless otherwise specified, a control message that lists a set of supported (or expected) message elements MUST NOT expect the message elements to be in any specific order. The sender MAY include the message elements in any order. Unless otherwise noted, one message element of each type is present in a given control message.
除非另有规定，否则列出一组受支持（或预期）消息元素的控制消息不得期望消息元素按任何特定顺序排列。发送方可以按任何顺序包括消息元素。除非另有说明，否则每种类型的消息元素都存在于给定的控制消息中。
Unless otherwise specified, any configuration information sent by the AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) for more information).
除非另有规定，否则AC发送到WTP的任何配置信息都可以保存到非易失性存储器（更多信息请参见第8.1节）。
Additional message elements may be defined in separate IETF documents.
其他消息元素可在单独的IETF文件中定义。
The format of a message element uses the TLV format shown here:
消息元素的格式使用如下所示的TLV格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... |
+-+-+-+-+-+-+-+-+
The 16-bit Type field identifies the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. The value of zero (0) is reserved and MUST NOT be used. The rest of the Type field values are allocated as follows:
16位类型字段标识值字段中携带的信息，长度（16位）表示值字段中的字节数。零（0）的值为保留值，不得使用。其余的类型字段值分配如下：
Usage Type Values
使用类型值
CAPWAP Protocol Message Elements 1 - 1023 IEEE 802.11 Message Elements 1024 - 2047 Reserved for Future Use 2048 - 3071 EPCGlobal Message Elements 3072 - 4095 Reserved for Future Use 4096 - 65535
CAPWAP协议消息元素1-1023 IEEE 802.11消息元素1024-2047保留供将来使用2048-3071 EPCGlobal消息元素3072-4095保留供将来使用4096-65535
The table below lists the CAPWAP protocol Message Elements and their Type values.
下表列出了CAPWAP协议消息元素及其类型值。
CAPWAP Message Element Type Value
CAPWAP消息元素类型值
AC Descriptor 1 AC IPv4 List 2 AC IPv6 List 3 AC Name 4 AC Name with Priority 5 AC Timestamp 6 Add MAC ACL Entry 7 Add Station 8 Reserved 9 CAPWAP Control IPV4 Address 10 CAPWAP Control IPV6 Address 11 CAPWAP Local IPV4 Address 30 CAPWAP Local IPV6 Address 50 CAPWAP Timers 12 CAPWAP Transport Protocol 51 Data Transfer Data 13 Data Transfer Mode 14 Decryption Error Report 15 Decryption Error Report Period 16 Delete MAC ACL Entry 17 Delete Station 18 Reserved 19 Discovery Type 20 Duplicate IPv4 Address 21 Duplicate IPv6 Address 22 ECN Support 53 Idle Timeout 23 Image Data 24 Image Identifier 25 Image Information 26 Initiate Download 27 Location Data 28 Maximum Message Length 29 MTU Discovery Padding 52 Radio Administrative State 31 Radio Operational State 32 Result Code 33 Returned Message Element 34 Session ID 35 Statistics Timer 36 Vendor Specific Payload 37 WTP Board Data 38 WTP Descriptor 39 WTP Fallback 40 WTP Frame Tunnel Mode 41 Reserved 42
AC描述符1 AC IPv4列表2 AC IPv6列表3 AC名称4具有优先级的AC名称5 AC时间戳6添加MAC ACL条目7添加站点8保留9 CAPWAP控制IPv4地址10 CAPWAP控制IPv6地址11 CAPWAP本地IPv4地址30 CAPWAP本地IPv6地址50 CAPWAP定时器12 CAPWAP传输协议51数据传输数据13数据传输模式14解密错误报告15解密错误报告周期16删除MAC ACL条目17删除站18保留19发现类型20重复IPv4地址21重复IPv6地址22 ECN支持53空闲超时23映像数据24映像标识符25映像信息26启动下载27位置数据28最大消息长度29 MTU发现填充52无线电管理状态31无线电操作状态32结果代码33返回消息元素34会话ID 35统计计时器36供应商特定有效负载37 WTP板数据38 WTP描述符39 WTP回退40 WTP帧隧道模式41保留42
Reserved 43 WTP MAC Type 44 WTP Name 45 Unused/Reserved 46 WTP Radio Statistics 47 WTP Reboot Statistics 48 WTP Static IP Address Information 49
保留43 WTP MAC类型44 WTP名称45未使用/保留46 WTP无线电统计47 WTP重新启动统计48 WTP静态IP地址信息49
The AC Descriptor message element is used by the AC to communicate its current state. The value contains the following fields.
AC描述符消息元素由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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Active WTPs | Max WTPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | R-MAC Field | Reserved1 | DTLS Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Active WTPs | Max WTPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | R-MAC Field | Reserved1 | DTLS Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1 for AC Descriptor
类型：1表示交流描述符
Length: >= 12
Length: >= 12
Stations: The number of stations currently served by the AC
站点：AC当前服务的站点数
Limit: The maximum number of stations supported by the AC
限制：AC支持的最大站点数
Active WTPs: The number of WTPs currently attached to the AC
活动WTP：当前连接到AC的WTP数
Max WTPs: The maximum number of WTPs supported by the AC
Max WTPs：AC支持的最大WTP数
Security: An 8-bit mask specifying the authentication credential type supported by the AC (see Section 2.4.4). The field has the following format:
安全性：一个8位掩码，指定AC支持的身份验证凭据类型（参见第2.4.4节）。该字段具有以下格式：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |S|X|R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |S|X|R|
+-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
保留：一组保留位，供将来使用。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
S: The AC supports the pre-shared secret authentication, as described in Section 12.6.
S:AC支持预共享秘密认证，如第12.6节所述。
X: The AC supports X.509 Certificate authentication, as described in Section 12.7.
X:AC支持X.509证书认证，如第12.7节所述。
R: A reserved bit for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
R：为将来使用而保留的位。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
R-MAC Field: The AC supports the optional Radio MAC Address field in the CAPWAP transport header (see Section 4.3). The following enumerated values are supported:
R-MAC字段：AC支持CAPWAP传输头中的可选无线电MAC地址字段（参见第4.3节）。支持以下枚举值：
0 - Reserved
0-保留
1 - Supported
1-支持
2 - Not Supported
2-不支持
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
保留：一组保留位，供将来使用。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
DTLS Policy: The AC communicates its policy on the use of DTLS for the CAPWAP data channel. The AC MAY communicate more than one supported option, represented by the bit field below. The WTP MUST abide by one of the options communicated by AC. The field has the following format:
DTLS策略：AC就CAPWAP数据通道使用DTLS的策略进行沟通。AC可以传送多个受支持的选项，由下面的位字段表示。WTP必须遵守AC传达的选项之一。该字段具有以下格式：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |D|C|R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |D|C|R|
+-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.translate error, please retry
D: DTLS-Enabled Data Channel Supported
D:支持DTLS启用的数据通道
C: Clear Text Data Channel Supported
C：支持明文数据通道
R: A reserved bit for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
R：为将来使用而保留的位。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
AC Information Sub-Element: The AC Descriptor message element contains multiple AC Information sub-elements, and defines two sub-types, each of which MUST be present. The AC Information sub-element has the following format:
AC信息子元素：AC描述符消息元素包含多个AC信息子元素，并定义两个子类型，每个子类型都必须存在。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Type | AC Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Type | AC Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AC Information Vendor Identifier: A 32-bit value containing the IANA-assigned "Structure of Management Information (SMI) Network Management Private Enterprise Codes".
AC信息供应商标识符：32位值，包含IANA分配的“管理信息结构（SMI）网络管理私有企业代码”。
AC Information Type: Vendor-specific encoding of AC information in the UTF-8 format [RFC3629]. The following enumerated values are supported. Both the Hardware and Software Version sub-elements MUST be included in the AC Descriptor message element. The values listed below are used in conjunction with the AC Information Vendor Identifier field, whose value MUST be set to zero (0). This field, combined with the AC Information Vendor Identifier set to a non-zero (0) value, allows vendors to use a private namespace.
AC信息类型：供应商特定的UTF-8格式AC信息编码[RFC3629]。支持以下枚举值。AC描述符消息元素中必须包含硬件和软件版本子元素。下面列出的值与AC信息供应商标识符字段一起使用，其值必须设置为零（0）。此字段与设置为非零（0）值的AC信息供应商标识符相结合，允许供应商使用专用命名空间。
4 - Hardware Version: The AC's hardware version number.
4-硬件版本：AC的硬件版本号。
5 - Software Version: The AC's Software (firmware) version number.
5-软件版本：AC的软件（固件）版本号。
AC Information Length: Length of vendor-specific encoding of AC information, with a maximum size of 1024.
AC信息长度：供应商特定的AC信息编码长度，最大大小为1024。
AC Information Data: Vendor-specific encoding of AC information.
AC信息数据：供应商特定的AC信息编码。
The AC IPv4 List message element is used to configure a WTP with the latest list of ACs available for the WTP to join.
AC IPv4列表消息元素用于使用WTP可加入的最新ACs列表配置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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for AC IPv4 List
类型：2用于AC IPv4列表
Length: >= 4
Length: >= 4
AC IP Address: An array of 32-bit integers containing AC IPv4 Addresses, containing no more than 1024 addresses.
AC IP地址：包含AC IPv4地址的32位整数数组，包含的地址不超过1024个。
The AC IPv6 List message element is used to configure a WTP with the latest list of ACs available for the WTP to join.
AC IPv6列表消息元素用于使用WTP可加入的最新AC列表配置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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 for AC IPV6 List
类型：3用于AC IPV6列表
Length: >= 16
Length: >= 16
AC IP Address: An array of 128-bit integers containing AC IPv6 Addresses, containing no more than 1024 addresses.
AC IP地址：包含AC IPv6地址的128位整数数组，包含的地址不超过1024个。
The AC Name message element contains an UTF-8 [RFC3629] representation of the AC identity. The value is a variable-length byte string. The string is NOT zero terminated.
AC名称消息元素包含AC标识的UTF-8[RFC3629]表示。该值是长度可变的字节字符串。字符串不是以零结尾的。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Type: 4 for AC Name
类型：4表示AC名称
Length: >= 1
Length: >= 1
Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC's name, whose maximum size MUST NOT exceed 512 bytes.
名称：包含AC名称的可变长度UTF-8编码字符串[RFC3629]，其最大大小不得超过512字节。
The AC Name with Priority message element is sent by the AC to the WTP to configure preferred ACs. The number of instances of this message element is equal to the number of ACs configured on the WTP. The WTP also uses this message element to send its configuration to the AC.
AC向WTP发送带有优先级消息元素的AC名称，以配置首选AC。此消息元素的实例数等于WTP上配置的ACs数。WTP还使用此消息元素将其配置发送给AC。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 for AC Name with Priority
类型：5表示具有优先级的AC名称
Length: >= 2
Length: >= 2
Priority: A value between 1 and 255 specifying the priority order of the preferred AC. For instance, the value of one (1) is used to set the primary AC, the value of two (2) is used to set the secondary, etc.
优先级：介于1和255之间的值，指定首选空调的优先级顺序。例如，一（1）的值用于设置主空调，二（2）的值用于设置辅助空调，等等。
AC Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC name, whose maximum size MUST NOT exceed 512 bytes.
AC名称：包含AC名称的可变长度UTF-8编码字符串[RFC3629]，其最大大小不得超过512字节。
The AC Timestamp message element is sent by the AC to synchronize the WTP clock.
AC时间戳消息元素由AC发送以同步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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Timestamp
类型：6表示AC时间戳
Length: 4
长度：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 [RFC1305]. Only the most significant 32 bits of the NTP time are included in this field.
时间戳：AC的当前时间，允许所有WTP按照RFC 1305[RFC1305]中网络时间协议（NTP）定义的格式进行时间同步。此字段中仅包括NTP时间的最高有效32位。
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 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. The MAC ACL table on the WTP is cleared every time the WTP establishes a new session with an AC.
AC使用添加MAC访问控制列表（ACL）条目消息元素在WTP上添加MAC ACL列表条目，以确保WTP不再向消息中提供的MAC地址提供服务。此消息元素中提供的MAC地址预计不会保存在WTP上的非易失性内存中。每次WTP与AC建立新会话时，都会清除WTP上的MAC ACL表。
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| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 7 for Add MAC ACL Entry
类型：7用于添加MAC ACL条目
Length: >= 8
Length: >= 8
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This value MUST NOT exceed 255.
条目数：数组中长度/MAC地址字段的实例数。此值不得超过255。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: MAC addresses to add to the ACL.
MAC地址：要添加到ACL的MAC地址。
The Add Station message element is used by the AC to inform a WTP that it should forward traffic for a station. The Add Station message element is accompanied by technology-specific binding information element(s), which may include security parameters. Consequently, the security parameters MUST be applied by the WTP for the station.
AC使用添加站点消息元素通知WTP它应该转发站点的通信量。添加站点消息元素伴随着特定于技术的绑定信息元素，这些绑定信息元素可能包括安全参数。因此，WTP必须为电站应用安全参数。
After station policy has been delivered to the WTP through the Add Station message element, an AC MAY change any policies by sending a modified Add Station message element. When a WTP receives an Add Station message element for an existing station, it MUST override any existing state for the station.
在通过添加站点消息元素将站点策略交付给WTP后，AC可以通过发送修改后的添加站点消息元素来更改任何策略。当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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+
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 | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+
Type: 8 for Add Station
类型：8用于添加站
Length: >= 8
Length: >= 8
Radio ID: An 8-bit value representing the radio, whose value is between one (1) and 31.
无线电ID：表示无线电的8位值，其值介于1和31之间。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: The station's MAC address.
MAC地址：站点的MAC地址。
VLAN Name: An optional variable-length UTF-8 encoded string [RFC3629], with a maximum length of 512 octets, containing the VLAN Name on which the WTP is to locally bridge user data. Note this field is only valid with WTPs configured in Local MAC mode.
VLAN名称：可选的可变长度UTF-8编码字符串[RFC3629]，最大长度为512个八位字节，包含WTP在其上本地桥接用户数据的VLAN名称。注意：此字段仅在本地MAC模式下配置WTP时有效。
The CAPWAP Control IPv4 Address message element is sent by the AC to the WTP during the Discovery process and is used by the AC to provide the interfaces available on the AC, and the current number of WTPs connected. When multiple CAPWAP Control IPV4 Address message elements are returned, the WTP SHOULD perform load balancing across the multiple interfaces (see Section 6.1).
CAPWAP控制IPv4地址消息元素在发现过程中由AC发送到WTP，AC使用该元素提供AC上可用的接口以及当前连接的WTP数量。当返回多个CAPWAP控制IPV4地址消息元素时，WTP应跨多个接口执行负载平衡（参见第6.1节）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for CAPWAP Control IPv4 Address
类型：10表示CAPWAP控制IPv4地址
Length: 6
长度：6
IP Address: The IP address of an interface.
IP地址：接口的IP地址。
WTP Count: The number of WTPs currently connected to the interface, with a maximum value of 65535.
WTP计数：当前连接到接口的WTP数，最大值为65535。
The CAPWAP Control IPv6 Address message element is sent by the AC to the WTP during the Discovery process and is used by the AC to provide the interfaces available on the AC, and the current number of WTPs connected. This message element is useful for the WTP to perform load balancing across multiple interfaces (see Section 6.1).
CAPWAP控制IPv6地址消息元素在发现过程中由AC发送到WTP，AC使用该元素提供AC上可用的接口以及当前连接的WTP数量。此消息元素有助于WTP跨多个接口执行负载平衡（参见第6.1节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for CAPWAP Control IPv6 Address
类型：11表示CAPWAP控制IPv6地址
Length: 18
长度：18
IP Address: The IP address of an interface.
IP地址：接口的IP地址。
WTP Count: The number of WTPs currently connected to the interface, with a maximum value of 65535.
WTP计数：当前连接到接口的WTP数，最大值为65535。
The CAPWAP Local IPv4 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv4 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element.
CAPWAP本地IPv4地址消息元素由WTP在加入请求中发送，或由AC在加入响应中发送。CAPWAP本地IPv4地址消息元素用于传输发射机的IP地址。接收方通过将数据包的源IP地址与消息元素的值进行比较来确定两个对等方之间是否存在中间盒。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for CAPWAP Local IPv4 Address
类型：30表示CAPWAP本地IPv4地址
Length: 4
长度：4
IP Address: The IP address of the sender.
IP地址：发送方的IP地址。
The CAPWAP Local IPv6 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv6 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element.
CAPWAP本地IPv6地址消息元素由WTP在加入请求中发送，或由AC在加入响应中发送。CAPWAP本地IPv6地址消息元素用于传送发射机的IP地址。接收方通过将数据包的源IP地址与消息元素的值进行比较来确定两个对等方之间是否存在中间盒。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 50 for CAPWAP Local IPv6 Address
类型：50表示CAPWAP本地IPv6地址
Length: 16
长度：16
IP Address: The IP address of the sender.
IP地址：发送方的IP地址。
The CAPWAP Timers message element is used by an AC to configure CAPWAP timers on a WTP.
AC使用CAPWAP定时器消息元素在WTP上配置CAPWAP定时器。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12 for CAPWAP Timers
类型：12用于CAPWAP定时器
Length: 2
长度：2
Discovery: The number of seconds between CAPWAP Discovery messages, when the WTP is in the Discovery phase. This value is used to configure the MaxDiscoveryInterval timer (see Section 4.7.10).
发现：当WTP处于发现阶段时，CAPWAP发现消息之间的秒数。该值用于配置MaxDiscoveryInterval定时器（见第4.7.10节）。
Echo Request: The number of seconds between WTP Echo Request CAPWAP messages. This value is used to configure the EchoInterval timer (see Section 4.7.7). The AC sets its EchoInterval timer to this value, plus the maximum retransmission time as described in Section 4.5.3.
Echo Request：WTP Echo Request CAPWAP消息之间的秒数。该值用于配置EchoInterval定时器（见第4.7.7节）。AC将其EchoInterval定时器设置为该值，加上第4.5.3节所述的最大重传时间。
When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be used (see Section 3). The CAPWAP IPv6 Transport Protocol message element is used by either the WTP or the AC to signal which transport protocol is to be used for the CAPWAP data channel.
当CAPWAP通过IPv6运行时，可以使用UDP Lite或UDP传输（参见第3节）。WTP或AC使用CAPWAP IPv6传输协议消息元素来表示CAPWAP数据通道将使用哪个传输协议。
Upon receiving the Join Request, the AC MAY set the CAPWAP Transport Protocol to UDP-Lite in the Join Response message if the CAPWAP message was received over IPv6, and the CAPWAP Local IPv6 Address message element (see Section 4.6.12) is present and no middlebox was detected (see Section 11).
收到加入请求后，如果通过IPv6接收到CAPWAP消息，且存在CAPWAP本地IPv6地址消息元素（参见第4.6.12节）且未检测到任何中间盒（参见第11节），则AC可在加入响应消息中将CAPWAP传输协议设置为UDP Lite。
Upon receiving the Join Response, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in the Configuration Status Request or Image Data Request message if the AC advertised support for UDP-Lite, the message was received over IPv6, the CAPWAP Local IPv6 Address message element (see Section 4.6.12) and no middlebox was detected (see Section 11). Upon receiving either the Configuration Status Request or the Image Data Request, the AC MUST observe the preference indicated by the WTP in the CAPWAP Transport Protocol, as long as it is consistent with what the AC advertised in the Join Response.
收到加入响应后，WTP可在配置状态请求或图像数据请求消息中将CAPWAP传输协议设置为UDP Lite，前提是AC公布的对UDP Lite的支持，该消息是通过IPv6、CAPWAP本地IPv6地址消息元素（参见第4.6.12节）接收的，并且未检测到任何中间盒（参见第11节）. 收到配置状态请求或图像数据请求后，AC必须遵守CAPWAP传输协议中WTP指示的首选项，只要它与AC在加入响应中公布的内容一致。
For any other condition, the CAPWAP Transport Protocol MUST be set to UDP.
对于任何其他情况，CAPWAP传输协议必须设置为UDP。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+
Type: 51 for CAPWAP Transport Protocol
类型：51用于CAPWAP传输协议
Length: 1
长度：1
Transport: The transport to use for the CAPWAP Data channel. The following enumerated values are supported:
传输：用于CAPWAP数据通道的传输。支持以下枚举值：
1 - UDP-Lite: The UDP-Lite transport protocol is to be used for the CAPWAP Data channel. Note that this option MUST NOT be used if the CAPWAP Control channel is being used over IPv4.
1-UDP Lite：UDP Lite传输协议将用于CAPWAP数据通道。请注意，如果通过IPv4使用CAPWAP控制通道，则不得使用此选项。
2 - UDP: The UDP transport protocol is to be used for the CAPWAP Data channel.
2-UDP：UDP传输协议将用于CAPWAP数据通道。
The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes.
WTP使用数据传输数据消息元素向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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Mode | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ....
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Mode | Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ....
+-+-+-+-+-+-+-+-+
Type: 13 for Data Transfer Data
类型：13用于数据传输数据
Length: >= 5
Length: >= 5
Data Type: An 8-bit value representing the transfer Data Type. The following enumerated values are supported:
数据类型：表示传输数据类型的8位值。支持以下枚举值：
1 - Transfer data is included.
1-包括传输数据。
2 - Last Transfer Data Block is included (End of File (EOF)).
2-包括最后一个传输数据块（文件末尾（EOF））。
5 - An error occurred. Transfer is aborted.
5-发生错误。传输被中止。
Data Mode: An 8-bit value describing the type of information being transmitted. The following enumerated values are supported:
数据模式：描述传输信息类型的8位值。支持以下枚举值：
0 - Reserved
0-保留
1 - WTP Crash Data
1-WTP碰撞数据
2 - WTP Memory Dump
2-WTP内存转储
Data Length: Length of data field, with a maximum size of 65535.
数据长度：数据字段的长度，最大为65535。
Data: Data being transferred from the WTP to the AC, whose type is identified via the Data Mode field.
数据：从WTP传输到AC的数据，其类型通过数据模式字段标识。
The Data Transfer Mode message element is used by the WTP to indicate the type of data transfer information it is sending to the AC for debugging purposes.
WTP使用数据传输模式消息元素指示其发送给AC的数据传输信息的类型，以便进行调试。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Data Mode |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Data Mode |
+-+-+-+-+-+-+-+-+
Type: 14 for Data Transfer Mode
类型：14用于数据传输模式
Length: 1
长度：1
Data Mode: An 8-bit value describing the type of information being requested. The following enumerated values are supported:
数据模式：描述所请求信息类型的8位值。支持以下枚举值：
0 - Reserved
0-保留
1 - WTP Crash Data
1-WTP碰撞数据
2 - WTP Memory Dump
2-WTP内存转储
The Decryption Error Report message element value is used by the WTP to inform the AC of decryption errors that have occurred since the last report. Note that this error reporting mechanism is not used if encryption and decryption services are provided in the AC.
WTP使用解密错误报告消息元素值通知AC自上次报告以来发生的解密错误。请注意，如果AC中提供了加密和解密服务，则不使用此错误报告机制。
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 | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for Decryption Error Report
类型：15用于解密错误报告
Length: >= 9
Length: >= 9
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31.
无线电标识：无线电标识是指WTP上的接口索引，其值介于1和31之间。
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This field MUST NOT exceed the value of 255.
条目数：数组中长度/MAC地址字段的实例数。此字段不得超过255的值。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: MAC address of the station that has caused decryption errors.
MAC地址：导致解密错误的站点的MAC地址。
The Decryption Error Report Period message element value is used by the AC to inform the WTP how frequently it should send decryption error report messages. Note that this error reporting mechanism is not used if encryption and decryption services are provided in the AC.
AC使用解密错误报告周期消息元素值通知WTP发送解密错误报告消息的频率。请注意，如果AC中提供了加密和解密服务，则不使用此错误报告机制。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 16 for Decryption Error Report Period
类型：16用于解密错误报告期
Length: 3
长度：3
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31.
无线电标识：无线电标识是指WTP上的接口索引，其值介于1和31之间。
Report Interval: A 16-bit unsigned integer indicating the time, in seconds. The default value for this message element can be found in Section 4.7.11.
报告间隔：表示时间的16位无符号整数，以秒为单位。该消息元素的默认值见第4.7.11节。
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.
AC使用删除MAC ACL条目消息元素删除WTP上的MAC ACL条目，确保WTP向消息中提供的MAC地址提供服务。
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| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 17 for Delete MAC ACL Entry
类型：17用于删除MAC ACL条目
Length: >= 8
Length: >= 8
Num of Entries: The number of instances of the Length/MAC Address fields in the array. This field MUST NOT exceed the value of 255.
条目数：数组中长度/MAC地址字段的实例数。此字段不得超过255的值。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: An array of MAC addresses to delete from the ACL.
MAC地址：要从ACL中删除的MAC地址数组。
The Delete Station message element is used by the AC to inform a WTP that it should no longer provide service to a particular station. The WTP MUST terminate service to the station immediately upon receiving this message element.
AC使用删除站点消息元素通知WTP它不应再向特定站点提供服务。WTP必须在收到此消息元素后立即终止对站点的服务。
The transmission of a Delete Station message element could occur for various reasons, including for administrative reasons, or if the station has roamed to another WTP.
删除站点消息元素的传输可能出于各种原因，包括管理原因，或者如果站点已漫游到另一个WTP。
The Delete Station message element MAY be sent by the WTP, in the WTP Event Request message, to inform the AC that a particular station is no longer being provided service. This could occur as a result of an Idle Timeout (see section 4.4.43), due to internal resource shortages or for some other reason.
可由WTP在WTP事件请求消息中发送删除站消息元素，以通知AC特定站不再被提供服务。这可能是由于内部资源短缺或其他原因导致的空闲超时（见第4.4.43节）。
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 | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Length | MAC Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18 for Delete Station
类型：18用于删除站点
Length: >= 8
Length: >= 8
Radio ID: An 8-bit value representing the radio, whose value is between one (1) and 31.
无线电ID：表示无线电的8位值，其值介于1和31之间。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: The station's MAC address.
MAC地址：站点的MAC地址。
The Discovery Type message element is used by the WTP to indicate how it has come to know about the existence of the AC to which it is sending the Discovery Request message.
WTP使用发现类型消息元素来指示它如何知道它正在向其发送发现请求消息的AC的存在。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Discovery Type|
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Discovery Type|
+-+-+-+-+-+-+-+-+
Type: 20 for Discovery Type
类型：发现类型为20
Length: 1
长度：1
Discovery Type: An 8-bit value indicating how the WTP discovered the AC. The following enumerated values are supported:
发现类型：一个8位值，指示WTP如何发现AC。支持以下枚举值：
0 - Unknown
0-未知
1 - Static Configuration
1-静态配置
2 - DHCP
2-DHCP
3 - DNS
3-DNS
4 - AC Referral (used when the AC was configured either through the AC IPv4 List or AC IPv6 List message element)
4-AC参考（通过AC IPv4列表或AC IPv6列表消息元素配置AC时使用）
The Duplicate IPv4 Address message element is used by a WTP to inform an AC that it has detected another IP device using the same IP address that the WTP is currently using.
WTP使用重复IPv4地址消息元素通知AC，它已检测到另一个IP设备使用WTP当前使用的相同IP地址。
The WTP MUST transmit this message element with the status set to 1 after it has detected a duplicate IP address. When the WTP detects that the duplicate IP address has been cleared, it MUST send this message element with the status set to 0.
WTP在检测到重复的IP地址后，必须以设置为1的状态发送此消息元素。当WTP检测到重复IP地址已被清除时，它必须发送状态设置为0的此消息元素。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 21 for Duplicate IPv4 Address
类型：21表示重复的IPv4地址
Length: >= 12
Length: >= 12
IP Address: The IP address currently used by the WTP.
IP地址：WTP当前使用的IP地址。
Status: The status of the duplicate IP address. The value MUST be set to 1 when a duplicate address is detected, and 0 when the duplicate address has been cleared.
状态：重复IP地址的状态。检测到重复地址时，该值必须设置为1，清除重复地址时，该值必须设置为0。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: The MAC address of the offending device.
MAC地址：违规设备的MAC地址。
The Duplicate IPv6 Address message element is used by a WTP to inform an AC that it has detected another host using the same IP address that the WTP is currently using.
WTP使用复制IPv6地址消息元素通知AC，它已检测到另一台主机使用WTP当前使用的相同IP地址。
The WTP MUST transmit this message element with the status set to 1 after it has detected a duplicate IP address. When the WTP detects that the duplicate IP address has been cleared, it MUST send this message element with the status set to 0.
WTP在检测到重复的IP地址后，必须以设置为1的状态发送此消息元素。当WTP检测到重复IP地址已被清除时，它必须发送状态设置为0的此消息元素。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22 for Duplicate IPv6 Address
类型：22表示重复的IPv6地址
Length: >= 24
Length: >= 24
IP Address: The IP address currently used by the WTP.
IP地址：WTP当前使用的IP地址。
Status: The status of the duplicate IP address. The value MUST be set to 1 when a duplicate address is detected, and 0 when the duplicate address has been cleared.
状态：重复IP地址的状态。检测到重复地址时，该值必须设置为1，清除重复地址时，该值必须设置为0。
Length: The length of the MAC Address field. The formats and lengths specified in [EUI-48] and [EUI-64] are supported.
长度：MAC地址字段的长度。支持[EUI-48]和[EUI-64]中指定的格式和长度。
MAC Address: The MAC address of the offending device.
MAC地址：违规设备的MAC地址。
The Idle Timeout message element is sent by the AC to the WTP to provide the Idle Timeout value that the WTP SHOULD enforce for its active stations. The value applies to all radios on the WTP.
空闲超时消息元素由AC发送到WTP，以提供WTP应为其活动站点强制执行的空闲超时值。该值适用于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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 23 for Idle Timeout
类型：23表示空闲超时
Length: 4
长度：4
Timeout: The current Idle Timeout, in seconds, to be enforced by the WTP. The default value for this message element is specified in Section 4.7.8.
超时：WTP将强制执行的当前空闲超时（以秒为单位）。第4.7.8节规定了此消息元素的默认值。
The ECN Support message element is sent by both the WTP and the AC to indicate their support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168].
如[RFC3168]中所定义，WTP和AC均发送ECN支持消息元素，以表明其对显式拥塞通知（ECN）位的支持。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ECN Support |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ECN Support |
+-+-+-+-+-+-+-+-+
Type: 53 for ECN Support
类型：53用于ECN支持
Length: 1
长度：1
ECN Support: An 8-bit value representing the sender's support for ECN, as defined in [RFC3168]. All CAPWAP Implementations MUST support the Limited ECN Support mode. Full ECN Support is used if both the WTP and AC advertise the capability for "Full and Limited ECN" Support; otherwise, Limited ECN Support is used.
ECN支持：一个8位值，表示发送方对ECN的支持，如[RFC3168]中所定义。所有CAPWAP实施必须支持有限的ECN支持模式。如果WTP和AC都宣传“完全和有限ECN”支持的能力，则使用完全ECN支持；否则，将使用有限的ECN支持。
0 - Limited ECN Support
0-有限的ECN支持
1 - Full and Limited ECN Support
1-全面和有限的ECN支持
The Image Data message element is present in the Image Data Request message sent by the AC and contains the following fields.
图像数据消息元素存在于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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24 for Image Data
类型：24用于图像数据
Length: >= 1
Length: >= 1
Data Type: An 8-bit value representing the image Data Type. The following enumerated values are supported:
数据类型：表示图像数据类型的8位值。支持以下枚举值：
1 - Image data is included.
1-包括图像数据。
2 - Last Image Data Block is included (EOF).
2-包括最后一个图像数据块（EOF）。
5 - An error occurred. Transfer is aborted.
5-发生错误。传输被中止。
Data: The Image Data field contains up to 1024 characters, and its length is inferred from this message element's length field. If the block being sent is the last one, the Data Type field is set to 2. The AC MAY opt to abort the data transfer by setting the Data Type field to 5. When the Data Type field is 5, the Value field has a zero length.
数据：图像数据字段最多包含1024个字符，其长度由此消息元素的长度字段推断。如果要发送的块是最后一个，则数据类型字段设置为2。AC可通过将数据类型字段设置为5来选择中止数据传输。当数据类型字段为5时，值字段的长度为零。
The Image Identifier message element is sent by the AC to the WTP to indicate the expected active software version that is to be run on the WTP. The WTP sends the Image Identifier message element in order to request a specific software version from the AC. The actual download process is defined in Section 9.1. The value is a variable-length UTF-8 encoded string [RFC3629], which is NOT zero terminated.
图像标识符消息元素由AC发送到WTP，以指示将在WTP上运行的预期活动软件版本。WTP发送图像标识符消息元素，以便从AC请求特定软件版本。实际下载过程在第9.1节中定义。该值是一个可变长度UTF-8编码字符串[RFC3629]，它不是以零结尾的。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 25 for Image Identifier
类型：25表示图像标识符
Length: >= 5
Length: >= 5
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes".
供应商标识符：包含IANA分配的“SMI网络管理私有企业代码”的32位值。
Data: A variable-length UTF-8 encoded string [RFC3629] containing the firmware identifier to be run on the WTP, whose length MUST NOT exceed 1024 octets. The length of this field is inferred from this message element's length field.
数据：可变长度UTF-8编码字符串[RFC3629]，包含要在WTP上运行的固件标识符，其长度不得超过1024个八位字节。此字段的长度是根据此消息元素的长度字段推断的。
The Image Information message element is present in the Image Data Response message sent by the AC to the WTP and contains the following fields.
图像信息消息元素存在于AC发送至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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Image Information
类型：26用于图像信息
Length: 20
长度：20
File Size: A 32-bit value containing the size of the file, in bytes, that will be transferred by the AC to the WTP.
文件大小：一个32位值，包含AC将传输到WTP的文件大小（以字节为单位）。
Hash: A 16-octet MD5 hash of the image using the procedures defined in [RFC1321].
哈希：使用[RFC1321]中定义的过程对图像进行16个八位MD5哈希。
The Initiate Download message element is used by the WTP to inform the AC that the AC SHOULD initiate a firmware upgrade. The AC subsequently transmits an Image Data Request message, which includes the Image Data message element. This message element does not contain any data.
WTP使用Initiate Download message元素通知AC AC应启动固件升级。AC随后发送包括图像数据消息元素的图像数据请求消息。此消息元素不包含任何数据。
Type: 27 for Initiate Download
类型：27用于启动下载
Length: 0
长度：0
The Location Data message element is a variable-length byte UTF-8 encoded string [RFC3629] containing user-defined location information (e.g., "Next to Fridge"). This information is configurable by the network administrator, and allows the WTP location to be determined. The string is not zero terminated.
位置数据消息元素是一个可变长度字节UTF-8编码字符串[RFC3629]，包含用户定义的位置信息（例如，“冰箱旁边”）。该信息可由网络管理员配置，并允许确定WTP位置。字符串不是以零结尾的。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| Location ...
+-+-+-+-+-+-+-+-+-
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| Location ...
+-+-+-+-+-+-+-+-+-
Type: 28 for Location Data
类型：28用于位置数据
Length: >= 1
Length: >= 1
Location: A non-zero-terminated UTF-8 encoded string [RFC3629] containing the WTP location, whose maximum size MUST NOT exceed 1024.
位置：包含WTP位置的非零终止UTF-8编码字符串[RFC3629]，其最大大小不得超过1024。
The Maximum Message Length message element is included in the Join Request message by the WTP to indicate the maximum CAPWAP message length that it supports to the AC. The Maximum Message Length message element is optionally included in Join Response message by the AC to indicate the maximum CAPWAP message length that it supports to the WTP.
WTP将最大消息长度消息元素包含在加入请求消息中，以指示其对AC支持的最大CAPWAP消息长度。AC可选择将最大消息长度消息元素包含在加入响应消息中，以指示其对WTP支持的最大CAPWAP消息长度。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 29 for Maximum Message Length
类型：29表示最大消息长度
Length: 2
长度：2
Maximum Message Length A 16-bit unsigned integer indicating the maximum message length.
最大消息长度指示最大消息长度的16位无符号整数。
The MTU Discovery Padding message element is used as padding to perform MTU discovery, and MUST contain octets of value 0xFF, of any length.
MTU发现填充消息元素用作执行MTU发现的填充，并且必须包含任意长度的值为0xFF的八位字节。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding...
+-+-+-+-+-+-+-+-
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding...
+-+-+-+-+-+-+-+-
Type: 52 for MTU Discovery Padding
类型：52用于MTU查找填充
Length: Variable
长度：可变
Pad: A variable-length pad, filled with the value 0xFF.
Pad：可变长度的Pad，填充值0xFF。
The Radio Administrative State message element is used to communicate the state of a particular radio. The Radio Administrative State message element is sent by the AC to change the state of the WTP. The WTP saves the value, to ensure that it remains across WTP resets. The WTP communicates this message element during the configuration phase, in the Configuration Status Request message, to ensure that the AC has the WTP radio current administrative state settings. The message element contains the following fields:
无线电管理状态消息元素用于传达特定无线电的状态。AC发送无线电管理状态消息元素以更改WTP的状态。WTP保存该值，以确保该值在WTP重置期间保持不变。WTP在配置阶段在配置状态请求消息中传递此消息元素，以确保AC具有WTP无线电当前管理状态设置。message元素包含以下字段：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 31 for Radio Administrative State
类型：31表示无线电管理状态
Length: 2
长度：2
Radio ID: An 8-bit value representing the radio to configure, whose value is between one (1) and 31. The Radio ID field MAY also include the value of 0xff, which is used to identify the WTP. If an AC wishes to change the administrative state of a WTP, it includes 0xff in the Radio ID field.
Radio ID：表示要配置的无线电的8位值，其值介于一（1）和31之间。无线电ID字段还可以包括0xff的值，该值用于识别WTP。如果AC希望更改WTP的管理状态，则在Radio ID字段中包含0xff。
Admin State: An 8-bit value representing the administrative state of the radio. The default value for the Admin State field is listed in Section 4.8.1. The following enumerated values are supported:
管理状态：表示无线电管理状态的8位值。第4.8.1节列出了管理状态字段的默认值。支持以下枚举值：
0 - Reserved
0-保留
1 - Enabled
1-启用
2 - Disabled
2-残疾人士
The Radio Operational State message element is sent by the WTP to the AC to communicate a radio's operational state. This message element is included in the Configuration Update Response message by the WTP if it was requested to change the state of its radio, via the Radio Administrative State message element, but was unable to comply to the request. This message element is included in the Change State Event message when a WTP radio state was changed unexpectedly. This could occur due to a hardware failure. Note that the operational state setting is not saved on the WTP, and therefore does not remain across WTP resets. The value contains three fields, as shown below.
无线操作状态消息元素由WTP发送至AC，以传达无线操作状态。如果WTP通过无线电管理状态消息元素被请求更改其无线电状态，但无法遵守请求，则该消息元素将包含在配置更新响应消息中。当WTP无线电状态意外更改时，此消息元素包含在更改状态事件消息中。这可能是由于硬件故障造成的。请注意，操作状态设置未保存在WTP上，因此不会在WTP重置期间保持不变。该值包含三个字段，如下所示。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 32 for Radio Operational State
类型：32表示无线电工作状态
Length: 3
长度：3
Radio ID: The Radio Identifier refers to an interface index on the WTP, whose value is between one (1) and 31. A value of 0xFF is invalid, as it is not possible to change the WTP's operational state.
无线电标识：无线电标识是指WTP上的接口索引，其值介于1和31之间。0xFF值无效，因为无法更改WTP的运行状态。
State: An 8-bit Boolean value representing the state of the radio. The following enumerated values are supported:
状态：表示收音机状态的8位布尔值。支持以下枚举值：
0 - Reserved
0-保留
1 - Enabled
1-启用
2 - Disabled
2-残疾人士
Cause: When a radio is inoperable, the cause field contains the reason the radio is out of service. The following enumerated values are supported:
原因：当收音机不可操作时，原因字段包含收音机停止工作的原因。支持以下枚举值：
0 - Normal
0-正常
1 - Radio Failure
1-无线电故障
2 - Software Failure
2-软件故障
3 - Administratively Set
3-行政设置
The Result Code message element value is a 32-bit integer value, indicating the result of the Request message corresponding to the sequence number included in the Response message.
结果代码消息元素值是32位整数值，指示与响应消息中包含的序列号相对应的请求消息的结果。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 33 for Result Code
类型：33表示结果代码
Length: 4
长度：4
Result Code: The following enumerated values are defined:
结果代码：定义了以下枚举值：
0 Success
0成功
1 Failure (AC List Message Element MUST Be Present)
1故障（AC列表消息元素必须存在）
2 Success (NAT Detected)
2成功（检测到NAT）
3 Join Failure (Unspecified)
3连接失败（未指定）
4 Join Failure (Resource Depletion)
4连接失败（资源耗尽）
5 Join Failure (Unknown Source)
5连接失败（未知源）
6 Join Failure (Incorrect Data)
6连接失败（数据不正确）
7 Join Failure (Session ID Already in Use)
7加入失败（会话ID已在使用）
8 Join Failure (WTP Hardware Not Supported)
8连接失败（不支持WTP硬件）
9 Join Failure (Binding Not Supported)
9连接失败（不支持绑定）
10 Reset Failure (Unable to Reset)
10复位失败（无法复位）
11 Reset Failure (Firmware Write Error)
11复位故障（固件写入错误）
12 Configuration Failure (Unable to Apply Requested Configuration - Service Provided Anyhow)
12配置失败（无法应用请求的配置-无论如何都提供了服务）
13 Configuration Failure (Unable to Apply Requested Configuration - Service Not Provided)
13配置失败（无法应用请求的配置-未提供服务）
14 Image Data Error (Invalid Checksum)
14图像数据错误（校验和无效）
15 Image Data Error (Invalid Data Length)
15图像数据错误（数据长度无效）
16 Image Data Error (Other Error)
16图像数据错误（其他错误）
17 Image Data Error (Image Already Present)
17图像数据错误（图像已存在）
18 Message Unexpected (Invalid in Current State)
18意外消息（当前状态下无效）
19 Message Unexpected (Unrecognized Request)
19意外消息（无法识别的请求）
20 Failure - Missing Mandatory Message Element
20故障-缺少必需的消息元素
21 Failure - Unrecognized Message Element
21故障-无法识别的消息元素
22 Data Transfer Error (No Information to Transfer)
22数据传输错误（无需传输的信息）
The Returned Message Element is sent by the WTP in the Change State Event Request message to communicate to the AC which message elements in the Configuration Status Response it was unable to apply locally. The Returned Message Element message element contains a result code indicating the reason that the configuration could not be applied, and encapsulates the failed message element.
返回的消息元素由WTP在更改状态事件请求消息中发送，以与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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Length | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Length | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for Returned Message Element
返回消息元素的类型：34
Length: >= 6
Length: >= 6
Reason: The reason the configuration in the offending message element could not be applied by the WTP. The following enumerated values are supported:
原因：WTP无法应用有问题消息元素中的配置的原因。支持以下枚举值：
0 - Reserved
0-保留
1 - Unknown Message Element
1-未知消息元素
2 - Unsupported Message Element
2-不支持的消息元素
3 - Unknown Message Element Value
3-未知消息元素值
4 - Unsupported Message Element Value
4-不支持的消息元素值
Length: The length of the Message Element field, which MUST NOT exceed 255 octets.
长度：消息元素字段的长度，不得超过255个八位字节。
Message Element: The Message Element field encapsulates the message element sent by the AC in the Configuration Status Response message that caused the error.
Message Element（消息元素）：Message Element（消息元素）字段将AC发送的消息元素封装在导致错误的配置状态响应消息中。
The Session ID message element value contains a randomly generated unsigned 128-bit integer.
会话ID消息元素值包含随机生成的无符号128位整数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 35 for Session ID
类型：会话ID为35
Length: 16
长度：16
Session ID: A 128-bit unsigned integer used as a random session identifier
会话ID：用作随机会话标识符的128位无符号整数
The Statistics Timer message element value is used by the AC to inform the WTP of the frequency with which it expects to receive updated statistics.
AC使用统计定时器消息元素值通知WTP其预期接收更新统计信息的频率。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 36 for Statistics Timer
类型：36用于统计计时器
Length: 2
长度：2
Statistics Timer: A 16-bit unsigned integer indicating the time, in seconds. The default value for this timer is specified in Section 4.7.14.
统计计时器：表示时间的16位无符号整数，以秒为单位。第4.7.14节规定了该定时器的默认值。
The Vendor Specific Payload message element is used to communicate vendor-specific information between the WTP and the AC. The Vendor Specific Payload message element MAY be present in any CAPWAP message. The exchange of vendor-specific data between the MUST NOT modify the behavior of the base CAPWAP protocol and state machine. The message element uses the following format:
供应商特定有效负载消息元素用于在WTP和AC之间传送供应商特定信息。供应商特定有效负载消息元素可能存在于任何CAPWAP消息中。在之间交换特定于供应商的数据不得修改基本CAPWAP协议和状态机的行为。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Vendor Specific Payload
类型：37用于供应商特定的有效载荷
Length: >= 7
Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC3232].
供应商标识符：32位值，包含IANA分配的“SMI网络管理专用企业代码”[RFC3232]。
Element ID: A 16-bit Element Identifier that is managed by the vendor.
元素ID：由供应商管理的16位元素标识符。
Data: Variable-length vendor-specific information, whose contents and format are proprietary and understood based on the Element ID field. This field MUST NOT exceed 2048 octets.
数据：可变长度的供应商特定信息，其内容和格式是专有的，并根据元素ID字段理解。此字段不得超过2048个八位字节。
The WTP Board Data message element is sent by the WTP to the AC and contains information about the hardware present.
WTP板数据消息元素由WTP发送至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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for WTP Board Data
类型：38用于WTP板数据
Length: >=14
Length: >=14
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes", identifying the WTP hardware manufacturer. The Vendor Identifier field MUST NOT be set to zero.
供应商标识符：包含IANA分配的“SMI网络管理私有企业代码”的32位值，用于标识WTP硬件制造商。供应商标识符字段不能设置为零。
Board Data Sub-Element: The WTP Board Data message element contains multiple Board Data sub-elements, some of which are mandatory and some are optional, as described below. The Board Data Type values are not extensible by vendors, and are therefore not coupled along with the Vendor Identifier field. The Board Data sub-element has the following format:
线路板数据子元素：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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Type | Board Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Type | Board Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Board Data Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Board Data Type: The Board Data Type field identifies the data being encoded. The CAPWAP protocol defines the following values, and each of these types identify whether their presence is mandatory or optional:
线路板数据类型：线路板数据类型字段标识正在编码的数据。CAPWAP协议定义了以下值，这些值中的每一种都标识了它们的存在是强制性的还是可选的：
0 - WTP Model Number: The WTP Model Number MUST be included in the WTP Board Data message element.
0-WTP型号：WTP型号必须包含在WTP板数据消息元素中。
1 - WTP Serial Number: The WTP Serial Number MUST be included in the WTP Board Data message element.
1-WTP序列号：WTP序列号必须包含在WTP板数据消息元素中。
2 - Board ID: A hardware identifier, which MAY be included in the WTP Board Data message element.
2-板ID：硬件标识符，可包含在WTP板数据消息元素中。
3 - Board Revision: A revision number of the board, which MAY be included in the WTP Board Data message element.
3-电路板版本：电路板的版本号，可包含在WTP电路板数据消息元素中。
4 - Base MAC Address: The WTP's Base MAC address, which MAY be assigned to the primary Ethernet interface.
4-基本MAC地址：WTP的基本MAC地址，可分配给主以太网接口。
Board Data Length: The length of the data in the Board Data Value field, whose length MUST NOT exceed 1024 octets.
线路板数据长度：线路板数据值字段中的数据长度，其长度不得超过1024个八位字节。
Board Data Value: The data associated with the Board Data Type field for this Board Data sub-element.
线路板数据值：与此线路板数据子元素的线路板数据类型字段关联的数据。
The WTP Descriptor message element is used by a WTP to communicate its current hardware and software (firmware) configuration. The value contains the following fields:
WTP描述符消息元素由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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Sub-Element | Descriptor Sub-Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for WTP Descriptor
类型：39用于WTP描述符
Length: >= 33
Length: >= 33
Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the Radio ID field) supported by the WTP.
Max Radios：一个8位值，表示WTP支持的无线电数量（每个无线电通过无线电ID字段标识）。
Radios in use: An 8-bit value representing the number of radios in use in the WTP.
正在使用的无线电：一个8位值，表示WTP中正在使用的无线电数量。
Num Encrypt: The number of 3-byte Encryption sub-elements that follow this field. The value of the Num Encrypt field MUST be between one (1) and 255.
Num Encrypt：此字段后面的3字节加密子元素数。Num Encrypt字段的值必须介于一（1）和255之间。
Encryption Sub-Element: The WTP Descriptor message element MUST contain at least one Encryption sub-element. One sub-element is present for each binding supported by the WTP. The Encryption sub-element has the following format:
加密子元素：WTP描述符消息元素必须至少包含一个加密子元素。WTP支持的每个绑定都有一个子元素。加密子元素具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resvd| WBID | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resvd| WBID | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resvd: The 3-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
Resvd：3位字段保留供将来使用。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
WBID: A 5-bit field that is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The WBIDs defined in this specification can be found in Section 4.3.
WBID：一个5位字段，是无线绑定标识符。标识符将指示与无线电相关联的无线分组的类型。本规范中定义的WBID见第4.3节。
Encryption Capabilities: This 16-bit field is used by the WTP to communicate its capabilities to the AC. A WTP that does not have any encryption capabilities sets this field to zero (0). Refer to the specific wireless binding for further specification of the Encryption Capabilities field.
加密功能：WTP使用此16位字段将其功能与AC通信。没有任何加密功能的WTP将此字段设置为零（0）。有关加密功能字段的进一步规范，请参阅特定的无线绑定。
Descriptor Sub-Element: The WTP Descriptor message element contains multiple Descriptor sub-elements, some of which are mandatory and some are optional, as described below. The Descriptor sub-element has the following format:
描述符子元素：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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Type | Descriptor Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Type | Descriptor Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Descriptor Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes".
描述符供应商标识符：包含IANA分配的“SMI网络管理专用企业代码”的32位值。
Descriptor Type: The Descriptor Type field identifies the data being encoded. The format of the data is vendor-specific encoded in the UTF-8 format [RFC3629]. The CAPWAP protocol defines the following values, and each of these types identify whether their presence is mandatory or optional. The values listed below are used in conjunction with the Descriptor Vendor Identifier field, whose value MUST be set to zero (0). This field, combined with the Descriptor Vendor Identifier set to a non-zero (0) value, allows vendors to use a private namespace.
描述符类型：描述符类型字段标识正在编码的数据。数据格式为UTF-8格式[RFC3629]中的供应商特定编码。CAPWAP协议定义了以下值，这些值中的每一种都标识它们的存在是强制性的还是可选的。下面列出的值与描述符供应商标识符字段一起使用，其值必须设置为零（0）。此字段与设置为非零（0）值的描述符供应商标识符相结合，允许供应商使用私有命名空间。
0 - Hardware Version: The WTP hardware version number MUST be present.
0-硬件版本：WTP硬件版本号必须存在。
1 - Active Software Version: The WTP running software version number MUST be present.
1-活动软件版本：WTP运行软件版本号必须存在。
2 - Boot Version: The WTP boot loader version number MUST be present.
2-启动版本：WTP启动加载程序版本号必须存在。
3 - Other Software Version: The WTP non-running software (firmware) version number MAY be present. This type is used to communicate alternate software versions that are available on the WTP's non-volatile storage.
3-其他软件版本：可能存在WTP非运行软件（固件）版本号。此类型用于传送WTP非易失性存储器上可用的备用软件版本。
Descriptor Length: Length of the vendor-specific encoding of the Descriptor Data field, whose length MUST NOT exceed 1024 octets.
描述符长度：描述符数据字段的供应商特定编码的长度，其长度不得超过1024个八位字节。
Descriptor Data: Vendor-specific data of WTP information encoded in the UTF-8 format [RFC3629].
描述符数据：以UTF-8格式编码的WTP信息的供应商特定数据[RFC3629]。
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 to which it is not currently connected.
AC向WTP发送WTP回退消息元素，以在WTP检测到其当前未连接的首选AC时启用或禁用自动CAPWAP回退。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
Type: 40 for WTP Fallback
类型：40用于WTP回退
Length: 1
长度：1
Mode: The 8-bit value indicates the status of automatic CAPWAP fallback on the WTP. When enabled, if the WTP detects that its primary AC is available, and that the WTP is not connected to the primary AC, the WTP SHOULD automatically disconnect from its current AC and reconnect to its primary AC. If disabled, the WTP will only reconnect to its primary AC through manual intervention (e.g., through the Reset Request message). The default value for this field is specified in Section 4.8.9. The following enumerated values are supported:
模式：8位值表示WTP上自动CAPWAP回退的状态。启用时，如果WTP检测到其主AC可用，且WTP未连接到主AC，则WTP应自动断开其当前AC并重新连接到其主AC。如果禁用，WTP将仅通过手动干预（例如，通过重置请求消息）重新连接到其主AC。第4.8.9节规定了该字段的默认值。支持以下枚举值：
0 - Reserved
0-保留
1 - Enabled
1-启用
2 - Disabled
2-残疾人士
The WTP Frame Tunnel Mode message element allows the WTP to communicate the tunneling modes of operation that 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.
WTP帧隧道模式消息元素允许WTP将其支持的隧道操作模式传达给AC。宣布支持所有类型的WTP允许AC根据其本地策略选择将使用的类型。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reservd|N|E|L|U|
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reservd|N|E|L|U|
+-+-+-+-+-+-+-+-+
Type: 41 for WTP Frame Tunnel Mode
类型：41适用于WTP框架隧道模式
Length: 1
长度：1
Reservd: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
Reservd：为将来使用而保留的一组位。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
N: Native Frame Tunnel mode requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see for example Section 4.4)
N：本机帧隧道模式要求WTP和AC将所有用户有效负载封装为本机无线帧，如无线绑定所定义（例如，参见第4.4节）
E: The 802.3 Frame Tunnel Mode requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.4). All user traffic is tunneled to the AC. This value MUST NOT be used when the WTP MAC Type is set to Split MAC.
E:802.3帧隧道模式要求WTP和AC将所有用户有效负载封装为本机IEEE 802.3帧（参见第4.4节）。所有用户流量都通过隧道传输到AC。当WTP MAC类型设置为拆分MAC时，不得使用此值。
L: When Local Bridging is used, the WTP does not tunnel user traffic to the AC; all user traffic is locally bridged. This value MUST NOT be used when the WTP MAC Type is set to Split MAC.
L：当使用本地桥接时，WTP不会将用户流量隧道到AC；所有用户流量都在本地桥接。当WTP MAC类型设置为拆分MAC时，不得使用此值。
R: A reserved bit for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support.
R：为将来使用而保留的位。符合此协议的所有实现必须将该实现支持的协议版本中保留的任何位设置为零。接收器必须忽略所有未为其支持的协议版本定义的位。
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 MAC类型消息元素允许WTP将其操作模式传达给AC。宣布支持两种模式的WTP允许AC根据本地策略选择要使用的模式。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MAC Type |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MAC Type |
+-+-+-+-+-+-+-+-+
Type: 44 for WTP MAC Type
类型：对于WTP MAC类型为44
Length: 1
长度：1
MAC Type: The MAC mode of operation supported by the WTP. The following enumerated values are supported:
MAC类型：WTP支持的MAC操作模式。支持以下枚举值：
0 - Local MAC: Local MAC is the default mode that MUST be supported by all WTPs. When tunneling is enabled (see Section 4.6.43), the encapsulated frames MUST be in the 802.3 format (see Section 4.4.2), unless a wireless management or control frame which MAY be in its native format. Any CAPWAP binding needs to specify the format of management and control wireless frames.
0-本地MAC：本地MAC是所有WTP必须支持的默认模式。启用隧道时（参见第4.6.43节），封装的帧必须采用802.3格式（参见第4.4.2节），除非无线管理或控制帧可能采用其本机格式。任何CAPWAP绑定都需要指定管理和控制无线帧的格式。
1 - Split MAC: Split MAC support is optional, and allows the AC to receive and process native wireless frames.
1-分割MAC：分割MAC支持是可选的，允许AC接收和处理本机无线帧。
2 - Both: WTP is capable of supporting both Local MAC and Split MAC.
2-两者：WTP能够同时支持本地MAC和拆分MAC。
The WTP Name message element is a variable-length byte UTF-8 encoded string [RFC3629]. The string is not zero terminated.
WTP名称消息元素是一个可变长度字节UTF-8编码字符串[RFC3629]。字符串不是以零结尾的。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| WTP Name ...
+-+-+-+-+-+-+-+-+-
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-
| WTP Name ...
+-+-+-+-+-+-+-+-+-
Type: 45 for WTP Name
类型：45表示WTP名称
Length: >= 1
Length: >= 1
WTP Name: A non-zero-terminated UTF-8 encoded string [RFC3629] containing the WTP name, whose maximum size MUST NOT exceed 512 bytes.
WTP名称：包含WTP名称的非零终止UTF-8编码字符串[RFC3629]，其最大大小不得超过512字节。
The WTP Radio Statistics message element is sent by the WTP to the AC to communicate statistics on radio behavior and reasons why the WTP radio has been reset. These counters are never reset on the WTP, and will therefore roll over to zero when the maximum size has been reached.
WTP无线电统计信息元素由WTP发送至AC，以传达有关无线电行为的统计信息以及重置WTP无线电的原因。这些计数器永远不会在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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Last Fail Type| Reset Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Failure Count | HW Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Failure Count | Unknown Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Update Count | Channel Change Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Band Change Count | Current Noise Floor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Last Fail Type| Reset Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Failure Count | HW Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Failure Count | Unknown Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Update Count | Channel Change Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Band Change Count | Current Noise Floor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 47 for WTP Radio Statistics
类型：47用于WTP无线电统计
Length: 20
长度：20
Radio ID: The radio ID of the radio to which the statistics apply, whose value is between one (1) and 31.
Radio ID：应用统计信息的收音机的收音机ID，其值介于一（1）和31之间。
Last Failure Type: The last WTP failure. The following enumerated values are supported:
上次故障类型：上次WTP故障。支持以下枚举值：
0 - Statistic Not Supported
0-不支持统计信息
1 - Software Failure
1-软件故障
2 - Hardware Failure
2-硬件故障
3 - Other Failure
3-其他故障
255 - Unknown (e.g., WTP doesn't keep track of info)
255-未知（例如，WTP不跟踪信息）
Reset Count: The number of times that the radio has been reset.
重置计数：收音机已重置的次数。
SW Failure Count: The number of times that the radio has failed due to software-related reasons.
SW Failure Count（软件故障计数）：由于软件相关原因导致无线电故障的次数。
HW Failure Count: The number of times that the radio has failed due to hardware-related reasons.
硬件故障计数：由于硬件相关原因导致收音机故障的次数。
Other Failure Count: The number of times that the radio has failed due to known reasons, other than software or hardware failure.
其他故障计数：由于已知原因（软件或硬件故障除外）导致收音机故障的次数。
Unknown Failure Count: The number of times that the radio has failed for unknown reasons.
未知故障计数：收音机因未知原因发生故障的次数。
Config Update Count: The number of times that the radio configuration has been updated.
配置更新计数：无线电配置已更新的次数。
Channel Change Count: The number of times that the radio channel has been changed.
频道更改计数：无线频道已更改的次数。
Band Change Count: The number of times that the radio has changed frequency bands.
频带更改计数：收音机更改频带的次数。
Current Noise Floor: A signed integer that indicates the noise floor of the radio receiver in units of dBm.
当前噪声下限：一个有符号整数，表示无线电接收机的噪声下限，单位为dBm。
The WTP Reboot Statistics message element is sent by the WTP to the AC to communicate reasons why WTP reboots have occurred. These counters are never reset on the WTP, and will therefore roll over to zero when the maximum size has been reached.
WTP向AC发送WTP重新启动统计信息元素，以说明发生WTP重新启动的原因。这些计数器永远不会在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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reboot Count | AC Initiated Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Failure Count | SW Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Failure Count | Other Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Failure Count |Last Failure Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reboot Count | AC Initiated Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Failure Count | SW Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Failure Count | Other Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Failure Count |Last Failure Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 48 for WTP Reboot Statistics
类型：48用于WTP重新启动统计信息
Length: 15
长度：15
Reboot Count: The number of reboots that have occurred due to a WTP crash. A value of 65535 implies that this information is not available on the WTP.
重新启动计数：由于WTP崩溃而发生的重新启动次数。值65535表示WTP上没有此信息。
AC Initiated Count: The number of reboots that have occurred at the request of a CAPWAP protocol message, such as a change in configuration that required a reboot or an explicit CAPWAP protocol reset request. A value of 65535 implies that this information is not available on the WTP.
AC Initiated Count（AC Initiated Count）：请求CAPWAP协议消息时发生的重新启动次数，例如需要重新启动的配置更改或明确的CAPWAP协议重置请求。值65535表示WTP上没有此信息。
Link Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to link failure.
链路故障计数：由于链路故障，与AC的CAPWAP协议连接失败的次数。
SW Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to software-related reasons.
SW Failure Count（软件故障计数）：由于软件相关原因，与AC的CAPWAP协议连接失败的次数。
HW Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to hardware-related reasons.
HW Failure Count（硬件故障计数）：由于硬件相关原因，与AC的CAPWAP协议连接失败的次数。
Other Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed due to known reasons, other than AC initiated, link, SW or HW failure.
其他故障计数：由于已知原因（AC启动、链路、软件或硬件故障除外），与AC的CAPWAP协议连接失败的次数。
Unknown Failure Count: The number of times that a CAPWAP protocol connection with an AC has failed for unknown reasons.
未知失败计数：与AC的CAPWAP协议连接因未知原因失败的次数。
Last Failure Type: The failure type of the most recent WTP failure. The following enumerated values are supported:
上次故障类型：最近WTP故障的故障类型。支持以下枚举值：
0 - Not Supported
0-不受支持
1 - AC Initiated (see Section 9.2)
1-交流启动（见第9.2节）
2 - Link Failure
2-链路故障
3 - Software Failure
3-软件故障
4 - Hardware Failure
4-硬件故障
5 - Other Failure
5-其他故障
255 - Unknown (e.g., WTP doesn't keep track of info)
255-未知（例如，WTP不跟踪信息）
The WTP Static IP Address Information message element is used by an AC to configure or clear a previously configured static IP address on a WTP. IPv6 WTPs are expected to use dynamic addresses.
AC使用WTP静态IP地址信息消息元素来配置或清除先前在WTP上配置的静态IP地址。IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static |
+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static |
+-+-+-+-+-+-+-+-+
Type: 49 for WTP Static IP Address Information
类型：49用于WTP静态IP地址信息
Length: 13
长度：13
IP Address: The IP address to assign to the WTP. This field is only valid if the static field is set to one.
IP地址：要分配给WTP的IP地址。仅当静态字段设置为1时，此字段才有效。
Netmask: The IP Netmask. This field is only valid if the static field is set to one.
网络掩码：IP网络掩码。仅当静态字段设置为1时，此字段才有效。
Gateway: The IP address of the gateway. This field is only valid if the static field is set to one.
网关：网关的IP地址。仅当静态字段设置为1时，此字段才有效。
Static: An 8-bit Boolean stating whether or not the WTP should use a static IP address. A value of zero disables the static IP address, while a value of one enables it.
静态：一个8位布尔值，说明WTP是否应使用静态IP地址。值为零将禁用静态IP地址，而值为1将启用静态IP地址。
This section contains the definition of the CAPWAP timers.
本节包含CAPWAP定时器的定义。
The maximum time, in seconds, the AC will wait for the Change State Event Request from the WTP after having transmitted a successful Configuration Status Response message.
在传输成功的配置状态响应消息后，AC将等待来自WTP的更改状态事件请求的最长时间（以秒为单位）。
Default: 25 seconds
默认值：25秒
The DataChannelKeepAlive timer is used by the WTP to determine the next opportunity when it must transmit the Data Channel Keep-Alive, in seconds.
WTP使用DataChannelKeepAlive计时器来确定下一次必须传输数据通道保持活动的机会，以秒为单位。
Default: 30 seconds
默认值：30秒
The minimum time, in seconds, a WTP MUST wait without having received a Data Channel Keep-Alive packet before the destination for the Data Channel Keep-Alive packets may be considered dead. The value of this timer MUST be no less than 2*DataChannelKeepAlive seconds and no greater that 240 seconds.
WTP必须在没有接收到数据信道保持活动分组的情况下等待的最短时间（以秒为单位），然后数据信道保持活动分组的目的地才能被视为死亡。此计时器的值必须不小于2*DataChannelKeepAlive秒，且不大于240秒。
Default: 60
默认值：60
The number of seconds the AC will wait for the Data Channel Keep Alive, which is required by the CAPWAP state machine's Data Check state. The AC resets the state machine if this timer expires prior to transitioning to the next state.
AC等待数据通道保持活动的秒数，这是CAPWAP状态机的数据检查状态所要求的。如果此计时器在转换到下一个状态之前过期，AC将重置状态机。
Default: 30
默认值：30
The minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response message, before initiating a DTLS handshake.
WTP在接收到发现响应消息后，在启动DTLS握手之前必须等待的最短时间（秒）。
Default: 5
默认值：5
The minimum time, in seconds, a WTP MUST wait for DTLS session deletion.
WTP必须等待DTLS会话删除的最短时间（秒）。
Default: 5
默认值：5
The minimum time, in seconds, between sending Echo Request messages to the AC with which the WTP has joined.
向WTP已加入的AC发送回显请求消息之间的最短时间（秒）。
Default: 30
默认值：30
The default Idle Timeout is 300 seconds.
默认空闲超时为300秒。
The number of seconds the WTP will wait for its peer to transmit the Image Data Request.
WTP等待其对等方发送图像数据请求的秒数。
Default: 30
默认值：30
The maximum time allowed between sending Discovery Request messages, in seconds. This value MUST be no less than 2 seconds and no greater than 180 seconds.
发送发现请求消息之间允许的最长时间（秒）。该值必须不小于2秒且不大于180秒。
Default: 20 seconds.
默认值：20秒。
The ReportInterval is used by the WTP to determine the interval the WTP uses between sending the Decryption Error message elements to inform the AC of decryption errors, in seconds.
WTP使用ReportInterval来确定WTP在发送解密错误消息元素以通知AC解密错误之间使用的时间间隔（以秒为单位）。
The default Report Interval is 120 seconds.
默认报告间隔为120秒。
The minimum time, in seconds, in which a non-acknowledged CAPWAP packet will be retransmitted.
重新传输未确认的CAPWAP数据包的最短时间（秒）。
Default: 3
默认值：3
For a WTP, this is the minimum time, in seconds, a WTP MUST wait before it MAY again send Discovery Request messages or attempt to establish a DTLS session. For an AC, this is the minimum time, in seconds, during which the AC SHOULD ignore all CAPWAP and DTLS packets received from the WTP that is in the Sulking state.
对于WTP，这是WTP在再次发送发现请求消息或尝试建立DTLS会话之前必须等待的最短时间（以秒为单位）。对于AC，这是AC应忽略从WTP接收的处于生气状态的所有CAPWAP和DTLS数据包的最短时间（以秒为单位）。
Default: 30 seconds
默认值：30秒
The StatisticsTimer is used by the WTP to determine the interval the WTP uses between the WTP Events Requests it transmits to the AC to communicate its statistics, in seconds.
WTP使用StatisticsTimer来确定WTP发送给AC的WTP事件请求之间的间隔，以秒为单位传达其统计信息。
Default: 120 seconds
默认值：120秒
The maximum time, in seconds, a WTP MUST wait without having received a DTLS Handshake message from an AC. This timer MUST be greater than 30 seconds.
WTP在没有收到来自AC的DTLS握手消息的情况下必须等待的最长时间（以秒为单位）。该计时器必须大于30秒。
Default: 60
默认值：60
The maximum time, in seconds, an AC will wait after the DTLS session has been established until it receives the Join Request from the WTP. This timer MUST be greater than 20 seconds.
在DTLS会话建立之后，AC将等待的最长时间（以秒为单位），直到它接收到来自WTP的加入请求。此计时器必须大于20秒。
Default: 60
默认值：60
This section defines the CAPWAP protocol variables, which are used for various protocol functions. Some of these variables are configurable, while others are counters or have a fixed value. For non-counter-related variables, default values are specified. However, when a WTP's variable configuration is explicitly overridden by an AC, the WTP MUST save the new value.
本节定义用于各种协议功能的CAPWAP协议变量。其中一些变量是可配置的，而其他变量是计数器或具有固定值。对于非计数器相关变量，将指定默认值。但是，当AC显式覆盖WTP的变量配置时，WTP必须保存新值。
The default Administrative State value is enabled (1).
默认管理状态值已启用（1）。
The number of Discovery Request messages transmitted by a WTP to a single AC. This is a monotonically increasing counter.
WTP发送到单个AC的发现请求消息数。这是一个单调递增的计数器。
The number of failed DTLS session establishment attempts due to authentication failures.
由于身份验证失败而尝试建立DTLS会话失败的次数。
The number of failed DTLS session establishment attempts.
DTLS会话建立尝试失败的次数。
The maximum number of Discovery Request messages that will be sent after a WTP boots.
WTP引导后将发送的最大发现请求消息数。
Default: 10
默认值：10
The maximum number of failed DTLS session establishment attempts before the CAPWAP device enters a silent period.
CAPWAP设备进入静默期之前失败的DTLS会话建立尝试的最大次数。
Default: 3
默认值：3
The maximum number of retransmissions for a given CAPWAP packet before the link layer considers the peer dead.
链路层认为对等方已死亡之前，给定CAPWAP数据包的最大重传次数。
Default: 5
默认值：5
The number of retransmissions for a given CAPWAP packet. This is a monotonically increasing counter.
给定CAPWAP数据包的重新传输次数。这是一个单调递增的计数器。
The default WTP Fallback value is enabled (1).
默认WTP回退值已启用（1）。
In addition to the values defined in Section 4.8, the following values SHOULD be saved on the WTP in non-volatile memory. CAPWAP wireless bindings MAY define additional values that SHOULD be stored on the WTP.
除第4.8节中定义的值外，以下值应保存在非易失性存储器中的WTP上。CAPWAP无线绑定可定义应存储在WTP上的附加值。
The number of times the WTP has rebooted administratively, defined in Section 4.6.47.
WTP以管理方式重新启动的次数，如第4.6.47节所定义。
For WTPs that support multiple Frame Encapsulation Types, it is useful to save the value configured by the AC. The Frame Encapsulation Type is defined in Section 4.6.43.
对于支持多种帧封装类型的WTP，保存AC配置的值非常有用。第4.6.43节定义了帧封装类型。
The reason why the WTP last rebooted, defined in Section 4.6.47.
WTP上次重新启动的原因，见第4.6.47节。
For WTPs that support multiple MAC-Types, it is useful to save the value configured by the AC. The MAC-Type is defined in Section 4.6.44.
对于支持多种MAC类型的WTP，保存AC配置的值非常有用。MAC类型在第4.6.44节中定义。
The preferred ACs, with the index, defined in Section 4.6.5.
首选ACs，具有第4.6.5节中定义的索引。
The number of times the WTP has rebooted, defined in Section 4.6.47.
第4.6.47节中定义的WTP重新启动的次数。
The static IP address assigned to the WTP, as configured by the WTP Static IP address Information message element (see Section 4.6.48).
分配给WTP的静态IP地址，由WTP静态IP地址信息消息元素配置（见第4.6.48节）。
The number of times the link to the AC has failed, see Section 4.6.47.
连接至AC的链路发生故障的次数，见第4.6.47节。
The WTP Location, defined in Section 4.6.30.
第4.6.30节中定义的水处理厂位置。
The WTP Name, defined in Section 4.6.45.
第4.6.45节中定义的WTP名称。
The Discovery messages are used by a WTP to determine which ACs are available to provide service, and the capabilities and load of the ACs.
WTP使用发现消息来确定哪些ACs可提供服务，以及ACs的能力和负载。
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使用发现请求消息自动发现网络中可用的潜在ACs。发现请求消息为ACs提供了
WTP. A WTP must exchange this information to ensure subsequent exchanges with the ACs are consistent with the WTP's functional characteristics.
WTP。WTP必须交换此信息，以确保与ACs的后续交换符合WTP的功能特征。
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.
在WTP首次出现或（重新）初始化后，等待小于MaxDiscoveryInterval的随机延迟后，发现请求消息必须由处于发现状态的WTP发送。WTP发送的消息不得超过MaxDiscoverys发现请求消息的最大值，等待每个连续消息之间小于MaxDiscoveryInterval的随机延迟。
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.
这是为了防止WTP发现请求消息爆炸。发生这种情况的一个例子是多个WTP同时通电。
If a Discovery Response message is not received after sending the 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.
如果在发送最大数量的发现请求消息后未收到发现响应消息，WTP将进入生气状态，并且必须等待等于SilentInterval的间隔，然后再发送进一步的发现请求消息。
Upon receiving a Discovery Request message, the AC will respond with a Discovery Response message sent to the address in the source address of the received Discovery Request message. Once a Discovery Response has been received, if the WTP decides to establish a session with the responding AC, it SHOULD perform an MTU discovery, using the process described in Section 3.5.
在接收到发现请求消息后，AC将通过发送到接收到的发现请求消息的源地址中的地址的发现响应消息进行响应。一旦收到发现响应，如果WTP决定与响应的AC建立会话，则应使用第3.5节中描述的过程执行MTU发现。
It is possible for the AC to receive a clear text Discovery Request message while a DTLS session is already active with the WTP. This is most likely the case if the WTP has rebooted, perhaps due to a software or power failure, but could also be caused by a DoS attack. In such cases, any WTP state, including the state machine instance, MUST NOT be cleared until another DTLS session has been successfully established, communicated via the DTLSSessionEstablished DTLS notification (see Section 2.3.2.2).
当DTLS会话已与WTP激活时，AC可以接收明文发现请求消息。如果WTP已重新启动（可能是由于软件或电源故障），但也可能是由DoS攻击引起，则最有可能出现这种情况。在这种情况下，任何WTP状态（包括状态机实例）都不得清除，直到成功建立另一个DTLS会话，并通过DTLSSessionEstablished DTLS通知进行通信（见第2.3.2.2节）。
The binding specific WTP Radio Information message element (see Section 2.1) is included in the Discovery Request message to advertise WTP support for one or more CAPWAP bindings.
特定于绑定的WTP无线电信息消息元素（参见第2.1节）包含在查找请求消息中，用于公布一个或多个CAPWAP绑定的WTP支持。
The Discovery Request message is sent by the WTP when in the Discovery state. The AC does not transmit this message.
WTP在发现状态下发送发现请求消息。空调不发送此信息。
The following message elements MUST be included in the Discovery Request message:
发现请求消息中必须包含以下消息元素：
o Discovery Type, see Section 4.6.21
o 发现类型，见第4.6.21节
o WTP Board Data, see Section 4.6.40
o WTP板数据，见第4.6.40节
o WTP Descriptor, see Section 4.6.41
o WTP描述符，见第4.6.41节
o WTP Frame Tunnel Mode, see Section 4.6.43
o WTP框架隧道模式，见第4.6.43节
o WTP MAC Type, see Section 4.6.44
o WTP MAC类型，见第4.6.44节
o WTP Radio Information message element(s) that the WTP supports; These are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1).
o WTP支持的WTP无线电信息消息元素；这些由各个链路层CAPWAP绑定协议定义（参见第2.1节）。
The following message elements MAY be included in the Discovery Request message:
发现请求消息中可能包括以下消息元素：
o MTU Discovery Padding, see Section 4.6.32
o MTU发现填充，见第4.6.32节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Discovery Response message provides a mechanism for an AC to advertise its services to requesting WTPs.
发现响应消息为AC向请求的WTP公布其服务提供了一种机制。
When a WTP receives a Discovery Response message, it MUST wait for an 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.
当WTP接收到发现响应消息时，它必须等待不小于DiscoveryInterval的间隔来接收其他发现响应消息。发现间隔过后，WTP进入DTLS初始状态，并选择发送发现响应消息并向该AC发送DTLS握手的ACs之一。
One or more binding-specific WTP Radio Information message elements (see Section 2.1) are included in the Discovery Request message to advertise AC support for the CAPWAP bindings. The AC MAY include only the bindings it shares in common with the WTP, known through the WTP Radio Information message elements received in the Discovery Request message, or it MAY include all of the bindings supported. The WTP MAY use the supported bindings in its AC decision process. Note that if the WTP joins an AC that does not support a specific CAPWAP binding, service for that binding MUST NOT be provided by the WTP.
发现请求消息中包含一个或多个特定于绑定的WTP无线电信息消息元素（请参见第2.1节），以公布对CAPWAP绑定的AC支持。AC可以仅包括其与WTP共享的绑定（通过在发现请求消息中接收的WTP无线电信息消息元素知道），或者它可以包括支持的所有绑定。WTP可以在其AC决策过程中使用受支持的绑定。请注意，如果WTP加入不支持特定CAPWAP绑定的AC，则WTP不得提供该绑定的服务。
The Discovery Response message is sent by the AC when in the Idle state. The WTP does not transmit this message.
AC在空闲状态下发送发现响应消息。WTP不传输此消息。
The following message elements MUST be included in the Discovery Response Message:
发现响应消息中必须包含以下消息元素：
o AC Descriptor, see Section 4.6.1
o 交流描述符，见第4.6.1节
o AC Name, see Section 4.6.4
o AC名称，见第4.6.4节
o WTP Radio Information message element(s) that the AC supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
o AC支持的WTP无线电信息消息元素；这些由各个链路层CAPWAP绑定协议定义（有关更多信息，请参阅第2.1节）。
o One of the following message elements MUST be included in the Discovery Response Message:
o 发现响应消息中必须包含以下消息元素之一：
* CAPWAP Control IPv4 Address, see Section 4.6.9
* CAPWAP控制IPv4地址，见第4.6.9节
* CAPWAP Control IPv6 Address, see Section 4.6.10
* CAPWAP控制IPv6地址，见第4.6.10节
The following message elements MAY be included in the Discovery Response message:
发现响应消息中可能包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Primary Discovery Request message is sent by the WTP to:
主发现请求消息由WTP发送至：
o determine whether its preferred (or primary) AC is available, or
o 确定其首选（或主要）AC是否可用，或
o perform a Path MTU Discovery (see Section 3.5).
o 执行路径MTU发现（参见第3.5节）。
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. Since the WTP only has a single instance of the CAPWAP state machine, the Primary Discovery Request is sent by the WTP when in the Run state. The AC does not transmit this message.
当WTP配置了主AC时，主发现请求消息由WTP发送，并连接到另一个AC。这通常是故障切换的结果，WTP将此消息用作发现其主AC可用时的一种方法。由于WTP只有一个CAPWAP状态机实例，因此当处于运行状态时，WTP将发送主发现请求。空调不发送此信息。
The frequency of the Primary Discovery Request messages should be no more often than the sending of the Echo Request message.
主发现请求消息的频率不应超过发送回显请求消息的频率。
Upon receipt of a Primary 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.
在接收到主发现请求消息后，AC使用发送到所接收的主发现请求消息的源地址中的地址的主发现响应消息进行响应。
The following message elements MUST be included in the Primary Discovery Request message.
主发现请求消息中必须包含以下消息元素。
o Discovery Type, see Section 4.6.21
o 发现类型，见第4.6.21节
o WTP Board Data, see Section 4.6.40
o WTP板数据，见第4.6.40节
o WTP Descriptor, see Section 4.6.41
o WTP描述符，见第4.6.41节
o WTP Frame Tunnel Mode, see Section 4.6.43
o WTP框架隧道模式，见第4.6.43节
o WTP MAC Type, see Section 4.6.44
o WTP MAC类型，见第4.6.44节
o WTP Radio Information message element(s) that the WTP supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
o WTP支持的WTP无线电信息消息元素；这些由各个链路层CAPWAP绑定协议定义（有关更多信息，请参阅第2.1节）。
The following message elements MAY be included in the Primary Discovery Request message:
主发现请求消息中可能包括以下消息元素：
o MTU Discovery Padding, see Section 4.6.32
o MTU发现填充，见第4.6.32节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
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.
主发现响应消息使AC能够向请求的WTP公布其可用性和服务，这些WTP配置为将AC作为其主AC。
The Primary Discovery Response message is sent by an AC after receiving a Primary Discovery Request message.
AC在收到主发现请求消息后发送主发现响应消息。
When a WTP receives a Primary Discovery Response message, it may establish a CAPWAP protocol connection to its primary AC, based on the configuration of the WTP Fallback Status message element on the WTP.
当WTP收到主发现响应消息时，它可以基于WTP上WTP回退状态消息元素的配置，建立与其主AC的CAPWAP协议连接。
The Primary Discovery Response message is sent by the AC when in the Idle state. The WTP does not transmit this message.
AC在空闲状态下发送主发现响应消息。WTP不传输此消息。
The following message elements MUST be included in the Primary Discovery Response message.
主发现响应消息中必须包含以下消息元素。
o AC Descriptor, see Section 4.6.1
o 交流描述符，见第4.6.1节
o AC Name, see Section 4.6.4
o AC名称，见第4.6.4节
o WTP Radio Information message element(s) that the AC supports; These are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
o AC支持的WTP无线电信息消息元素；这些由各个链路层CAPWAP绑定协议定义（有关更多信息，请参阅第2.1节）。
One of the following message elements MUST be included in the Discovery Response Message:
发现响应消息中必须包含以下消息元素之一：
o CAPWAP Control IPv4 Address, see Section 4.6.9
o CAPWAP控制IPv4地址，见第4.6.9节
o CAPWAP Control IPv6 Address, see Section 4.6.10
o CAPWAP控制IPv6地址，见第4.6.10节
The following message elements MAY be included in the Primary Discovery Response message:
主发现响应消息中可能包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Join Request message is used by a WTP to request service from an AC after a DTLS connection is established to that AC. The Join Response message is used by the AC to indicate that it will or will not provide service.
在与AC建立DTLS连接后，WTP使用加入请求消息从AC请求服务。AC使用加入响应消息指示其将提供或不提供服务。
The Join Request message is used by a WTP to request service through the AC. If the WTP is performing the optional AC Discovery process (see Section 3.3), the join process occurs after the WTP has received one or more Discovery Response messages. During the Discovery process, an AC MAY return more than one CAPWAP Control IPv4 Address or CAPWAP Control IPv6 Address message elements. When more than one such message element is returned, the WTP SHOULD perform "load balancing" by choosing the interface that is servicing the least number of WTPs (known through the WTP Count field of the message element). Note, however, that other load balancing algorithms are also permitted. Once the WTP has determined its preferred AC, and its associated interface, to which to connect, it establishes the DTLS session, and transmits the Join Request over the secured control channel. When an AC receives a Join Request message it responds with a Join Response message.
WTP使用加入请求消息通过AC请求服务。如果WTP正在执行可选的AC发现过程（参见第3.3节），则加入过程在WTP收到一个或多个发现响应消息后发生。在发现过程中，AC可能返回多个CAPWAP控制IPv4地址或CAPWAP控制IPv6地址消息元素。当返回多个这样的消息元素时，WTP应该通过选择为最少数量的WTP提供服务的接口（通过消息元素的WTP计数字段知道）来执行“负载平衡”。但是，请注意，也允许使用其他负载平衡算法。一旦WTP确定了要连接的首选AC及其相关接口，它将建立DTLS会话，并通过安全控制通道传输加入请求。当AC收到加入请求消息时，它会以加入响应消息进行响应。
Upon completion of the DTLS handshake and receipt of the DTLSEstablished notification, the WTP sends the Join Request message to the AC. When the AC is notified of the DTLS session establishment, it does not clear the WaitDTLS timer until it has received the Join Request message, at which time it sends a Join Response message to the WTP, indicating success or failure.
DTLS握手完成并收到DTLSEstablished通知后，WTP向AC发送加入请求消息。当AC收到DTLS会话建立的通知时，它不会清除WaitDTLS计时器，直到它收到加入请求消息，此时它向WTP发送加入响应消息，表示成功或失败的。
One or more WTP Radio Information message elements (see Section 2.1) are included in the Join Request to request service for the CAPWAP bindings by the AC. Including a binding that is unsupported by the AC will result in a failed Join Response.
AC为CAPWAP绑定请求服务的加入请求中包含一个或多个WTP无线电信息消息元素（参见第2.1节）。包括AC不支持的绑定将导致加入响应失败。
If the AC rejects the Join Request, it sends a Join Response message with a failure indication and initiates an abort of the DTLS session via the DTLSAbort command.
如果AC拒绝加入请求，它将发送带有故障指示的加入响应消息，并通过DTLSAbort命令启动DTLS会话的中止。
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.
如果接收到无效（即格式不正确）的加入请求消息，AC必须悄悄地丢弃该消息。不会向WTP发送响应。AC应记录此事件。
The Join Request is sent by the WTP when in the Join State. The AC does not transmit this message.
连接请求在处于连接状态时由WTP发送。空调不发送此信息。
The following message elements MUST be included in the Join Request message.
加入请求消息中必须包含以下消息元素。
o Location Data, see Section 4.6.30
o 位置数据，见第4.6.30节
o WTP Board Data, see Section 4.6.40
o WTP板数据，见第4.6.40节
o WTP Descriptor, see Section 4.6.41
o WTP描述符，见第4.6.41节
o WTP Name, see Section 4.6.45
o 水处理厂名称，见第4.6.45节
o Session ID, see Section 4.6.37
o 会话ID，见第4.6.37节
o WTP Frame Tunnel Mode, see Section 4.6.43
o WTP框架隧道模式，见第4.6.43节
o WTP MAC Type, see Section 4.6.44
o WTP MAC类型，见第4.6.44节
o WTP Radio Information message element(s) that the WTP supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1 for more information).
o WTP支持的WTP无线电信息消息元素；这些由各个链路层CAPWAP绑定协议定义（有关更多信息，请参阅第2.1节）。
o ECN Support, see Section 4.6.25
o ECN支持，见第4.6.25节
At least one of the following message element MUST be included in the Join Request message.
加入请求消息中必须至少包含以下消息元素之一。
o CAPWAP Local IPv4 Address, see Section 4.6.11
o CAPWAP本地IPv4地址，见第4.6.11节
o CAPWAP Local IPv6 Address, see Section 4.6.12
o CAPWAP本地IPv6地址，见第4.6.12节
The following message element MAY be included in the Join Request message.
加入请求消息中可能包含以下消息元素。
o CAPWAP Transport Protocol, see Section 4.6.14
o CAPWAP传输协议，见第4.6.14节
o Maximum Message Length, see Section 4.6.31
o 最大消息长度，见第4.6.31节
o WTP Reboot Statistics, see Section 4.6.47
o WTP重启统计信息，见第4.6.47节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Join Response message is sent by the AC to indicate to a WTP that it is capable and willing to provide service to the WTP.
加入响应消息由AC发送，以向WTP指示其能够并且愿意向WTP提供服务。
The WTP, receiving a Join Response message, checks for success or failure. If the message indicates success, the WTP clears the WaitDTLS timer for the session and proceeds to the Configure state.
WTP接收加入响应消息，检查成功或失败。如果消息指示成功，WTP将清除会话的WaitDTLS计时器并进入配置状态。
If the WaitDTLS Timer expires prior to reception of the Join Response message, the WTP MUST terminate the handshake, deallocate session state and initiate the DTLSAbort command.
如果WaitDTLS计时器在接收到加入响应消息之前过期，则WTP必须终止握手、取消分配会话状态并启动DTLSAbort命令。
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. The WaitDTLS timer will eventually expire, and the WTP MAY (if it is so configured) attempt to join a new AC.
如果收到无效（格式错误）的连接响应消息，WTP应记录详细说明错误的信息性消息。必须以与AC无响应性相同的方式处理此错误。WaitDTLS计时器最终将过期，WTP可能（如果已配置）尝试加入新的AC。
If one of the WTP Radio Information message elements (see Section 2.1) in the Join Request message requested support for a CAPWAP binding that the AC does not support, the AC sets the Result Code message element to "Binding Not Supported".
如果加入请求消息中的一个WTP无线电信息消息元素（参见第2.1节）请求支持AC不支持的CAPWAP绑定，AC将结果代码消息元素设置为“绑定不支持”。
The AC includes the Image Identifier message element to indicate the software version it expects the WTP to run. This information is used to determine whether the WTP MUST change its currently running firmware image or download a new version (see Section 9.1.1).
AC包括图像标识符消息元素，以指示它期望WTP运行的软件版本。此信息用于确定WTP是否必须更改其当前运行的固件映像或下载新版本（请参阅第9.1.1节）。
The Join Response message is sent by the AC when in the Join State. The WTP does not transmit this message.
连接响应消息在连接状态下由AC发送。WTP不传输此消息。
The following message elements MUST be included in the Join Response message.
加入响应消息中必须包含以下消息元素。
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
o AC Descriptor, see Section 4.6.1
o 交流描述符，见第4.6.1节
o AC Name, see Section 4.6.4
o AC名称，见第4.6.4节
o WTP Radio Information message element(s) that the AC supports; these are defined by the individual link layer CAPWAP Binding Protocols (see Section 2.1).
o AC支持的WTP无线电信息消息元素；这些由各个链路层CAPWAP绑定协议定义（参见第2.1节）。
o ECN Support, see Section 4.6.25
o ECN支持，见第4.6.25节
One of the following message elements MUST be included in the Join Response Message:
加入响应消息中必须包含以下消息元素之一：
o CAPWAP Control IPv4 Address, see Section 4.6.9
o CAPWAP控制IPv4地址，见第4.6.9节
o CAPWAP Control IPv6 Address, see Section 4.6.10
o CAPWAP控制IPv6地址，见第4.6.10节
One of the following message elements MUST be included in the Join Response Message:
加入响应消息中必须包含以下消息元素之一：
o CAPWAP Local IPv4 Address, see Section 4.6.11
o CAPWAP本地IPv4地址，见第4.6.11节
o CAPWAP Local IPv6 Address, see Section 4.6.12
o CAPWAP本地IPv6地址，见第4.6.12节
The following message elements MAY be included in the Join Response message.
加入响应消息中可能包含以下消息元素。
o AC IPv4 List, see Section 4.6.2
o AC IPv4列表，见第4.6.2节
o AC IPv6 List, see Section 4.6.3
o AC IPv6列表，见第4.6.3节
o CAPWAP Transport Protocol, see Section 4.6.14
o CAPWAP传输协议，见第4.6.14节
o Image Identifier, see Section 4.6.27
o 图像标识符，见第4.6.27节
o Maximum Message Length, see Section 4.6.31
o 最大消息长度，见第4.6.31节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Control Channel Management messages are used by the WTP and AC to maintain a control communication channel. CAPWAP Control messages, such as the WTP Event Request message sent from the WTP to the AC indicate to the AC that the WTP is operational. When such control messages are not being sent, the Echo Request and Echo Response messages are used to maintain the control communication channel.
WTP和AC使用控制信道管理消息来维护控制通信信道。CAPWAP控制消息，例如从WTP发送到AC的WTP事件请求消息，向AC指示WTP正在运行。当不发送此类控制消息时，回显请求和回显响应消息用于维护控制通信信道。
The Echo Request message is a keep-alive mechanism for CAPWAP control messages.
Echo请求消息是CAPWAP控制消息的保持活动机制。
Echo Request messages are sent periodically by a WTP in the Image Data or Run state (see Section 2.3) to determine the state of the control connection between the WTP and the AC. The Echo Request message is sent by the WTP when the EchoInterval timer expires.
WTP在图像数据或运行状态下（见第2.3节）定期发送回显请求消息，以确定WTP和AC之间控制连接的状态。回显请求消息在回显间隔计时器过期时由WTP发送。
The Echo Request message is sent by the WTP when in the Run state. The AC does not transmit this message.
当WTP处于运行状态时，将发送回显请求消息。空调不发送此信息。
The following message elements MAY be included in the Echo Request message:
回送请求消息中可能包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
When an AC receives an Echo Request message it responds with an Echo Response message.
当AC收到回音请求消息时，它会以回音响应消息进行响应。
The Echo Response message acknowledges the Echo Request message.
回显响应消息确认回显请求消息。
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 EchoInterval timer (see Section 4.7.7). 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 reachable.
AC在接收回显请求消息后发送回显响应消息。在发送回声响应信息后，AC应重置其回声间隔计时器（见第4.7.7节）。如果在定时器到期时AC没有接收到另一个回声请求消息或其他控制消息，则AC应该考虑WTP不再可到达。
The Echo Response message is sent by the AC when in the Run state. The WTP does not transmit this message.
当AC处于运行状态时，会发送回显响应消息。WTP不传输此消息。
The following message elements MAY be included in the Echo Response message:
回声响应消息中可能包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
When a WTP receives an Echo Response message it initializes the EchoInterval to the configured value.
当WTP收到回音响应消息时，它会将回音间隔初始化为配置的值。
WTP Configuration messages are used to exchange configuration information between the AC and the WTP.
WTP配置消息用于在AC和WTP之间交换配置信息。
The CAPWAP protocol provides flexibility in how WTP configuration is managed. A WTP can behave in one of two ways, which is implementation specific:
CAPWAP协议在如何管理WTP配置方面提供了灵活性。WTP可以采用以下两种方式之一，这是特定于实现的：
1. The WTP retains no configuration and accepts the configuration provided by the AC.
1. WTP不保留任何配置，并接受AC提供的配置。
2. The WTP saves the configuration of parameters provided by the AC that are non-default values into local non-volatile memory, and are enforced during the WTP's power up initialization phase.
2. WTP将AC提供的非默认值参数配置保存到本地非易失性内存中，并在WTP通电初始化阶段强制执行。
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 Request message. A configuration override is a non-default parameter. As an example, 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.
如果WTP选择在本地保存配置，CAPWAP协议状态机将定义允许配置交换的配置状态。在配置状态下，WTP通过配置状态请求消息向AC发送其当前配置覆盖。配置替代是非默认参数。例如，在CAPWAP协议中，默认天线配置为内部全向天线。没有内部天线或已被AC明确配置为使用外部天线的WTP在配置阶段发送其天线配置，从而允许AC了解WTP的当前配置。
Once the WTP has provided its configuration to the AC, the AC sends its configuration to the WTP. This allows the WTP to receive configuration and policies from the AC.
一旦WTP向AC提供了其配置，AC将其配置发送给WTP。这允许WTP从AC接收配置和策略。
The AC maintains a copy of each active WTP configuration. There is no need for versioning or other means to identify configuration changes. If a WTP becomes inactive, the AC MAY delete the inactive WTP configuration. If a WTP fails, and connects to a new AC, the WTP provides its overridden configuration parameters, allowing the new AC to be aware of the WTP configuration.
AC维护每个活动WTP配置的副本。不需要版本控制或其他方法来识别配置更改。如果WTP变为非活动状态，AC可删除非活动WTP配置。如果WTP发生故障并连接到新的AC，WTP将提供其覆盖的配置参数，使新AC能够了解WTP配置。
This model allows for resiliency in case of an AC failure, ensuring another AC can provide service to the WTP. A new AC would be automatically updated with WTP configuration changes, eliminating the need for inter-AC communication and the need for all ACs to be aware of the configuration of all WTPs in the network.
该模型允许在AC故障情况下恢复，确保另一个AC可以向WTP提供服务。新的AC将随着WTP配置的更改而自动更新，从而消除AC间通信的需要以及所有AC了解网络中所有WTP配置的需要。
Once the CAPWAP protocol enters the Run state, the WTPs begin to provide service. It is 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.
一旦CAPWAP协议进入运行状态，WTP就开始提供服务。管理员通常要求在网络运行时更改配置。因此，AC向WTP发送配置更新请求，以便在运行时进行这些更改。
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
CAPWAP协议提供了配置和管理具有不同设计和功能特征的WTP的灵活性。当WTP首次发现AC时，它提供主要功能信息
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 state for the WTP.
与MAC的类型和要交换的帧的性质有关。AC适当地配置WTP。AC还为WTP建立相应的内部状态。
The Configuration Status Request message is sent by a WTP to deliver its current configuration to the AC.
配置状态请求消息由WTP发送，以将其当前配置传递给AC。
The Configuration Status Request message carries binding-specific message elements. Refer to the appropriate binding for the definition of this structure.
配置状态请求消息包含绑定特定的消息元素。有关此结构的定义，请参阅相应的绑定。
When an AC receives a Configuration Status Request message, it acts upon the content of the message and responds to the WTP with a Configuration Status Response message.
当AC接收到配置状态请求消息时，它根据消息的内容采取行动，并使用配置状态响应消息响应WTP。
The Configuration Status Request message includes multiple Radio Administrative State message elements, one for the WTP, and one for each radio in the WTP.
配置状态请求消息包括多个无线电管理状态消息元素，一个用于WTP，另一个用于WTP中的每个无线电。
The Configuration Status Request message is sent by the WTP when in the Configure State. The AC does not transmit this message.
配置状态请求消息在处于配置状态时由WTP发送。空调不发送此信息。
The following message elements MUST be included in the Configuration Status Request message.
配置状态请求消息中必须包含以下消息元素。
o AC Name, see Section 4.6.4
o AC名称，见第4.6.4节
o Radio Administrative State, see Section 4.6.33
o 无线电管理状态，见第4.6.33节
o Statistics Timer, see Section 4.6.38
o 统计计时器，见第4.6.38节
o WTP Reboot Statistics, see Section 4.6.47
o WTP重启统计信息，见第4.6.47节
The following message elements MAY be included in the Configuration Status Request message.
配置状态请求消息中可能包含以下消息元素。
o AC Name with Priority, see Section 4.6.5
o 具有优先权的AC名称，见第4.6.5节
o CAPWAP Transport Protocol, see Section 4.6.14
o CAPWAP传输协议，见第4.6.14节
o WTP Static IP Address Information, see Section 4.6.48
o WTP静态IP地址信息，见第4.6.48节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Configuration Status Response message is sent by an AC and provides a mechanism for the AC to override a WTP's requested configuration.
配置状态响应消息由AC发送，并为AC提供覆盖WTP请求的配置的机制。
A Configuration Status Response message is sent by an AC after receiving a Configuration Status Request message.
AC在收到配置状态请求消息后发送配置状态响应消息。
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 Radio Operational State message element that causes a change in the operational state of one of the radios, the WTP transmits a Change State Event to the AC, as an acknowledgement of the change in state.
当WTP收到配置状态响应消息时，它会根据消息的内容（视情况而定）进行操作。如果配置状态响应消息包括导致其中一个无线电的操作状态改变的无线电操作状态消息元素，则WTP向AC发送改变状态事件，作为对状态改变的确认。
The Configuration Status Response message is sent by the AC when in the Configure state. The WTP does not transmit this message.
配置状态响应消息由AC在配置状态下发送。WTP不传输此消息。
The following message elements MUST be included in the Configuration Status Response message.
配置状态响应消息中必须包含以下消息元素。
o CAPWAP Timers, see Section 4.6.13
o CAPWAP定时器，见第4.6.13节
o Decryption Error Report Period, see Section 4.6.18
o 解密错误报告期，见第4.6.18节
o Idle Timeout, see Section 4.6.24
o 空闲超时，见第4.6.24节
o WTP Fallback, see Section 4.6.42
o WTP回退，见第4.6.42节
One or both of the following message elements MUST be included in the Configuration Status Response message:
配置状态响应消息中必须包含以下一个或两个消息元素：
o AC IPv4 List, see Section 4.6.2
o AC IPv4列表，见第4.6.2节
o AC IPv6 List, see Section 4.6.3
o AC IPv6列表，见第4.6.3节
The following message element MAY be included in the Configuration Status Response message.
配置状态响应消息中可能包含以下消息元素。
o WTP Static IP Address Information, see Section 4.6.48
o WTP静态IP地址信息，见第4.6.48节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
Configuration 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.
AC在运行状态下发送配置更新请求消息，以提供WTP。这用于在WTP运行时修改其配置。
When a WTP receives a Configuration Update Request message, it responds with a Configuration Update Response message, with a Result Code message element indicating the result of the configuration request.
当WTP收到配置更新请求消息时，它用配置更新响应消息进行响应，结果代码消息元素指示配置请求的结果。
The AC includes the Image Identifier message element (see Section 4.6.27) to force the WTP to update its firmware while in the Run state. The WTP MAY proceed to download the requested firmware if it determines the version specified in the Image Identifier message element is not in its non-volatile storage by transmitting an Image Data Request (see Section 9.1.1) that includes the Initiate Download message element (see Section 4.6.29).
AC包括图像标识符消息元素（见第4.6.27节），以强制WTP在运行状态下更新其固件。如果WTP通过发送包含启动下载消息元素（参见第4.6.29节）的图像数据请求（参见第9.1.1节）确定图像标识符消息元素中指定的版本不在其非易失性存储器中，则WTP可以继续下载请求的固件。
The Configuration Update Request is sent by the AC when in the Run state. The WTP does not transmit this message.
AC在运行状态下发送配置更新请求。WTP不传输此消息。
One or more of the following message elements MAY be included in the Configuration Update message:
配置更新消息中可能包括以下一个或多个消息元素：
o AC Name with Priority, see Section 4.6.5
o 具有优先权的AC名称，见第4.6.5节
o AC Timestamp, see Section 4.6.6
o AC时间戳，见第4.6.6节
o Add MAC ACL Entry, see Section 4.6.7
o 添加MAC ACL条目，见第4.6.7节
o CAPWAP Timers, see Section 4.6.13
o CAPWAP定时器，见第4.6.13节
o Decryption Error Report Period, see Section 4.6.18
o 解密错误报告期，见第4.6.18节
o Delete MAC ACL Entry, see Section 4.6.19
o 删除MAC ACL条目，见第4.6.19节
o Idle Timeout, see Section 4.6.24
o 空闲超时，见第4.6.24节
o Location Data, see Section 4.6.30
o 位置数据，见第4.6.30节
o Radio Administrative State, see Section 4.6.33
o 无线电管理状态，见第4.6.33节
o Statistics Timer, see Section 4.6.38
o 统计计时器，见第4.6.38节
o WTP Fallback, see Section 4.6.42
o WTP回退，见第4.6.42节
o WTP Name, see Section 4.6.45
o 水处理厂名称，见第4.6.45节
o WTP Static IP Address Information, see Section 4.6.48
o WTP静态IP地址信息，见第4.6.48节
o Image Identifier, see Section 4.6.27
o 图像标识符，见第4.6.27节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Configuration Update Response message is the acknowledgement message for the Configuration Update Request message.
配置更新响应消息是配置更新请求消息的确认消息。
The Configuration Update Response message is sent by a WTP after receiving a Configuration Update Request message.
配置更新响应消息由WTP在接收到配置更新请求消息后发送。
When an AC receives a Configuration Update Response message, the result code indicates if the WTP successfully accepted the configuration.
当AC收到配置更新响应消息时，结果代码指示WTP是否成功接受配置。
The Configuration Update Response message is sent by the WTP when in the Run state. The AC does not transmit this message.
WTP在运行状态下发送配置更新响应消息。空调不发送此信息。
The following message element MUST be present in the Configuration Update message.
配置更新消息中必须存在以下消息元素。
Result Code, see Section 4.6.35
结果代码，见第4.6.35节
The following message elements MAY be present in the Configuration Update Response message.
配置更新响应消息中可能存在以下消息元素。
o Radio Operational State, see Section 4.6.34
o 无线电工作状态，见第4.6.34节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Change State Event Request message is used by the WTP for two main purposes:
WTP将更改状态事件请求消息用于两个主要目的：
o When sent by the WTP following the reception of a Configuration Status Response message from the AC, the WTP uses the Change State Event Request message to provide an update on the WTP radio's operational state and to confirm that the configuration provided by the AC was successfully applied.
o 当WTP在收到来自AC的配置状态响应消息后发送时，WTP使用更改状态事件请求消息提供WTP无线电操作状态的更新，并确认AC提供的配置已成功应用。
o When sent during the Run state, the WTP uses the Change State Event Request message to notify the AC of an unexpected change in the WTP's radio operational state.
o 在运行状态期间发送时，WTP使用更改状态事件请求消息通知AC WTP无线电操作状态的意外更改。
When an AC receives a Change State Event Request message it responds with a Change State Event Response message and modifies its data structures for the WTP as needed. The AC MAY decide not to provide service to the WTP if it receives an error, based on local policy, and to transition to the Reset state.
当AC收到变更状态事件请求消息时，它会使用变更状态事件响应消息进行响应，并根据需要修改WTP的数据结构。如果AC收到错误，则AC可根据本地策略决定不向WTP提供服务，并转换到重置状态。
The Change State Event Request message is sent by a WTP to acknowledge or report an error condition to the AC for a requested configuration in the Configuration Status Response message. The Change State Event Request message includes the Result Code message element, which indicates whether the configuration was successfully applied. If the WTP is unable to apply a specific configuration request, it indicates the failure by including one or more Returned Message Element message elements (see Section 4.6.36).
变更状态事件请求消息由WTP发送，以确认或向AC报告配置状态响应消息中请求配置的错误情况。更改状态事件请求消息包含结果代码消息元素，该元素指示配置是否已成功应用。如果WTP无法应用特定的配置请求，则通过包含一个或多个返回的消息元素（参见第4.6.36节）来指示故障。
The Change State Event Request message is sent by the WTP in the Configure or Run state. The AC does not transmit this message.
更改状态事件请求消息由WTP在配置或运行状态下发送。空调不发送此信息。
The WTP MAY save its configuration to persistent storage prior to transmitting the response. However, this is implementation specific and is not required.
WTP可以在发送响应之前将其配置保存到持久存储器。但是，这是特定于实现的，不是必需的。
The following message elements MUST be present in the Change State Event Request message.
更改状态事件请求消息中必须存在以下消息元素。
o Radio Operational State, see Section 4.6.34
o 无线电工作状态，见第4.6.34节
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
One or more of the following message elements MAY be present in the Change State Event Request message:
更改状态事件请求消息中可能存在以下一个或多个消息元素：
o Returned Message Element(s), see Section 4.6.36
o 返回的消息元素，见第4.6.36节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Change State Event Response message acknowledges the Change State Event Request message.
变更状态事件响应消息确认变更状态事件请求消息。
A Change State Event Response message is sent by an AC in response to a Change State Event Request message.
变更状态事件响应消息由AC发送，以响应变更状态事件请求消息。
The Change State Event Response message is sent by the AC when in the Configure or Run state. The WTP does not transmit this message.
处于配置或运行状态时，AC将发送更改状态事件响应消息。WTP不传输此消息。
The following message element MAY be included in the Change State Event Response message:
更改状态事件响应消息中可能包含以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The WTP does not take any action upon receipt of the Change State Event Response message.
WTP在收到变更状态事件响应消息后不采取任何行动。
The Clear Configuration Request message is used to reset the WTP configuration.
清除配置请求消息用于重置WTP配置。
The Clear Configuration Request message is sent by an AC to request that a WTP reset its configuration to the manufacturing default configuration. The Clear Config Request message is sent while in the Run state.
清除配置请求消息由AC发送，请求WTP将其配置重置为制造默认配置。清除配置请求消息在处于运行状态时发送。
The Clear Configuration Request is sent by the AC when in the Run state. The WTP does not transmit this message.
在运行状态下，AC发送清除配置请求。WTP不传输此消息。
The following message element MAY be included in the Clear Configuration Request message:
清除配置请求消息中可能包含以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
When a WTP receives a Clear Configuration Request message, it resets its configuration to the manufacturing default configuration.
当WTP收到清除配置请求消息时，它将其配置重置为制造默认配置。
The Clear Configuration Response message is sent by the WTP after receiving a Clear Configuration Request message and resetting its configuration parameters to the manufacturing default values.
在接收到清除配置请求消息并将其配置参数重置为制造默认值后，WTP发送清除配置响应消息。
The Clear Configuration Response is sent by the WTP when in the Run state. The AC does not transmit this message.
处于运行状态时，WTP将发送清除配置响应。空调不发送此信息。
The Clear Configuration Response message MUST include the following message element:
清除配置响应消息必须包括以下消息元素：
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
The following message element MAY be included in the Clear Configuration Request message:
清除配置请求消息中可能包含以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
This section defines CAPWAP operations responsible for debugging, gathering statistics, logging, and firmware management. The management operations defined in this section are used by the AC to either push/pull information to/from the WTP, or request that the WTP reboot. This section does not deal with the management of the AC per se, and assumes that the AC is operational and configured.
本节定义了负责调试、收集统计信息、日志记录和固件管理的CAPWAP操作。AC使用本节中定义的管理操作向WTP推送/从WTP拉取信息，或请求WTP重新启动。本节不涉及空调本身的管理，并假设空调可以运行和配置。
This section describes the firmware download procedures used by the CAPWAP protocol. Firmware download can occur during the Image Data or Run state. The former allows the download to occur at boot time, while the latter is used to trigger the download while an active CAPWAP session exists. It is important to note that the CAPWAP protocol does not provide the ability for the AC to identify whether the firmware information provided by the WTP is correct or whether the WTP is properly storing the firmware (see Section 12.10 for more information).
本节介绍CAPWAP协议使用的固件下载过程。固件下载可在映像数据或运行状态期间进行。前者允许在启动时进行下载，而后者用于在活动CAPWAP会话存在时触发下载。需要注意的是，CAPWAP协议不提供AC识别WTP提供的固件信息是否正确或WTP是否正确存储固件的能力（有关更多信息，请参阅第12.10节）。
Figure 6 provides an example of a WTP that performs a firmware upgrade while in the Image Data state. In this example, the WTP does not already have the requested firmware (Image Identifier = x), and downloads the image from the AC.
图6提供了在映像数据状态下执行固件升级的WTP示例。在此示例中，WTP尚未具有请求的固件（映像标识符=x），并从AC下载映像。
WTP AC
水处理厂空调
Join Request
-------------------------------------------------------->
Join Request
-------------------------------------------------------->
Join Response (Image Identifier = x)
<------------------------------------------------------
Join Response (Image Identifier = x)
<------------------------------------------------------
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
Image Data Request (Image Data = Data)
<------------------------------------------------------
Image Data Request (Image Data = Data)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
Image Data Response (Result Code = Success)
-------------------------------------------------------->
.....
.....
Image Data Request (Image Data = EOF)
<------------------------------------------------------
Image Data Request (Image Data = EOF)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
Image Data Response (Result Code = Success)
-------------------------------------------------------->
(WTP enters the Reset State)
（WTP进入重置状态）
Figure 6: WTP Firmware Download Case 1
Figure 6: WTP Firmware Download Case 1translate error, please retry
Figure 7 provides an example in which the WTP has the image specified by the AC in its non-volatile storage, but is not its current running image. In this case, the WTP opts to NOT download the firmware and immediately reset to the requested image.
图7提供了一个示例，其中WTP在其非易失性存储器中具有AC指定的映像，但不是其当前运行的映像。在这种情况下，WTP选择不下载固件，并立即重置为请求的映像。
WTP AC
水处理厂空调
Join Request
-------------------------------------------------------->
Join Request
-------------------------------------------------------->
Join Response (Image Identifier = x)
<------------------------------------------------------
Join Response (Image Identifier = x)
<------------------------------------------------------
(WTP enters the Reset State)
（WTP进入重置状态）
Figure 7: WTP Firmware Download Case 2
图7:WTP固件下载案例2
Figure 8 provides an example of a WTP that performs a firmware upgrade while in the Run state. This mode of firmware upgrade allows the WTP to download its image while continuing to provide service. The WTP will not automatically reset until it is notified by the AC, with a Reset Request message.
图8提供了在运行状态下执行固件升级的WTP示例。这种固件升级模式允许WTP在继续提供服务的同时下载其映像。WTP将不会自动重置，直到AC发出重置请求消息通知。
WTP AC
水处理厂空调
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Response (Result Code = Success)
-------------------------------------------------------->
Configuration Update Response (Result Code = Success)
-------------------------------------------------------->
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Request (Image Identifier = x,
Initiate Download)
-------------------------------------------------------->
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
Image Data Response (Result Code = Success,
Image Information = {size,hash})
<------------------------------------------------------
Image Data Request (Image Data = Data)
<------------------------------------------------------
Image Data Request (Image Data = Data)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
Image Data Response (Result Code = Success)
-------------------------------------------------------->
.....
.....
Image Data Request (Image Data = EOF)
<------------------------------------------------------
Image Data Request (Image Data = EOF)
<------------------------------------------------------
Image Data Response (Result Code = Success)
-------------------------------------------------------->
Image Data Response (Result Code = Success)
-------------------------------------------------------->
.....
.....
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
Reset Response (Result Code = Success)
-------------------------------------------------------->
Reset Response (Result Code = Success)
-------------------------------------------------------->
Figure 8: WTP Firmware Download Case 3
图8:WTP固件下载案例3
Figure 9 provides another example of the firmware download while in the Run state. In this example, the WTP already has the image specified by the AC in its non-volatile storage. The WTP opts to NOT download the firmware. The WTP resets upon receipt of a Reset Request message from the AC.
图9提供了处于运行状态时固件下载的另一个示例。在此示例中，WTP在其非易失性存储器中已经具有AC指定的映像。WTP选择不下载固件。WTP在收到来自AC的重置请求消息后重置。
WTP AC
水处理厂空调
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Request (Image Identifier = x)
<------------------------------------------------------
Configuration Update Response (Result Code = Already Have Image)
-------------------------------------------------------->
Configuration Update Response (Result Code = Already Have Image)
-------------------------------------------------------->
.....
.....
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
(administratively requested reboot request)
Reset Request (Image Identifier = x)
<------------------------------------------------------
Reset Response (Result Code = Success)
-------------------------------------------------------->
Reset Response (Result Code = Success)
-------------------------------------------------------->
Figure 9: WTP Firmware Download Case 4
图9:WTP固件下载案例4
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 ensure that the image being run on each WTP is appropriate.
图像数据请求消息用于更新WTP上的固件。AC使用此消息及其伴随响应消息来确保在每个WTP上运行的映像是适当的。
Image Data Request messages are exchanged between the WTP and the AC to download a new firmware image to the WTP. When a WTP or AC receives an Image Data Request message, it responds with an Image Data Response message. The message elements contained within the Image Data Request message are required to determine the intent of the request.
图像数据请求消息在WTP和AC之间交换，以将新固件图像下载到WTP。当WTP或AC收到图像数据请求消息时，它会以图像数据响应消息进行响应。需要包含在图像数据请求消息中的消息元素来确定请求的意图。
The decision that new firmware is to be downloaded to the WTP can occur in one of two ways:
将新固件下载到WTP的决定可以通过以下两种方式之一进行：
When the WTP joins the AC, the Join Response message includes the Image Identifier message element, which informs the WTP of the firmware it is expected to run. If the WTP does not currently have the requested firmware version, it transmits an Image Data Request message, with the appropriate Image Identifier message element. If the WTP already has the requested firmware in its non-volatile flash, but is not its currently running image, it simply resets to run the proper firmware.
当WTP加入AC时，加入响应消息包括图像标识符消息元素，该元素通知WTP其预期运行的固件。如果WTP当前没有请求的固件版本，它将发送一条带有适当图像标识符消息元素的图像数据请求消息。如果WTP在其非易失性闪存中已具有请求的固件，但不是其当前运行的映像，则它将简单地重置以运行正确的固件。
Once the WTP is in the Run state, it is possible for the AC to cause the WTP to initiate a firmware download by sending a Configuration Update Request message with the Image Identifier message elements. This will cause the WTP to transmit an Image
一旦WTP处于运行状态，AC就可以通过发送带有映像标识符消息元素的配置更新请求消息，使WTP启动固件下载。这将导致WTP传输图像
Data Request with the Image Identifier and the Initiate Download message elements. Note that when the firmware is downloaded in this way, the WTP does not automatically reset after the download is complete. The WTP will only reset when it receives a Reset Request message from the AC. If the WTP already had the requested firmware version in its non-volatile storage, the WTP does not transmit the Image Data Request message and responds with a Configuration Update Response message with the Result Code set to Image Already Present.
带有图像标识符和启动下载消息元素的数据请求。请注意，以这种方式下载固件时，下载完成后WTP不会自动重置。WTP仅在接收到来自AC的重置请求消息时才会重置。如果WTP的非易失性存储器中已存在请求的固件版本，则WTP不会发送图像数据请求消息，并使用配置更新响应消息进行响应，结果代码设置为图像已存在。
Regardless of how the download was initiated, once the AC receives an Image Data Request message with the Image Identifier message element, it begins the transfer process by transmitting an Image Data Request message that includes the Image Data message element. This continues until the firmware image has been transferred.
无论下载是如何启动的，一旦AC接收到具有图像标识符消息元素的图像数据请求消息，它通过发送包括图像数据消息元素的图像数据请求消息来开始传输过程。这将一直持续到固件映像已传输。
The Image Data Request message is sent by the WTP or the AC when in the Image Data or Run state.
图像数据请求消息在图像数据或运行状态下由WTP或AC发送。
The following message elements MAY be included in the Image Data Request message:
图像数据请求消息中可以包括以下消息元素：
o CAPWAP Transport Protocol, see Section 4.6.14
o CAPWAP传输协议，见第4.6.14节
o Image Data, see Section 4.6.26
o 图像数据，见第4.6.26节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The following message elements MAY be included in the Image Data Request message when sent by the WTP:
当由WTP发送时，图像数据请求消息中可包括以下消息元素：
o Image Identifier, see Section 4.6.27
o 图像标识符，见第4.6.27节
o Initiate Download, see Section 4.6.29
o 启动下载，见第4.6.29节
The Image Data Response message acknowledges the Image Data Request message.
图像数据响应消息确认图像数据请求消息。
An Image Data Response message is sent in response to a received Image Data Request message. Its purpose is to acknowledge the receipt of the Image Data Request message. The Result Code is included to indicate whether a previously sent Image Data Request message was invalid.
响应于接收到的图像数据请求消息，发送图像数据响应消息。其目的是确认图像数据请求消息的接收。包含结果代码以指示先前发送的图像数据请求消息是否无效。
The Image Data Response message is sent by the WTP or the AC when in the Image Data or Run state.
图像数据响应消息在图像数据或运行状态下由WTP或AC发送。
The following message element MUST be included in the Image Data Response message:
图像数据响应消息中必须包含以下消息元素：
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
The following message element MAY be included in the Image Data Response message:
图像数据响应消息中可以包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o Vendor Specific Payload, see Section 4.6.39translate error, please retry
The following message element MAY be included in the Image Data Response message when sent by the AC:
当AC发送时，图像数据响应消息中可能包括以下消息元素：
o Image Information, see Section 4.6.28
o 图像信息，见第4.6.28节
Upon receiving an Image Data Response message indicating an error, the WTP MAY retransmit a previous Image Data Request message, or abandon the firmware download to the WTP by transitioning to the Reset state.
在接收到指示错误的图像数据响应消息时，WTP可以重新传输先前的图像数据请求消息，或者通过转换到重置状态来放弃固件下载到WTP。
The Reset Request message is used to cause a WTP to reboot.
重置请求消息用于使WTP重新启动。
A Reset Request message is sent by an AC to cause a WTP to reinitialize its operation. If the AC includes the Image Identifier message element (see Section 4.6.27), it indicates to the WTP that it SHOULD use that version of software upon reboot.
AC发送重置请求消息，以使WTP重新初始化其操作。如果AC包含图像标识符消息元素（参见第4.6.27节），则它向WTP指示在重新启动时应使用该版本的软件。
The Reset Request is sent by the AC when in the Run state. The WTP does not transmit this message.
在运行状态下，重置请求由AC发送。WTP不传输此消息。
The following message element MUST be included in the Reset Request message:
重置请求消息中必须包含以下消息元素：
o Image Identifier, see Section 4.6.27
o 图像标识符，见第4.6.27节
The following message element MAY be included in the Reset Request message:
重置请求消息中可能包含以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
When a WTP receives a Reset Request message, it responds with a Reset Response message indicating success and then reinitializes itself. If the WTP is unable to write to its non-volatile storage, to ensure that it runs the requested software version indicated in the Image Identifier message element, it MAY send the appropriate Result Code message element, but MUST reboot. If the WTP is unable to reset,
当WTP收到重置请求消息时，它会用指示成功的重置响应消息进行响应，然后重新初始化自身。如果WTP无法写入其非易失性存储器，为确保其运行映像标识符消息元素中指示的请求软件版本，它可以发送相应的结果代码消息元素，但必须重新启动。如果WTP无法重置，
including a hardware reset, it sends a Reset Response message to the AC with a Result Code message element indicating failure. The AC no longer provides service to the WTP.
包括硬件重置，它向AC发送重置响应消息，结果代码消息元素指示故障。AC不再向WTP提供服务。
The Reset Response message acknowledges the Reset Request message.
重置响应消息确认重置请求消息。
A Reset Response message is sent by the WTP after receiving a Reset Request message.
WTP在收到重置请求消息后发送重置响应消息。
The Reset Response is sent by the WTP when in the Run state. The AC does not transmit this message.
WTP在运行状态下发送重置响应。空调不发送此信息。
The following message elements MAY be included in the Reset Response message.
重置响应消息中可能包括以下消息元素。
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
When an AC receives a successful Reset Response message, it is notified that the WTP will reinitialize its operation. An AC that receives a Reset Response message indicating failure may opt to no longer provide service to the WTP.
当AC收到成功重置响应消息时，将通知WTP将重新初始化其操作。接收到指示故障的重置响应消息的AC可选择不再向WTP提供服务。
The 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 in response to an asynchronous event on the WTP. For example, a WTP MAY collect statistics and use the WTP Event Request message to transmit the statistics to the AC.
WTP事件请求消息由WTP用于向其AC发送信息。WTP事件请求消息可定期发送，或响应WTP上的异步事件而发送。例如，WTP可以收集统计信息并使用WTP事件请求消息将统计信息发送给AC。
When an AC receives a WTP Event Request message it will respond with a WTP Event Response message.
当AC收到WTP事件请求消息时，它将使用WTP事件响应消息进行响应。
The presence of the Delete Station message element is used by the WTP to inform the AC that it is no longer providing service to the station. This could be the result of an Idle Timeout (see Section 4.6.24), due to resource shortages, or some other reason.
WTP使用删除站点消息元素的存在来通知AC它不再向站点提供服务。这可能是由于资源短缺或其他原因导致的空闲超时（见第4.6.24节）。
The WTP Event Request message is sent by the WTP when in the Run state. The AC does not transmit this message.
WTP事件请求消息在处于运行状态时由WTP发送。空调不发送此信息。
The WTP Event Request message MUST contain one of the message elements listed below, or a message element that is defined for a specific wireless technology. More than one of each message element listed MAY be included in the WTP Event Request message.
WTP事件请求消息必须包含下列消息元素之一，或为特定无线技术定义的消息元素。WTP事件请求消息中可能包含列出的每个消息元素中的一个以上。
o Decryption Error Report, see Section 4.6.17
o 解密错误报告，见第4.6.17节
o Duplicate IPv4 Address, see Section 4.6.22
o 重复的IPv4地址，请参见第4.6.22节
o Duplicate IPv6 Address, see Section 4.6.23
o 重复的IPv6地址，请参见第4.6.23节
o WTP Radio Statistics, see Section 4.6.46
o WTP无线电统计，见第4.6.46节
o WTP Reboot Statistics, see Section 4.6.47
o WTP重启统计信息，见第4.6.47节
o Delete Station, see Section 4.6.20
o 删除车站，见第4.6.20节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The WTP Event Response message acknowledges receipt of the WTP Event Request message.
WTP事件响应消息确认收到WTP事件请求消息。
A WTP Event Response message is sent by an AC after receiving a WTP Event Request message.
AC在收到WTP事件请求消息后发送WTP事件响应消息。
The WTP Event Response message is sent by the AC when in the Run state. The WTP does not transmit this message.
处于运行状态时，AC发送WTP事件响应消息。WTP不传输此消息。
The following message element MAY be included in the WTP Event Response message:
WTP事件响应消息中可能包含以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
This section describes the data transfer procedures used by the CAPWAP protocol. The data transfer mechanism is used to upload information available at the WTP to the AC, such as crash or debug information. The data transfer messages can only be exchanged while in the Run state.
本节介绍CAPWAP协议使用的数据传输过程。数据传输机制用于将WTP上可用的信息上载到AC，例如崩溃或调试信息。数据传输消息只能在运行状态下交换。
Figure 10 provides an example of an AC that requests that the WTP transfer its latest crash file. Once the WTP acknowledges that it has information to send, via the Data Transfer Response, it transmits its own Data Transfer Request. Upon receipt, the AC responds with a
图10提供了一个AC请求WTP传输其最新崩溃文件的示例。一旦WTP确认其具有通过数据传输响应发送的信息，它将发送其自己的数据传输请求。收到后，AC会发出一个响应
Data Transfer Response, and the exchange continues until the WTP transmits a Data Transfer Data message element that indicates an End of File (EOF).
数据传输响应，交换将继续，直到WTP传输指示文件结束（EOF）的数据传输数据消息元素。
WTP AC
水处理厂空调
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Response (Result Code = Success)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
-------------------------------------------------------->
Data Transfer Request (Data Transfer Data = Data)
-------------------------------------------------------->
Data Transfer Request (Data Transfer Data = Data)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
.....
.....
Data Transfer Request (Data Transfer Data = EOF)
-------------------------------------------------------->
Data Transfer Request (Data Transfer Data = EOF)
-------------------------------------------------------->
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
Data Transfer Response (Result Code = Success)
<------------------------------------------------------
Figure 10: WTP Data Transfer Case 1
图10:WTP数据传输案例1
Figure 11 provides an example of an AC that requests that the WTP transfer its latest crash file. However, in this example, the WTP does not have any crash information to send, and therefore sends a Data Transfer Response with a Result Code indicating the error.
图11提供了一个AC请求WTP传输其最新崩溃文件的示例。但是，在此示例中，WTP没有任何要发送的崩溃信息，因此发送数据传输响应，结果代码指示错误。
WTP AC
水处理厂空调
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Request (Data Transfer Mode = Crash Data)
<------------------------------------------------------
Data Transfer Response (Result Code = Data Transfer
Error (No Information to Transfer))
-------------------------------------------------------->
Data Transfer Response (Result Code = Data Transfer
Error (No Information to Transfer))
-------------------------------------------------------->
Figure 11: WTP Data Transfer Case 2
图11:WTP数据传输案例2
The Data Transfer Request message is used to deliver debug information from the WTP to the AC.
数据传输请求消息用于将调试信息从WTP传送到AC。
The Data Transfer Request messages can be sent either by the AC or the WTP. When sent by the AC, it is used to request that data be transmitted from the WTP to the AC, and includes the Data Transfer Mode message element, which specifies the information desired by the AC. The Data Transfer Request is sent by the WTP in order to transfer actual data to the AC, through the Data Transfer Data message element.
数据传输请求消息可由AC或WTP发送。当由AC发送时，它用于请求将数据从WTP传输到AC，并包括数据传输模式消息元素，该元素指定AC所需的信息。数据传输请求由WTP发送，以便通过数据传输数据消息元素将实际数据传输到AC。
Given that the CAPWAP protocol minimizes the need for WTPs to be directly managed, the Data Transfer Request is an important troubleshooting tool used by the AC to retrieve information that may be available on the WTP. For instance, some WTP implementations may store crash information to help manufacturers identify software faults. The Data Transfer Request message can be used to send such information from the WTP to the AC. Another possible use would be to allow a remote debugger function in the WTP to use the Data Transfer Request message to send console output to the AC for debugging purposes.
鉴于CAPWAP协议最大限度地减少了直接管理WTP的需要，数据传输请求是AC用于检索WTP上可用信息的重要故障排除工具。例如，一些WTP实现可能存储崩溃信息，以帮助制造商识别软件故障。数据传输请求消息可用于将此类信息从WTP发送至AC。另一种可能的用途是允许WTP中的远程调试器功能使用数据传输请求消息将控制台输出发送至AC以进行调试。
When the WTP or AC receives a Data Transfer Request message, it responds to the WTP with a Data Transfer Response message. The AC MAY log the information received through the Data Transfer Data message element.
当WTP或AC接收到数据传输请求消息时，它使用数据传输响应消息响应WTP。AC可以记录通过数据传输数据消息元素接收到的信息。
The Data Transfer Request message is sent by the WTP or AC when in the Run state.
数据传输请求消息在运行状态下由WTP或AC发送。
When sent by the AC, the Data Transfer Request message MUST contain the following message element:
由AC发送时，数据传输请求消息必须包含以下消息元素：
o Data Transfer Mode, see Section 4.6.16
o 数据传输模式，见第4.6.16节
When sent by the WTP, the Data Transfer Request message MUST contain the following message element:
由WTP发送时，数据传输请求消息必须包含以下消息元素：
o Data Transfer Data, see Section 4.6.15
o 数据传输数据，见第4.6.15节
Regardless of whether the Data Transfer Request is sent by the AC or WTP, the following message element MAY be included in the Data Transfer Request message:
无论数据传输请求是由AC还是WTP发送，数据传输请求消息中可能包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Data Transfer Response message acknowledges the Data Transfer Request message.
数据传输响应消息确认数据传输请求消息。
A Data Transfer Response message is sent in response to a received Data Transfer Request message. Its purpose is to acknowledge receipt of the Data Transfer Request message. When sent by the WTP, the Result Code message element is used to indicate whether the data transfer requested by the AC can be completed. When sent by the AC, the Result Code message element is used to indicate receipt of the data transferred in the Data Transfer Request message.
发送数据传输响应消息以响应接收到的数据传输请求消息。其目的是确认收到数据传输请求消息。当由WTP发送时，结果代码消息元素用于指示AC请求的数据传输是否可以完成。当AC发送时，结果代码消息元素用于指示收到数据传输请求消息中传输的数据。
The Data Transfer Response message is sent by the WTP or AC when in the Run state.
数据传输响应消息在运行状态下由WTP或AC发送。
The following message element MUST be included in the Data Transfer Response message:
数据传输响应消息中必须包含以下消息元素：
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
The following message element MAY be included in the Data Transfer Response message:
数据传输响应消息中可能包括以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
Upon receipt of a Data Transfer Response message, the WTP transmits more information, if more information is available.
在收到数据传输响应消息后，如果有更多信息可用，WTP将发送更多信息。
Messages in this section are used by the AC to create, modify, or delete station session state on the WTPs.
AC使用本节中的消息在WTP上创建、修改或删除站点会话状态。
The Station Configuration Request message is used to create, modify, or delete station session state on a WTP. The message is sent by the AC to the WTP, and MAY contain one or more message elements. The message elements for this CAPWAP Control message include information that is generally highly technology specific. Refer to the appropriate binding document for definitions of the messages elements that are included in this control message.
站点配置请求消息用于创建、修改或删除WTP上的站点会话状态。消息由AC发送到WTP，并且可能包含一个或多个消息元素。此CAPWAP控制消息的消息元素包括通常高度特定于技术的信息。有关此控制消息中包含的消息元素的定义，请参阅相应的绑定文档。
The Station Configuration Request message is sent by the AC when in the Run state. The WTP does not transmit this message.
AC在运行状态下发送站点配置请求消息。WTP不传输此消息。
The following CAPWAP Control message elements MAY be included in the Station Configuration Request message. More than one of each message element listed MAY be included in the Station Configuration Request message:
以下CAPWAP控制消息元素可能包含在站点配置请求消息中。所列的每个消息元素中有一个以上可包含在站点配置请求消息中：
o Add Station, see Section 4.6.8
o 添加站点，见第4.6.8节
o Delete Station, see Section 4.6.20
o 删除车站，见第4.6.20节
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Station Configuration Response message is used to acknowledge a previously received Station Configuration Request message.
站点配置响应消息用于确认先前收到的站点配置请求消息。
The Station Configuration Response message is sent by the WTP when in the Run state. The AC does not transmit this message.
当处于运行状态时，WTP发送站点配置响应消息。空调不发送此信息。
The following message element MUST be present in the Station Configuration Response message:
站配置响应消息中必须存在以下消息元素：
o Result Code, see Section 4.6.35
o 结果代码，见第4.6.35节
The following message element MAY be included in the Station Configuration Response message:
站配置响应消息中可能包含以下消息元素：
o Vendor Specific Payload, see Section 4.6.39
o 供应商特定有效载荷，见第4.6.39节
The Result Code message element indicates that the requested configuration was successfully applied, or that an error related to processing of the Station Configuration Request message occurred on the WTP.
结果代码消息元素表示请求的配置已成功应用，或者WTP上发生了与处理站点配置请求消息相关的错误。
There are three specific situations in which a NAT deployment may be used in conjunction with a CAPWAP-enabled deployment. The first consists of a configuration in which a single WTP is behind a NAT system. Since all communication is initiated by the WTP, and all communication is performed over IP using two UDP ports, the protocol easily traverses NAT systems in this configuration.
NAT部署可与支持CAPWAP的部署结合使用的具体情况有三种。第一种配置包括单个WTP位于NAT系统后面的配置。由于所有通信都是由WTP发起的，并且所有通信都是使用两个UDP端口通过IP执行的，因此该协议很容易在这种配置下穿越NAT系统。
In the second case, two or more WTPs are deployed behind the same NAT system. Here, the AC would receive multiple connection requests from the same IP address, and therefore cannot use the WTP's IP address alone to bind the CAPWAP Control and Data channel. The CAPWAP Data Check state, which establishes the data plane connection and
在第二种情况下，两个或多个WTP部署在同一NAT系统后面。在这里，AC将从同一IP地址接收多个连接请求，因此不能单独使用WTP的IP地址绑定CAPWAP控制和数据通道。CAPWAP数据检查状态，用于建立数据平面连接和
communicates the CAPWAP Data Channel Keep-Alive, includes the Session Identifier message element, which is used to bind the control and data plane. Use of the Session Identifier message element enables the AC to match the control and data plane flows from multiple WTPs behind the same NAT system (multiple WTPs sharing the same IP address). CAPWAP implementations MUST also use DTLS session information on any encrypted CAPWAP channel to validate the source of both the control and data plane, as described in Section 12.2.
与CAPWAP数据通道保持活动通信，包括用于绑定控件和数据平面的会话标识符消息元素。会话标识符消息元素的使用使AC能够匹配来自同一NAT系统后面的多个WTP（共享相同IP地址的多个WTP）的控制和数据平面流。CAPWAP实施还必须在任何加密的CAPWAP信道上使用DTLS会话信息，以验证控制平面和数据平面的来源，如第12.2节所述。
In the third configuration, the AC is deployed behind a NAT. In this case, the AC is not reachable by the WTP unless a specific rule has been configured on the NAT to translate the address and redirect CAPWAP messages to the AC. This deployment presents two issues. First, an AC communicates its interfaces and corresponding WTP load using the CAPWAP Control IPv4 Address and CAPWAP Control IPv6 Address message elements. This message element is mandatory, but contains IP addresses that are only valid in the private address space used by the AC, which is not reachable by the WTP. The WTP MUST NOT utilize the information in these message elements if it detects a NAT (as described in the CAPWAP Transport Protocol message element in Section 4.6.14). Second, since the addresses cannot be used by the WTP, this effectively disables the load-balancing capabilities (see Section 6.1) of the CAPWAP protocol. Alternatively, the AC could have a configured NAT'ed address, which it would include in either of the two control address message elements, and the NAT would need to be configured accordingly.
在第三种配置中，AC部署在NAT后面。在这种情况下，WTP无法访问AC，除非NAT上配置了特定规则来转换地址并将CAPWAP消息重定向到AC。此部署存在两个问题。首先，AC使用CAPWAP控制IPv4地址和CAPWAP控制IPv6地址消息元素通信其接口和相应的WTP负载。此消息元素是必需的，但包含的IP地址仅在AC使用的专用地址空间中有效，WTP无法访问该地址空间。如果WTP检测到NAT，则不得使用这些消息元素中的信息（如第4.6.14节CAPWAP传输协议消息元素所述）。其次，由于地址不能被WTP使用，这实际上禁用了CAPWAP协议的负载平衡功能（见第6.1节）。或者，AC可以具有配置的NAT’ed地址，它将包括在两个控制地址消息元素中的任一个中，并且NAT将需要相应地配置。
In order for a CAPWAP WTP or AC to detect whether a middlebox is present, both the Join Request (see Section 6.1) and the Join Response (see Section 6.2) include either the CAPWAP Local IPv4 Address (see Section 4.6.11) or the CAPWAP Local IPv6 Address (see Section 4.6.12) message element. Upon receiving one of these messages, if the packet's source IP address differs from the address found in either one of these message elements, it indicates that a middlebox is present.
为了让CAPWAP WTP或AC检测是否存在中间盒，加入请求（见第6.1节）和加入响应（见第6.2节）都包括CAPWAP本地IPv4地址（见第4.6.11节）或CAPWAP本地IPv6地址（见第4.6.12节）消息元素。在接收到其中一条消息时，如果数据包的源IP地址与在其中任一消息元素中找到的地址不同，则表示存在一个中间盒。
In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which it received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port.
为了使CAPWAP与网络中潜在的中间盒兼容，CAPWAP实施必须从接收来自给定对等方流量的同一端口发送返回流量。此外，CAPWAP节点生成的任何未经请求的请求必须在同一端口上发送。
Note that this middlebox detection technique is not foolproof. If the public IP address assigned to the NAT is identical to the private IP address used by the AC, detection by the WTP would fail. This failure can lead to various protocol errors, so it is therefore necessary for deployments to ensure that the NAT's IP address is not the same as the ACs.
请注意，这种中间盒检测技术并非万无一失。如果分配给NAT的公共IP地址与AC使用的私有IP地址相同，则WTP的检测将失败。此故障可能导致各种协议错误，因此部署时必须确保NAT的IP地址与ACs不同。
The CAPWAP protocol allows for all of the AC identities supporting a group of WTPs to be communicated through the AC List message element. This feature MUST be ignored by the WTP when it detects the AC is behind a middlebox.
CAPWAP协议允许支持一组WTP的所有AC身份通过AC List消息元素进行通信。当WTP检测到空调位于中间箱后面时，必须忽略此功能。
The CAPWAP protocol allows an AC to configure a static IP address on a WTP using the WTP Static IP Address Information message element. This message element SHOULD NOT be used in NAT'ed environments, unless the administrator is familiar with the internal IP addressing scheme within the WTP's private network, and does not rely on the public address seen by the AC.
CAPWAP协议允许AC使用WTP静态IP地址信息消息元素在WTP上配置静态IP地址。除非管理员熟悉WTP专用网络内的内部IP寻址方案，并且不依赖AC看到的公共地址，否则不应在NAT环境中使用此消息元素。
When a WTP detects the duplicate address condition, it generates a message to the AC, which includes the Duplicate IP Address message element. The IP address embedded within this message element is different from the public IP address seen by the AC.
当WTP检测到重复地址条件时，它会向AC生成一条消息，其中包括重复IP地址消息元素。此消息元素中嵌入的IP地址与AC看到的公共IP地址不同。
This section describes security considerations for the CAPWAP protocol. It also provides security recommendations for protocols used in conjunction with CAPWAP.
本节介绍CAPWAP协议的安全注意事项。它还为与CAPWAP结合使用的协议提供安全建议。
As it is currently specified, the CAPWAP protocol sits between the security mechanisms specified by the wireless link layer protocol (e.g., IEEE 802.11i) and Authentication, Authorization, and Accounting (AAA). One goal of CAPWAP is to bootstrap trust between the STA and WTP using a series of preestablished trust relationships:
按照目前的规定，CAPWAP协议位于无线链路层协议（如IEEE 802.11i）和认证、授权和计费（AAA）指定的安全机制之间。CAPWAP的一个目标是使用一系列预先建立的信任关系引导STA和WTP之间的信任：
STA WTP AC AAA
==============================================
STA WTP AC AAA
==============================================
DTLS Cred AAA Cred
<------------><------------->
DTLS Cred AAA Cred
<------------><------------->
EAP Credential
<------------------------------------------>
EAP Credential
<------------------------------------------>
wireless link layer
(e.g., 802.11 PTK)
<--------------> or
<--------------------------->
(derived)
wireless link layer
(e.g., 802.11 PTK)
<--------------> or
<--------------------------->
(derived)
Figure 12: STA Session Setup
图12:STA会话设置
Within CAPWAP, DTLS is used to secure the link between the WTP and AC. In addition to securing control messages, it's also a link in this chain of trust for establishing link layer keys. Consequently, much rests on the security of DTLS.
在CAPWAP中，DTLS用于保护WTP和AC之间的链路。除了保护控制消息外，它也是建立链路层密钥的信任链中的一个链路。因此，很大程度上取决于DTL的安全性。
In some CAPWAP deployment scenarios, there are two channels between the WTP and AC: the control channel, carrying CAPWAP Control messages, and the data channel, over which client data packets are tunneled between the AC and WTP. Typically, the control channel is secured by DTLS, while the data channel is not.
在某些CAPWAP部署场景中，WTP和AC之间有两个通道：控制通道，承载CAPWAP控制消息；数据通道，通过该通道在AC和WTP之间传输客户端数据包。通常，控制通道由DTL保护，而数据通道不受保护。
The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into unprotected data and attempting to convert un-protected data into protected data. These concerns are addressed below.
使用并行受保护和未受保护的通道值得特别考虑，但不会造成威胁。有两个潜在问题：试图将受保护的数据转换为不受保护的数据，以及试图将不受保护的数据转换为受保护的数据。这些问题将在下文讨论。
Since CAPWAP does not support authentication-only ciphers (i.e., all supported ciphersuites include encryption and authentication), it is not possible to convert protected data into unprotected data. Since encrypted data is (ideally) indistinguishable from random data, the probability of an encrypted packet passing for a well-formed packet is effectively zero.
由于CAPWAP不支持仅验证密码（即，所有支持的密码套件都包括加密和验证），因此无法将受保护的数据转换为不受保护的数据。由于加密数据（理想情况下）与随机数据无法区分，因此加密数据包通过格式良好数据包的概率实际上为零。
The use of message authentication makes it impossible for the attacker to forge protected records. This makes conversion of unprotected records to protected records impossible.
使用消息身份验证使攻击者无法伪造受保护的记录。这使得不受保护的记录无法转换为受保护的记录。
An attacker could remove protected records from the stream, though not undetectably so, due the built-in reliability of the underlying CAPWAP protocol. In the worst case, the attacker would remove the same record repeatedly, resulting in a CAPWAP session timeout and restart. This is effectively a DoS attack, and could be accomplished by a man in the middle regardless of the CAPWAP protocol security mechanisms chosen.
由于底层CAPWAP协议的内置可靠性，攻击者可以从流中删除受保护的记录，但并非无法检测到。在最坏的情况下，攻击者会重复删除相同的记录，导致CAPWAP会话超时并重新启动。这实际上是一个DoS攻击，并且可以由中间人完成，而不考虑CAPWAP协议安全机制的选择。
An attacker could inject packets into the unprotected channel, but this may become evident if sequence number desynchronization occurs as a result. Only if the attacker is a man in the middle (MITM) can
攻击者可以将数据包注入未受保护的通道，但如果因此发生序列号不同步，则这可能变得明显。只有攻击者是中间人（MITM）才能
packets be inserted undetectably. This is a consequence of that channel's lack of protection, and not a new threat resulting from the CAPWAP security mechanism.
无法检测到数据包被插入。这是该通道缺乏保护的结果，而不是CAPWAP安全机制造成的新威胁。
The Image Information message element (Section 4.6.28) makes use of MD5 to compute the hash field. The authenticity and integrity of the image file is protected by DTLS, and in this context, MD5 is not used as a cryptographically secure hash, but just as a basic checksum. Therefore, the use of MD5 is not considered a security vulnerability, and no mechanisms for algorithm agility are provided.
图像信息消息元素（第4.6.28节）使用MD5计算散列字段。图像文件的真实性和完整性受DTL保护，在这种情况下，MD5不用作加密安全哈希，而只是用作基本校验和。因此，MD5的使用不被视为安全漏洞，也没有提供算法敏捷性机制。
RFC 4963 [RFC4963] describes a possible security vulnerability where a malicious entity can "corrupt" a flow by injecting fragments. By sending "high" fragments (those with offset greater than zero) with a forged source address, the attacker can deliberately cause corruption. The use of DTLS on the CAPWAP Data channel can be used to avoid this possible vulnerability.
RFC 4963[RFC4963]描述了一个可能的安全漏洞，恶意实体可以通过注入碎片“破坏”流。通过发送带有伪造源地址的“高”片段（偏移量大于零的片段），攻击者可以故意造成损坏。在CAPWAP数据通道上使用DTL可避免此漏洞。
Since DTLS does not export a unique session identifier, there can be no explicit protocol binding between the DTLS layer and CAPWAP layer. As a result, implementations MUST provide a mechanism for performing this binding. For example, an AC MUST NOT associate decrypted DTLS control packets with a particular WTP session based solely on the Session ID in the packet header. Instead, identification should be done based on which DTLS session decrypted the packet. Otherwise, one authenticated WTP could spoof another authenticated WTP by altering the Session ID in the encrypted CAPWAP Header.
由于DTLS不导出唯一的会话标识符，因此DTLS层和CAPWAP层之间不可能存在明确的协议绑定。因此，实现必须提供执行此绑定的机制。例如，AC不得仅基于数据包报头中的会话ID将解密的DTLS控制数据包与特定WTP会话相关联。相反，应该根据哪个DTLS会话解密数据包来进行标识。否则，一个经过身份验证的WTP可以通过更改加密的CAPWAP头中的会话ID来欺骗另一个经过身份验证的WTP。
It should be noted that when the CAPWAP Data channel is unencrypted, the WTP Session ID is exposed and possibly known to adversaries and other WTPs. This would allow the forgery of the source of data-channel traffic. This, however, should not be a surprise for unencrypted data channels. When the data channel is encrypted, the Session ID is not exposed, and therefore can safely be used to associate a data and control channel. The 128-bit length of the Session ID mitigates online guessing attacks where an adversarial, authenticated WTP tries to correlate his own data channel with another WTP's control channel. Note that for encrypted data channels, the Session ID should only be used for correlation for the first packet immediately after the initial DTLS handshake. Future correlation should instead be done via identification of a packet's DTLS session.
应该注意的是，当CAPWAP数据通道未加密时，WTP会话ID将公开，并且对手和其他WTP可能知道该ID。这将允许伪造数据通道流量的来源。然而，对于未加密的数据通道来说，这并不奇怪。当数据通道加密时，会话ID不会公开，因此可以安全地用于关联数据和控制通道。会话ID的128位长度缓解了在线猜测攻击，其中一个敌对的、经过身份验证的WTP试图将其自己的数据通道与另一个WTP的控制通道关联起来。请注意，对于加密数据通道，会话ID应仅用于在初始DTLS握手后立即关联第一个数据包。未来的关联应该通过识别数据包的DTLS会话来完成。
Since the Discovery Request messages are sent in the clear, it is important that AC implementations NOT assume that receiving a Discovery Request message from a WTP implies that the WTP has rebooted, and consequently tear down any active DTLS sessions. Discovery Request messages can easily be spoofed by malicious devices, so it is important that the AC maintain two separate sets of states for the WTP until the DTLSSessionEstablished notification is received, indicating that the WTP was authenticated. Once a new DTLS session is successfully established, any state referring to the old session can be cleared.
由于发现请求消息是以明文形式发送的，因此AC实现不应假设从WTP接收到发现请求消息意味着WTP已重新启动，从而中断任何活动DTLS会话，这一点很重要。恶意设备很容易伪造发现请求消息，因此AC必须为WTP保留两组独立的状态，直到收到DTLSessionEstablished通知，表明WTP已通过身份验证。成功建立新DTLS会话后，可以清除引用旧会话的任何状态。
Similarly, when the AC is entering the DTLS Setup phase, it SHOULD NOT assume that the WTP has reset, and therefore should not discard active state until the DTLS session has been successfully established. While the HelloVerifyRequest provides some protection against denial-of-service (DoS) attacks on the AC, an adversary capable of receiving packets at a valid address (or a malfunctioning or misconfigured WTP) may repeatedly attempt DTLS handshakes with the AC, potentially creating a resource shortage. If either the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations MAY choose to rate-limit new DTLS handshakes for some period of time. It is RECOMMENDED that implementations choosing to implement rate-limiting use a random discard technique, rather than mimicking the WTP's sulking behavior. This will ensure that messages from valid WTPs will have some probability of eliciting a response, even in the face of a significant DoS attack.
同样，当AC进入DTLS设置阶段时，不应假定WTP已重置，因此在成功建立DTLS会话之前不应放弃活动状态。虽然HelloVerifyRequest提供了一些针对AC拒绝服务（DoS）攻击的保护，但能够在有效地址（或故障或配置错误的WTP）接收数据包的对手可能会重复尝试与AC进行DTLS握手，从而可能造成资源短缺。如果FailedDTLSessionCount或FailedDTLSAuthFailCount计数器达到MaxFailedDTLSessionRetry变量的值（请参见第4.8节），则实现可能会选择在一段时间内对新DTLS握手进行评级限制。建议选择实现速率限制的实现使用随机丢弃技术，而不是模仿WTP的生气行为。这将确保来自有效WTP的消息在一定程度上有可能引发响应，即使在面临重大DoS攻击时也是如此。
Some CAPWAP implementations may wish to restrict the DTLS setup process to only those peers that have been configured in the access control list, authorizing only those clients to initiate a DTLS handshake. Note that the impact of this on mitigating denial-of-service attacks against the DTLS layer is minimal, because DTLS already uses client-side cookies to minimize processor consumption attacks.
一些CAPWAP实施可能希望将DTLS设置过程仅限于访问控制列表中已配置的对等方，仅授权这些客户端启动DTLS握手。请注意，这对减轻针对DTLS层的拒绝服务攻击的影响是最小的，因为DTLS已经使用客户端cookie来最小化处理器消耗攻击。
If a WTP or AC repeatedly receives packets that fail DTLS authentication or decryption, this could indicate a DTLS desynchronization between the AC and WTP, a link prone to undetectable bit errors, or an attacker trying to disrupt a DTLS session.
如果WTP或AC反复接收到DTLS身份验证或解密失败的数据包，则这可能表示AC和WTP之间的DTLS失步、链路容易出现无法检测到的位错误，或者攻击者试图中断DTLS会话。
In the state machine (section 2.3), transitions to the DTLS Tear Down (TD) state can be triggered by frequently receiving DTLS packets with authentication or decryption errors. The threshold or technique for deciding when to move to the tear down state should be chosen carefully. Being able to easily transition to DTLS TD allows easy detection of malfunctioning devices, but allows for denial-of-service attacks. Making it difficult to transition to DTLS TD prevents denial-of-service attacks, but makes it more difficult to detect and reset a malfunctioning session. Implementers should set this policy with care.
在状态机（第2.3节）中，通过频繁接收带有身份验证或解密错误的DTLS数据包，可以触发到DTLS中断（TD）状态的转换。应仔细选择决定何时进入拆卸状态的阈值或技术。能够轻松过渡到DTLS TD可以轻松检测出故障设备，但也允许拒绝服务攻击。使其难以过渡到DTLS TD可防止拒绝服务攻击，但使检测和重置故障会话更加困难。实施者应谨慎地制定此策略。
In order for CAPWAP to establish a secure communication with a peer, some level of pre-provisioning on both the WTP and AC is necessary. This section will detail the minimal number of configuration parameters.
为了使CAPWAP与对等方建立安全通信，必须在WTP和AC上进行一定程度的预配置。本节将详细说明配置参数的最小数量。
When using pre-shared keys, it is necessary to configure the pre-shared key for each possible peer with which a DTLS session may be established. To support this mode of operation, one or more entries of the following table may be configured on either the AC or WTP:
当使用预共享密钥时，有必要为可能与之建立DTLS会话的每个可能对等方配置预共享密钥。为支持此操作模式，可在AC或WTP上配置下表中的一个或多个条目：
o Identity: The identity of the peering AC or WTP. This format MAY be in the form of either an IP address or host name (the latter of which needs to be resolved to an IP address using DNS).
o 标识：对等AC或WTP的标识。此格式可以是IP地址或主机名的形式（后者需要使用DNS解析为IP地址）。
o Key: The pre-shared key for use with the peer when establishing the DTLS session (see Section 12.6 for more information).
o 密钥：在建立DTLS会话时与对等方一起使用的预共享密钥（有关更多信息，请参阅第12.6节）。
o PSK Identity: Identity hint associated with the provisioned key (see Section 2.4.4.4 for more information).
o PSK标识：与配置密钥相关联的标识提示（有关更多信息，请参阅第2.4.4.4节）。
When using certificates, the following items need to be pre-provisioned:
使用证书时，需要预先设置以下项目：
o Device Certificate: The local device's certificate (see Section 12.7 for more information).
o 设备证书：本地设备的证书（有关更多信息，请参阅第12.7节）。
o Trust Anchor: Trusted root certificate chain used to validate any certificate received from CAPWAP peers. Note that one or more root certificates MAY be configured on a given device.
o 信任锚：用于验证从CAPWAP对等方接收的任何证书的受信任根证书链。请注意，可以在给定设备上配置一个或多个根证书。
Regardless of the authentication method, the following item needs to be pre-provisioned:
无论采用何种身份验证方法，都需要预先设置以下项：
o Access Control List: The access control list table contains the identities of one or more CAPWAP peers, along with a rule. The rule is used to determine whether communication with the peer is permitted (see Section 2.4.4.3 for more information).
o 访问控制列表：访问控制列表表包含一个或多个CAPWAP对等方的身份以及一条规则。该规则用于确定是否允许与对等方进行通信（有关更多信息，请参阅第2.4.4.3节）。
While use of pre-shared keys may provide deployment and provisioning advantages not found in public-key-based deployments, it also introduces a number of operational and security concerns. In particular, because the keys must typically be entered manually, it is common for people to base them on memorable words or phrases. These are referred to as "low entropy passwords/passphrases".
虽然使用预共享密钥可以提供基于公钥的部署中所没有的部署和资源调配优势，但它也带来了一些操作和安全问题。特别是，由于按键通常必须手动输入，因此人们通常会根据可记忆的单词或短语输入按键。这些被称为“低熵密码/密码短语”。
Use of low-entropy pre-shared keys, coupled with the fact that the keys are often not frequently updated, tends to significantly increase exposure. For these reasons, the following recommendations are made:
使用低熵预共享密钥，加上密钥通常不经常更新，往往会显著增加曝光率。出于这些原因，提出以下建议：
o When DTLS is used with a pre-shared key (PSK) ciphersuite, each WTP SHOULD have a unique PSK. Since WTPs will likely be widely deployed, their physical security is not guaranteed. If PSKs are not unique for each WTP, key reuse would allow the compromise of one WTP to result in the compromise of others.
o 当DTL与预共享密钥（PSK）密码套件一起使用时，每个WTP应具有唯一的PSK。由于WTP可能会被广泛部署，其物理安全无法得到保证。如果每个WTP的PSK不是唯一的，则密钥重用将允许一个WTP的妥协导致其他WTP的妥协。
o Generating PSKs from low entropy passwords is NOT RECOMMENDED.
o 不建议使用低熵密码生成PSK。
o It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a capability for generation of new random PSKs, taking RFC 4086 [RFC4086] into account.
o 建议允许管理员手动配置PSK的实现也提供生成新随机PSK的能力，同时考虑RFC 4086[RFC4086]。
o Pre-shared keys SHOULD be periodically updated. Implementations MAY facilitate this by providing an administrative interface for automatic key generation and periodic update, or it MAY be accomplished manually instead.
o 应定期更新预共享密钥。实现可以通过提供用于自动密钥生成和定期更新的管理接口来促进这一点，也可以手动完成。
Every pairwise combination of WTP and AC on the network SHOULD have a unique PSK. This prevents the domino effect (see "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" [RFC4962]). If PSKs are tied to specific WTPs, then knowledge of the PSK implies a binding to a specified identity that can be authorized.
网络上WTP和AC的每一对组合都应具有唯一的PSK。这可以防止多米诺效应（请参阅“身份验证、授权和记帐（AAA）密钥管理指南”[RFC4962]）。如果PSK绑定到特定的WTP，那么了解PSK意味着绑定到可以授权的指定标识。
If PSKs are shared, this binding between device and identity is no longer possible. Compromise of one WTP can yield compromise of another WTP, violating the CAPWAP security hierarchy. Consequently, sharing keys between WTPs is NOT RECOMMENDED.
如果PSK是共享的，那么设备和标识之间的绑定就不再可能。一个WTP的泄露会导致另一个WTP的泄露，从而违反CAPWAP安全层次结构。因此，不建议在WTP之间共享密钥。
For public-key-based DTLS deployments, each device SHOULD have unique credentials, with an extended key usage authorizing the device to act as either a WTP or AC. If devices do not have unique credentials, it is possible that by compromising one device, any other device using the same credential may also be considered to be compromised.
对于基于公钥的DTL部署，每个设备都应具有唯一的凭据，扩展的密钥使用授权该设备充当WTP或AC。如果设备没有唯一的凭据，则可能通过泄露一个设备，使用相同凭据的任何其他设备也会被视为泄露。
Certificate validation involves checking a large variety of things. Since the necessary things to validate are often environment-specific, many are beyond the scope of this document. In this section, we provide some basic guidance on certificate validation.
证书验证涉及检查各种各样的内容。由于需要验证的内容通常是特定于环境的，因此许多内容超出了本文档的范围。在本节中，我们将提供一些有关证书验证的基本指导。
Each device is responsible for authenticating and authorizing devices with which they communicate. Authentication entails validation of the chain of trust leading to the peer certificate, followed by the peer certificate itself. Implementations SHOULD also provide a secure method for verifying that the credential in question has not been revoked.
每个设备负责验证和授权与其通信的设备。身份验证需要验证导致对等证书的信任链，然后是对等证书本身。实现还应该提供一种安全的方法来验证所讨论的凭证是否未被撤销。
Note that if the WTP relies on the AC for network connectivity (e.g., the AC is a Layer 2 switch to which the WTP is directly connected), the WTP may not be able to contact an Online Certificate Status Protocol (OCSP) server or otherwise obtain an up-to-date Certificate Revocation List (CRL) if a compromised AC doesn't explicitly permit this. This cannot be avoided, except through effective physical security and monitoring measures at the AC.
请注意，如果WTP依赖AC进行网络连接（例如，AC是WTP直接连接到的第2层交换机），WTP可能无法联系在线证书状态协议（OCSP）服务器，或者在受损AC未明确允许的情况下无法获取最新证书撤销列表（CRL）。这是无法避免的，除非通过AC的有效物理安全和监控措施。
Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real-time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD make a best-effort attempt to validate the certificate validity dates through other means. Failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation.
证书的正确验证通常需要进行检查，以确保证书尚未过期。如果设备具有实时时钟，则应验证证书有效日期。如果没有实时时钟可用，设备应尽最大努力通过其他方式验证证书有效期。未能检查证书的暂时有效性会使设备容易受到使用已泄露、过期证书发起的中间人攻击的攻击，因此设备应尽一切努力执行此验证。
The CAPWAP protocol is an evolution of an existing protocol [LWAPP], which is implemented on a large number of already deployed ACs and WTPs. Every one of these devices has an existing X.509 certificate, which is provisioned at the time of manufacturing. These X.509 certificates use the device's MAC address in the Common Name (CN) field. It is well understood that encoding the MAC address in the CN field is less than optimal, and using the SubjectAltName field would be preferable. However, at the time of publication, there is no URN
CAPWAP协议是现有协议[LWAPP]的演变，该协议在大量已部署的ACs和WTP上实现。这些设备中的每一个都有一个现有的X.509证书，该证书是在制造时提供的。这些X.509证书在公共名称（CN）字段中使用设备的MAC地址。众所周知，在CN字段中编码MAC地址不是最佳的，并且使用SubjectAltName字段将是优选的。然而，在出版时，没有URN
specification that allows for the MAC address to be used in the SubjectAltName field. As such a specification is published by the IETF, future versions of the CAPWAP protocol MAY require support for the new URN scheme.
允许在SubjectAltName字段中使用MAC地址的规范。由于IETF发布了此类规范，CAPWAP协议的未来版本可能需要支持新的URN方案。
The AAA protocol is used to distribute Extensible Authentication Protocol (EAP) keys to the ACs, and consequently its security is important to the overall system security. When used with Transport Layer Security (TLS) or IPsec, security guidelines specified in RFC 3539 [RFC3539] SHOULD be followed.
AAA协议用于向ACs分发可扩展认证协议（EAP）密钥，因此其安全性对整个系统的安全性至关重要。当与传输层安全（TLS）或IPsec一起使用时，应遵循RFC 3539[RFC3539]中规定的安全准则。
In general, the link between the AC and AAA server SHOULD be secured using a strong ciphersuite keyed with mutually authenticated session keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared secret authentication as it is often vulnerable to dictionary attacks, but rather SHOULD use stronger underlying security mechanisms.
一般来说，AC和AAA服务器之间的链接应使用强密码套件进行保护，该套件由相互认证的会话密钥进行密钥设置。实现不应该仅仅依赖基本的RADIUS共享秘密身份验证，因为它通常容易受到字典攻击，而应该使用更强大的底层安全机制。
The CAPWAP protocol defines a mechanism by which the AC downloads new firmware to the WTP. During the session establishment process, the WTP provides information about its current firmware to the AC. The AC then decides whether the WTP's firmware needs to be updated. It is important to note that the CAPWAP specification makes the explicit assumption that the WTP is providing the correct firmware version to the AC, and is therefore not lying. Further, during the firmware download process, the CAPWAP protocol does not provide any mechanisms to recognize whether the WTP is actually storing the firmware for future use.
CAPWAP协议定义了AC将新固件下载到WTP的机制。在会话建立过程中，WTP向AC提供有关其当前固件的信息。AC然后决定是否需要更新WTP的固件。需要注意的是，CAPWAP规范明确假设WTP为AC提供了正确的固件版本，因此没有撒谎。此外，在固件下载过程中，CAPWAP协议不提供任何机制来识别WTP是否实际存储固件以供将来使用。
The CAPWAP protocol assumes that it is the only configuration interface to the WTP to configure parameters that are specified in the CAPWAP specifications. While the use of a separate management protocol MAY be used for the purposes of monitoring the WTP directly, configuring the WTP through a separate management interface is not recommended. Configuring the WTP through a separate protocol, such as via a command line interface (CLI) or Simple Network Management Protocol (SNMP), could lead to the AC state being out of sync with the WTP.
CAPWAP协议假定它是WTP的唯一配置接口，用于配置CAPWAP规范中指定的参数。虽然可以使用单独的管理协议直接监控WTP，但不建议通过单独的管理接口配置WTP。通过单独的协议（如通过命令行界面（CLI）或简单网络管理协议（SNMP））配置WTP可能会导致AC状态与WTP不同步。
The CAPWAP protocol does not deal with the management of the ACs. The AC is assumed to be configured through some separate management interface, which could be via a proprietary CLI, SNMP, Network Configuration Protocol (NETCONF), or some other management protocol.
CAPWAP协议不处理ACs的管理。假设AC通过一些单独的管理接口进行配置，这些接口可以通过专有CLI、SNMP、网络配置协议（NETCONF）或其他一些管理协议进行配置。
The CAPWAP protocol's control channel is fairly lightweight from a traffic perspective. Once the WTP has been configured, the WTP sends periodic statistics. Further, the specification calls for a keep-alive packet to be sent on the protocol's data channel to make sure that any possible middleboxes (e.g., NAT) maintain their UDP state. The overhead associated with the control and data channel is not expected to impact network traffic. That said, the CAPWAP protocol does allow for the frequency of these packets to be modified through the DataChannelKeepAlive and StatisticsTimer (see Section 4.7.2 and Section 4.7.14, respectively).
从流量角度来看，CAPWAP协议的控制通道相当轻量级。配置WTP后，WTP将发送定期统计信息。此外，该规范要求在协议的数据通道上发送保持活动的数据包，以确保任何可能的中间盒（例如NAT）保持其UDP状态。与控制和数据通道相关的开销预计不会影响网络流量。也就是说，CAPWAP协议允许通过DataChannelKeepAlive和StatisticsTimer修改这些数据包的频率（分别参见第4.7.2节和第4.7.14节）。
The CAPWAP WG carefully considered the congestion control requirements of the CAPWAP protocol, both for the CAPWAP Control and Data channels.
CAPWAP工作组仔细考虑了CAPWAP协议对CAPWAP控制和数据信道的拥塞控制要求。
CAPWAP specifies a single-threaded command/response protocol to be used on the control channel, and we have specified that an exponential back-off algorithm should be used when commands are retransmitted. When CAPWAP runs in its default mode (Local MAC), the control channel is the only CAPWAP channel.
CAPWAP指定了在控制通道上使用的单线程命令/响应协议，我们还指定了在重新传输命令时应使用指数退避算法。当CAPWAP在其默认模式（本地MAC）下运行时，控制通道是唯一的CAPWAP通道。
However, CAPWAP can also be run in Split MAC mode, in which case there will be a DTLS-encrypted data channel between each WTP and the AC. The WG discussed various options for providing congestion control on this channel. However, due to performance problems with TCP when it is run over another congestion control mechanism and the fact that the vast majority of traffic run over the CAPWAP Data channel is likely to be congestion-controlled IP traffic, the CAPWAP WG felt that specifying a congestion control mechanism for the CAPWAP Data channel would be more likely to cause problems than to resolve any.
然而，CAPWAP也可以在分割MAC模式下运行，在这种情况下，每个WTP和AC之间将有一个DTLS加密数据通道。工作组讨论了在该通道上提供拥塞控制的各种选项。但是，由于TCP在另一种拥塞控制机制上运行时的性能问题，以及在CAPWAP数据通道上运行的绝大多数流量可能是拥塞控制的IP流量这一事实，CAPWAP工作组认为，为CAPWAP数据通道指定拥塞控制机制更可能导致问题，而不是解决任何问题。
Because there is no congestion control mechanism specified for the CAPWAP Data channel, it is RECOMMENDED that non-congestion-controlled traffic not be tunneled over CAPWAP. When a significant amount of non-congestion-controlled traffic is expected to be present on a WLAN, the CAPWAP connection between the AC and the WTP for that LAN should be configured to remain in Local MAC mode with Distribution function at the WTP.
由于没有为CAPWAP数据通道指定拥塞控制机制，因此建议不要通过CAPWAP对非拥塞控制流量进行隧道传输。当预期WLAN上存在大量非拥塞控制流量时，该LAN的AC和WTP之间的CAPWAP连接应配置为保持本地MAC模式，并在WTP上具有分发功能。
The lock step nature of the CAPWAP protocol's control channel can cause the firmware download process to take some time, depending upon the round-trip time (RTT). This is not expected to be a problem since the CAPWAP protocol allows firmware to be downloaded while the WTP provides service to wireless clients/devices.
CAPWAP协议控制通道的锁定步骤性质可能导致固件下载过程需要一些时间，具体取决于往返时间（RTT）。由于CAPWAP协议允许在WTP向无线客户端/设备提供服务时下载固件，因此预计这不会成为问题。
It is necessary for the WTP and AC to configure their MTU based on the capabilities of the path. See Section 3.5 for more information.
WTP和AC有必要根据路径的功能配置其MTU。详见第3.5节。
The CAPWAP protocol mandates support of the Explicit Congestion Notification (ECN) through a mode of operation named "limited functionality option", detailed in section 9.1.1 of [RFC3168]. Future versions of the CAPWAP protocol should consider mandating support for the "full functionality option".
CAPWAP协议要求通过名为“有限功能选项”的操作模式支持显式拥塞通知（ECN），详见[RFC3168]第9.1.1节。CAPWAP协议的未来版本应该考虑强制支持“全功能选项”。
This section details the actions that IANA has taken in preparation for publication of the specification. Numerous registries have been created, and the contents, document action (see [RFC5226], and registry format are all included below. Note that in cases where bit fields are referred to, the bit numbering is left to right, where the leftmost bit is labeled as bit zero (0).
本节详细介绍了IANA在准备发布规范时所采取的行动。创建了许多注册表，内容、文档操作（参见[RFC5226]和注册表格式都包含在下面。请注意，在引用位字段的情况下，位编号是从左到右的，最左边的位标记为位零（0）。
For future registration requests where an Expert Review is required, a Designated Expert should be consulted, which is appointed by the responsible IESG Area Director. The intention is that any allocation will be accompanied by a published RFC, but given that other SDOs may want to create standards built on top of CAPWAP, a document the Designated Expert can review is also acceptable. IANA should allow for allocation of values prior to documents being approved for publication, so the Designated Expert can approve allocations once it seems clear that publication will occur. The Designated Expert will post a request to the CAPWAP WG mailing list (or a successor designated by the Area Director) for comment and review. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the CAPWAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
对于未来需要专家审查的注册请求，应咨询由IESG区域负责人任命的指定专家。其目的是，任何分配都将附带发布的RFC，但鉴于其他SDO可能希望在CAPWAP基础上创建标准，指定专家可以审查的文件也是可以接受的。IANA应允许在批准发布文件之前分配值，以便在明确将发布文件时，指定专家可以批准分配。指定专家将向CAPWAP工作组邮件列表（或区域总监指定的继任者）发出请求，以征求意见和审查。在30天内，指定专家将批准或拒绝注册请求，并向CAPWAP工作组邮件列表或其继任者发布决定通知，同时通知IANA。拒绝通知必须以解释为理由，在可能的情况下，应提供具体建议，说明如何修改请求以使其成为可接受的请求。
IANA has registered a new IPv4 multicast address called "capwap-ac" from the Internetwork Control Block IPv4 multicast address registry; see Section 3.3.
IANA已从互联网控制块IPv4多播地址注册表中注册了一个名为“capwap ac”的新IPv4多播地址；见第3.3节。
IANA has registered a new organization local multicast address called the "All ACs multicast address" in the Variable Scope IPv6 multicast address registry; see Section 3.3.
IANA在可变范围IPv6多播地址注册表中注册了一个新的组织本地多播地址，称为“All ACs多播地址”；见第3.3节。
IANA registered two new UDP Ports, which are organization-local multicast addresses, in the registered port numbers registry; see Section 3.1. The following values have been registered:
IANA在注册的端口号注册表中注册了两个新的UDP端口，它们是组织本地多播地址；见第3.1节。已注册以下值：
Keyword Decimal Description References
------- ------- ----------- ----------
capwap-control 5246/udp CAPWAP Control Protocol This Document
capwap-data 5247/udp CAPWAP Data Protocol This Document
Keyword Decimal Description References
------- ------- ----------- ----------
capwap-control 5246/udp CAPWAP Control Protocol This Document
capwap-data 5247/udp CAPWAP Data Protocol This Document
The Message Type field in the CAPWAP Header (see Section 4.5.1.1) is used to identify the operation performed by the message. There are multiple namespaces, which are identified via the first three octets of the field containing the IANA Enterprise Number [RFC5226].
CAPWAP标题中的消息类型字段（见第4.5.1.1节）用于识别消息执行的操作。有多个名称空间，通过包含IANA企业号[RFC5226]的字段的前三个八位字节来标识。
IANA maintains the CAPWAP Message Types registry for all message types whose Enterprise Number is set to zero (0). The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 26 are allocated in this specification, and can be found in Section 4.5.1.1. Any new assignments of a CAPWAP Message Type whose Enterprise Number is set to zero (0) requires an Expert Review. The registry maintained by IANA has the following format:
IANA为企业编号设置为零（0）的所有邮件类型维护CAPWAP邮件类型注册表。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了一（1）到26的值，可在第4.5.1.1节中找到。企业编号设置为零（0）的CAPWAP消息类型的任何新分配都需要专家审查。IANA维护的注册表具有以下格式：
CAPWAP Control Message Message Type Reference Value
CAPWAP控制消息消息类型参考值
The Flags field in the CAPWAP Header (see Section 4.3) is 9 bits in length and is used to identify any special treatment related to the message. This specification defines bits zero (0) through five (5), while bits six (6) through eight (8) are reserved. There are currently three unused, reserved bits that are managed by IANA and whose assignment require an Expert Review. IANA created the CAPWAP Header Flags registry, whose format is:
CAPWAP头中的标志字段（见第4.3节）长度为9位，用于识别与消息相关的任何特殊处理。本规范定义了位0（0）到位5，而位6（6）到位8（8）是保留的。目前有三个未使用的保留位由IANA管理，其分配需要专家审查。IANA创建了CAPWAP头标志注册表，其格式为：
Flag Field Name Bit Position Reference
标志字段名称位位置参考
The Flags field in the CAPWAP Control Message header (see Section 4.5.1.4) is used to identify any special treatment related to the control message. There are currently eight (8) unused, reserved bits. The assignment of these bits is managed by IANA and requires an Expert Review. IANA created the CAPWAP Control Message Flags registry, whose format is:
CAPWAP控制消息头中的标志字段（见第4.5.1.4节）用于识别与控制消息相关的任何特殊处理。目前有八（8）个未使用的保留位。这些BIT的分配由IANA管理，需要专家审查。IANA创建了CAPWAP控制消息标志注册表，其格式为：
Flag Field Name Bit Position Reference
标志字段名称位位置参考
The Type field in the CAPWAP Message Element header (see Section 4.6) is used to identify the data being transported. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 53 are allocated in this specification, and can be found in Section 4.5.1.1.
CAPWAP消息元素标题中的类型字段（见第4.6节）用于标识正在传输的数据。名称空间是16位（0-65535），其中0（0）的值是保留的，不能赋值。本规范中分配了一（1）到53的值，可在第4.5.1.1节中找到。
The 16-bit namespace is further divided into blocks of addresses that are reserved for specific CAPWAP wireless bindings. The following blocks are reserved:
16位名称空间进一步划分为地址块，这些地址块是为特定的CAPWAP无线绑定保留的。保留以下区块：
CAPWAP Protocol Message Elements 1 - 1023 IEEE 802.11 Message Elements 1024 - 2047 EPCGlobal Message Elements 3072 - 4095
CAPWAP协议消息元素1-1023 IEEE 802.11消息元素1024-2047 EPCGlobal消息元素3072-4095
This namespace is managed by IANA and assignments require an Expert Review. IANA created the CAPWAP Message Element Type registry, whose format is:
此名称空间由IANA管理，分配需要专家审查。IANA创建了CAPWAP消息元素类型注册表，其格式为：
CAPWAP Message Element Type Value Reference
CAPWAP消息元素类型值引用
The Wireless Binding Identifier (WBID) field in the CAPWAP Header (see Section 4.3) is used to identify the wireless technology associated with the packet. This specification allocates the values one (1) and three (3). Due to the limited address space available, a new WBID request requires Expert Review. IANA created the CAPWAP Wireless Binding Identifier registry, whose format is:
CAPWAP头中的无线绑定标识符（WBID）字段（见第4.3节）用于识别与数据包相关的无线技术。本规范分配值一（1）和三（3）。由于可用地址空间有限，新的WBID请求需要专家审查。IANA创建了CAPWAP无线绑定标识符注册表，其格式为：
CAPWAP Wireless Binding Identifier Type Value Reference
CAPWAP无线绑定标识符类型值引用
The Security field in the AC Descriptor message element (see Section 4.6.1) is 8 bits in length and is used to identify the authentication methods available on the AC. This specification defines bits five (5) and six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires Standards Action. IANA created the AC Security Types registry, whose format is:
AC描述符消息元素（见第4.6.1节）中的安全字段长度为8位，用于标识AC上可用的身份验证方法。本规范定义了第五（5）位和第六（6）位，而第零（0）位到第四（4）位以及第七（7）位是保留和未使用的。这些保留位由IANA管理，分配需要标准操作。IANA创建了AC安全类型注册表，其格式为：
AC Security Type Bit Position Reference
交流安全型位位置基准
The DTLS Policy field in the AC Descriptor message element (see Section 4.6.1) is 8 bits in length and is used to identify whether the CAPWAP Data Channel is to be secured. This specification defines bits five (5) and six (6), while bits zero (0) through four (4) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires Standards Action. IANA created the AC DTLS Policy registry, whose format is:
AC描述符消息元素（见第4.6.1节）中的DTLS策略字段长度为8位，用于标识是否保护CAPWAP数据通道。本规范定义了第五（5）位和第六（6）位，而第零（0）位到第四（4）位以及第七（7）位是保留和未使用的。这些保留位由IANA管理，分配需要标准操作。IANA创建了AC DTLS策略注册表，其格式为：
AC DTLS Policy Bit Position Reference
AC DTLS策略位位置参考
The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. This field, combined with the AC Information Vendor ID, allows vendors to use a private namespace. This specification defines the AC Information Type namespace when the AC Information Vendor ID is set to zero (0), for which the values four (4) and five (5) are allocated in this specification, and can be found in Section 4.6.1. This namespace is managed by IANA and assignments require an Expert Review. IANA created the AC Information Type registry, whose format is:
AC描述符消息元素（见第4.6.1节）中的信息类型字段用于表示有关AC的信息。名称空间为16位（0-65535），其中0（0）的值为保留值，不得分配。此字段与AC信息供应商ID相结合，允许供应商使用私有名称空间。当AC信息供应商ID设置为零（0）时，本规范定义了AC信息类型命名空间，本规范中为其分配了四（4）和五（5）个值，可在第4.6.1节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了AC信息类型注册表，其格式为：
AC Information Type Type Value Reference
AC信息类型值引用
The Transport field in the CAPWAP Transport Protocol message element (see Section 4.6.14) is used to identify the transport to use for the CAPWAP Data Channel. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be
CAPWAP传输协议消息元素（见第4.6.14节）中的传输字段用于标识CAPWAP数据通道使用的传输。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了值一（1）和值二（2），并且可以
found in Section 4.6.14. This namespace is managed by IANA and assignments require an Expert Review. IANA created the CAPWAP Transport Protocol Types registry, whose format is:
见第4.6.14节。此名称空间由IANA管理，分配需要专家审查。IANA创建了CAPWAP传输协议类型注册表，其格式为：
CAPWAP Transport Protocol Type Type Value Reference
CAPWAP传输协议类型值参考
The Data Type field in the Data Transfer Data message element (see Section 4.6.15) and Image Data message element (see Section 4.6.26) is used to provide information about the data being carried. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1), two (2), and five (5) are allocated in this specification, and can be found in Section 4.6.15. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Data Transfer Type registry, whose format is:
数据传输数据报文元素（见第4.6.15节）和图像数据报文元素（见第4.6.26节）中的数据类型字段用于提供有关所携带数据的信息。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了一（1）、二（2）和五（5）个值，可在第4.6.15节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了数据传输类型注册表，其格式为：
Data Transfer Type Type Value Reference
数据传输类型值引用
The Data Mode field in the Data Transfer Data message element (see Section 4.6.15) and Data Transfer Mode message element (see Section 15.14) is used to provide information about the data being carried. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 15.14. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Data Transfer Mode registry, whose format is:
数据传输数据报文元素（见第4.6.15节）和数据传输模式报文元素（见第15.14节）中的数据模式字段用于提供有关所携带数据的信息。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了值一（1）和值二（2），可在第15.14节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了数据传输模式注册表，其格式为：
Data Transfer Mode Type Value Reference
数据传输模式类型值引用
The Discovery Type field in the Discovery Type message element (see Section 4.6.21) is used by the WTP to indicate to the AC how it was discovered. The namespace is 8 bits (0-255). The values zero (0) through four (4) are allocated in this specification and can be found in Section 4.6.21. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Discovery Types registry, whose format is:
WTP使用发现类型消息元素（见第4.6.21节）中的发现类型字段向AC指示其发现方式。名称空间为8位（0-255）。零（0）到四（4）的值在本规范中分配，可在第4.6.21节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了发现类型注册表，其格式为：
Discovery Types Type Value Reference
发现类型类型值引用
The ECN Support field in the ECN Support message element (see Section 4.6.25) is used by the WTP to represent its ECN Support. The namespace is 8 bits (0-255). The values zero (0) and one (1) are allocated in this specification, and can be found in Section 4.6.25. This namespace is managed by IANA and assignments require an Expert Review. IANA created the ECN Support registry, whose format is:
WTP使用ECN支持消息元素（见第4.6.25节）中的ECN支持字段来表示其ECN支持。名称空间为8位（0-255）。本规范中分配了零（0）和一（1）的值，可在第4.6.25节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了ECN支持注册表，其格式为：
ECN Support Type Value Reference
ECN支持类型值引用
The Radio Admin field in the Radio Administrative State message element (see Section 4.6.33) is used by the WTP to represent the state of its radios. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.33. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Radio Admin State registry, whose format is:
WTP使用无线电管理状态消息元素（见第4.6.33节）中的无线电管理字段来表示其无线电的状态。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了值一（1）和值二（2），可在第4.6.33节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了无线电管理状态注册表，其格式为：
Radio Admin State Type Value Reference
无线电管理状态类型值引用
The State field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the operational state of its radios. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.34. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Radio Operational State registry, whose format is:
WTP使用无线电运行状态消息元素（见第4.6.34节）中的状态字段来表示其无线电的运行状态。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了值一（1）和值二（2），可在第4.6.34节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了无线电运行状态注册表，其格式为：
Radio Operational State Type Value Reference
无线电工作状态类型值参考
The Cause field in the Radio Operational State message element (see Section 4.6.34) is used by the WTP to represent the reason a radio may have failed. The namespace is 8 bits (0-255), where the value of zero (0) through three (3) are allocated in this specification, and can be found in Section 4.6.34. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Radio Failure Causes registry, whose format is:
WTP使用无线电运行状态消息元素（见第4.6.34节）中的原因字段来表示无线电可能出现故障的原因。名称空间为8位（0-255），其中零（0）到三（3）的值在本规范中分配，可在第4.6.34节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了无线电故障原因注册表，其格式为：
Radio Failure Causes Type Value Reference
无线电故障导致类型值引用
The Result Code field in the Result Code message element (see Section 4.6.35) is used to indicate the success or failure of a CAPWAP Control message. The namespace is 32 bits (0-4294967295), where the value of zero (0) through 22 are allocated in this specification, and can be found in Section 4.6.35. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Result Code registry, whose format is:
结果代码消息元素（见第4.6.35节）中的结果代码字段用于指示CAPWAP控制消息的成功或失败。名称空间为32位（0-4294967295），其中0（0）到22的值在本规范中分配，可在第4.6.35节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了结果代码注册表，其格式为：
Result Code Type Value Reference
结果代码类型值引用
The Reason field in the Returned Message Element message element (see Section 4.6.36) is used to indicate the reason why a message element was not processed successfully. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) through four (4) are allocated in this specification, and can be found in Section 4.6.36. This namespace is managed by IANA and assignments require an Expert Review. IANA created the Returned Message Element Reason registry, whose format is:
返回的消息元素消息元素（见第4.6.36节）中的原因字段用于指示消息元素未成功处理的原因。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了一（1）至四（4）个值，见第4.6.36节。此名称空间由IANA管理，分配需要专家审查。IANA创建了返回的消息元素原因注册表，其格式为：
Returned Message Element Reason Type Value Reference
返回的消息元素原因类型值引用
The Board Data Type field in the WTP Board Data message element (see Section 4.6.40) is used to represent information about the WTP hardware. The namespace is 16 bits (0-65535). The WTP Board Data Type values zero (0) through four (4) are allocated in this specification, and can be found in Section 4.6.40. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Board Data Type registry, whose format is:
WTP Board Data message元素（参见第4.6.40节）中的Board Data Type字段用于表示有关WTP硬件的信息。名称空间为16位（0-65535）。WTP板数据类型值0（0）到4（4）在本规范中分配，可在第4.6.40节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了WTP板数据类型注册表，其格式为：
WTP Board Data Type Type Value Reference
WTP板数据类型值参考
The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.41) is used to represent information about the WTP software. The namespace is 16 bits (0-65535). This field, combined with the Descriptor Vendor ID, allows vendors to use a private namespace. This specification defines the WTP Descriptor Type namespace when the Descriptor Vendor ID is set to zero (0), for which the values zero (0) through three (3) are allocated in this
WTP描述符消息元素（见第4.6.41节）中的描述符类型字段用于表示有关WTP软件的信息。名称空间为16位（0-65535）。此字段与描述符供应商ID相结合，允许供应商使用私有名称空间。当描述符供应商ID设置为零（0）时，本规范定义了WTP描述符类型命名空间，在本规范中为其分配了零（0）到三（3）的值
specification, and can be found in Section 4.6.41. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Board Data Type registry, whose format is:
规范，可在第4.6.41节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了WTP板数据类型注册表，其格式为：
WTP Descriptor Type Type Value Reference
WTP描述符类型值引用
The Mode field in the WTP Fallback message element (see Section 4.6.42) is used to indicate the type of AC fallback mechanism the WTP should employ. The namespace is 8 bits (0-255), where the value of zero (0) is reserved and must not be assigned. The values one (1) and two (2) are allocated in this specification, and can be found in Section 4.6.42. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Fallback Mode registry, whose format is:
WTP回退消息元素中的模式字段（见第4.6.42节）用于指示WTP应采用的AC回退机制的类型。名称空间是8位（0-255），其中0（0）的值是保留的，不能赋值。本规范中分配了值一（1）和值二（2），可在第4.6.42节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了WTP回退模式注册表，其格式为：
WTP Fallback Mode Type Value Reference
WTP回退模式类型值参考
The Tunnel Type field in the WTP Frame Tunnel Mode message element (see Section 4.6.43) is 8 bits and is used to indicate the type of tunneling to use between the WTP and the AC. This specification defines bits four (4) through six (6), while bits zero (0) through three (3) as well as bit seven (7) are reserved and unused. These reserved bits are managed by IANA and assignment requires an Expert Review. IANA created the WTP Frame Tunnel Mode registry, whose format is:
WTP帧隧道模式消息元素（见第4.6.43节）中的隧道类型字段为8位，用于指示WTP和AC之间使用的隧道类型。本规范定义了位四（4）到六（6），而位零（0）到三（3）以及位七（7）是保留和未使用的。这些保留位由IANA管理，分配需要专家审查。IANA创建了WTP帧隧道模式注册表，其格式为：
WTP Frame Tunnel Mode Bit Position Reference
帧隧道模式位位置参考
The MAC Type field in the WTP MAC Type message element (see Section 4.6.44) is used to indicate the type of MAC to use in tunneled frames between the WTP and the AC. The namespace is 8 bits (0-255), where the value of zero (0) through two (2) are allocated in this specification, and can be found in Section 4.6.44. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP MAC Type registry, whose format is:
WTP MAC类型消息元素（见第4.6.44节）中的MAC类型字段用于指示在WTP和AC之间的隧道帧中使用的MAC类型。命名空间为8位（0-255），其中在本规范中分配了0（0）到2（2）的值，可在第4.6.44节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了WTP MAC类型注册表，其格式为：
WTP MAC Type Type Value Reference
WTP MAC类型值引用
The Last Failure Type field in the WTP Radio Statistics message element (see Section 4.6.46) is used to indicate the last WTP failure. The namespace is 8 bits (0-255), where the value of zero (0) through three (3) as well as the value 255 are allocated in this specification, and can be found in Section 4.6.46. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Radio Stats Failure Type registry, whose format is:
WTP无线电统计信息元素（见第4.6.46节）中的最后一个故障类型字段用于指示最后一个WTP故障。名称空间为8位（0-255），其中零（0）到三（3）的值以及255的值在本规范中分配，可在第4.6.46节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了WTP无线电统计故障类型注册表，其格式为：
WTP Radio Stats Failure Type Type Value Reference
WTP无线电统计信息故障类型值参考
The Last Failure Type field in the WTP Reboot Statistics message element (see Section 4.6.47) is used to indicate the last reboot reason. The namespace is 8 bits (0-255), where the value of zero (0) through five (5) as well as the value 255 are allocated in this specification, and can be found in Section 4.6.47. This namespace is managed by IANA and assignments require an Expert Review. IANA created the WTP Reboot Stats Failure Type registry, whose format is:
WTP Reboot Statistics消息元素（参见第4.6.47节）中的Last Failure Type字段用于指示上次重新启动的原因。名称空间为8位（0-255），其中零（0）到五（5）的值以及255的值在本规范中分配，可在第4.6.47节中找到。此名称空间由IANA管理，分配需要专家审查。IANA创建了WTP重新启动统计失败类型注册表，其格式为：
WTP Reboot Stats Failure Type Type Value Reference
WTP重新启动统计信息失败类型值引用
The following individuals are acknowledged for their contributions to this protocol specification: Puneet Agarwal, Abhijit Choudhury, Pasi Eronen, Saravanan Govindan, Peter Nilsson, David Perkins, and Yong Zhang.
以下个人对本协议规范做出了贡献：Puneet Agarwal、Abhijit Choudhury、Pasi Eronen、Saravanan Govindan、Peter Nilsson、David Perkins和Yong Zhang。
Michael Vakulenko contributed text to describe how CAPWAP can be used over Layer 3 (IP/UDP) networks.
Michael Vakulenko提供的文本描述了如何在第3层（IP/UDP）网络上使用CAPWAP。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539]Aboba，B.和J.Wood，“认证、授权和会计（AAA）传输概要”，RFC 3539，2003年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[ISO.9834-1.1993] International Organization for Standardization, "Procedures for the operation of OSI registration authorities - part 1: general procedures", ISO Standard 9834-1, 1993.
[ISO.9834-1.1993]国际标准化组织，“现场视察登记机构的运作程序——第1部分：一般程序”，ISO标准9834-11993。
[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5416]Calhoun，P.，Ed.，Montemurro，M.，Ed.，和D.Stanley，Ed.，“IEEE 802.11无线接入点（CAPWAP）协议绑定的控制和供应”，RFC 5416，2009年3月。
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option", RFC 5417, March 2009.
[RFC5417]Calhoun，P.，“无线接入点（CAPWAP）接入控制器DHCP选项的控制和配置”，RFC 54172009年3月。
[FRAME-EXT] IEEE, "IEEE Standard 802.3as-2006", 2005.
[FRAME-EXT]IEEE，“IEEE标准802.3as-2006”，2005年。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC4564]Govindan，S.，Cheng，H.，Yao，ZH.，Zhou，WH.，和L.Yang，“无线接入点（CAPWAP）的控制和供应目标”，RFC 4564，2006年7月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[LWAPP] Calhoun, P., O'Hara, B., Suri, R., Cam Winget, N., Kelly, S., Williams, M., and S. Hares, "Lightweight Access Point Protocol", Work in Progress, March 2007.
[LWAPP]Calhoun，P.，O'Hara，B.，Suri，R.，Cam Winget，N.，Kelly，S.，Williams，M.，和S.Hares，“轻量级接入点协议”，正在进行的工作，2007年3月。
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP: Secure Light Access Point Protocol", Work in Progress, May 2005.
[SLAPP]Narasimhan，P.，Harkins，D.，和S.Ponnuswamy，“SLAPP：安全光接入点协议”，正在进行的工作，2005年5月。
[DTLS-DESIGN] Modadugu, et al., N., "The Design and Implementation of Datagram TLS", Feb 2004.
[DTLS-DESIGN]Modadugu等人，N.，“数据报TLS的设计和实现”，2004年2月。
[EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique Identifier", Dec 2005.
[EUI-48]IEEE，“48位扩展唯一标识符的使用指南”，2005年12月。
[EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY".
[EUI-64]IEEE，“64位全局标识符（EUI-64）注册机构指南”。
[EPCGlobal] "See http://www.epcglobalinc.org/home".
[EPCGlobal]“请参阅http://www.epcglobalinc.org/home".
[PacketCable] "PacketCable Security Specification PKT-SP-SEC-I12-050812", August 2005, <PacketCable>.
[PacketCable]“PacketCable安全规范PKT-SP-SEC-I12-050812”，2005年8月，<PacketCable>。
[CableLabs] "OpenCable System Security Specification OC-SP-SEC-I07-061031", October 2006, <CableLabs>.
[CableLabs]“OpenCable系统安全规范OC-SP-SEC-I07-061031”，2006年10月，<CableLabs>。
[WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved Specification V1.0.1", April 2008, <WiMAX>.
[WiMAX]“WiMAX论坛X.509设备证书配置文件批准规范V1.0.1”，2008年4月，<WiMAX>。
[RFC5418] Kelly, S. and C. Clancy, "Control And Provisioning for Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments", RFC 5418, March 2009.
[RFC5418]Kelly，S.和C.Clancy，“IEEE 802.11部署的无线接入点控制和配置（CAPWAP）威胁分析”，RFC 5418，2009年3月。
Editors' Addresses
编辑地址
Pat R. Calhoun (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Pat R.Calhoun（编辑）思科系统公司，加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
Phone: +1 408-902-3240
EMail: pcalhoun@cisco.com
Phone: +1 408-902-3240
EMail: pcalhoun@cisco.com
Michael P. Montemurro (editor) Research In Motion 5090 Commerce Blvd Mississauga, ON L4W 5M4 Canada
Michael P.Montemurro（编辑）Research In Motion 5090 Commerce Blvd Missisauga，位于加拿大L4W 5M4
Phone: +1 905-629-4746 x4999
EMail: mmontemurro@rim.com
Phone: +1 905-629-4746 x4999
EMail: mmontemurro@rim.com
Dorothy Stanley (editor) Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
多萝西·斯坦利（编辑）阿鲁巴网络公司加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089
Phone: +1 630-363-1389
EMail: dstanley@arubanetworks.com
Phone: +1 630-363-1389
EMail: dstanley@arubanetworks.com