Independent Submission P. Narasimhan
Request for Comments: 5413 D. Harkins
Category: Historic S. Ponnuswamy
ISSN: 2070-1721 Aruba Networks
February 2010
Independent Submission P. Narasimhan
Request for Comments: 5413 D. Harkins
Category: Historic S. Ponnuswamy
ISSN: 2070-1721 Aruba Networks
February 2010
SLAPP: Secure Light Access Point Protocol
SLAPP：安全光接入点协议
Abstract
摘要
The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.
无线接入点的控制和配置（CAPWAP）问题陈述描述了无线LAN（WLAN）网络设计师在构建由多个不同供应商的无线终端点（WTP）和接入控制器（AC）组成的解决方案之前需要解决的问题。主要目标之一是找到解决两类设备（WTP和ACs）之间互操作性的解决方案，从而使一家供应商的AC能够控制和管理另一家供应商的WTP。
In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.
在本文档中，我们提出了一个协议，该协议构成了通用的独立于技术的框架，并且能够在该框架的基础上协商和添加一个控制协议，该协议包含一个依赖于技术的组件，以获得完整的解决方案。在本文中，我们还介绍了两种这样的控制协议——802.11控制协议和另一种更通用的图像下载协议。
Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP).
尽管本文档中的文本是专门针对RFC 3990中所述的问题编写的，但该解决方案可应用于控制器（相当于AC）管理一个或多个网元（相当于WTP）的任何问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档定义了互联网社区的历史文档。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5413.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5413.
IESG Note
IESG注释
This RFC documents the SLAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP Working Group, and therefore it may resemble the CAPWAP protocol specification in RFC 5415 as well as other IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions.
本RFC记录了SLAPP协议提交给IETF时的状态，作为CAPWAP工作组进一步工作的基础，因此可能类似于RFC 5415中的CAPWAP协议规范以及其他IETF工作。本RFC仅为历史记录而发布。本RFC中描述的协议未经彻底审查，可能包含错误和遗漏。
RFC 5415 documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of Internet deployment.
RFC 5415记录了CAPWAP工作组的标准跟踪解决方案，并废除了本RFC中定义的所有机制。此RFC不适用于任何级别的Internet标准，不应用作任何类型Internet部署的基础。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http//:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定（http/：truster.IETF.org/license info）的约束，这些法律规定在本文件出版之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
2. Definitions .....................................................7
2.1. Conventions Used in This Document ..........................7
3. Topology ........................................................7
4. Protocol ........................................................8
4.1. Protocol Description .......................................8
4.1.1. State Machine Explanation ...........................9
4.2. Format of a SLAPP Header ..................................10
4.3. Version ...................................................11
4.4. Retransmission ............................................12
4.5. Discovery .................................................12
4.5.1. SLAPP Discover Request .............................13
4.5.2. SLAPP Discover Response ............................15
4.6. SLAPP Discovery Process ...................................17
4.6.1. WTP ................................................17
4.6.2. AC .................................................19
5. Security Association ...........................................19
5.1. Example Authentication Models (Informative) ...............20
5.1.1. Mutual Authentication ..............................20
5.1.2. WTP-Only Authentication ............................21
5.1.3. Anonymous Authentication ...........................21
6. SLAPP Control Protocols ........................................21
6.1. 802.11 Control Protocol for SLAPP .........................21
6.1.1. Supported CAPWAP Architectures .....................21
6.1.2. Transport ..........................................24
6.1.3. Provisioning and Configuration of WTP ..............26
6.1.4. Protocol Operation .................................60
6.2. Image Download Protocol ...................................66
6.2.1. Image Download Packet ..............................66
6.2.2. Image Download Request .............................67
6.2.3. Image Download Process .............................68
6.2.4. Image Download State Machine .......................69
7. Security Considerations ........................................73
8. Extensibility to Other Technologies ............................73
9. Informative References .........................................74
1. Introduction ....................................................4
2. Definitions .....................................................7
2.1. Conventions Used in This Document ..........................7
3. Topology ........................................................7
4. Protocol ........................................................8
4.1. Protocol Description .......................................8
4.1.1. State Machine Explanation ...........................9
4.2. Format of a SLAPP Header ..................................10
4.3. Version ...................................................11
4.4. Retransmission ............................................12
4.5. Discovery .................................................12
4.5.1. SLAPP Discover Request .............................13
4.5.2. SLAPP Discover Response ............................15
4.6. SLAPP Discovery Process ...................................17
4.6.1. WTP ................................................17
4.6.2. AC .................................................19
5. Security Association ...........................................19
5.1. Example Authentication Models (Informative) ...............20
5.1.1. Mutual Authentication ..............................20
5.1.2. WTP-Only Authentication ............................21
5.1.3. Anonymous Authentication ...........................21
6. SLAPP Control Protocols ........................................21
6.1. 802.11 Control Protocol for SLAPP .........................21
6.1.1. Supported CAPWAP Architectures .....................21
6.1.2. Transport ..........................................24
6.1.3. Provisioning and Configuration of WTP ..............26
6.1.4. Protocol Operation .................................60
6.2. Image Download Protocol ...................................66
6.2.1. Image Download Packet ..............................66
6.2.2. Image Download Request .............................67
6.2.3. Image Download Process .............................68
6.2.4. Image Download State Machine .......................69
7. Security Considerations ........................................73
8. Extensibility to Other Technologies ............................73
9. Informative References .........................................74
The need for a protocol by which wireless LAN (WLAN) Access Controllers (ACs) can control and manage Wireless Termination Points (WTPs) from a different vendor has been presented in the CAPWAP problem statement [3]. We believe that this problem is more general than as stated in [3] and can be found in any application, including non-wireless ones, that requires a central controller to control and manage one or more network elements from a different vendor.
CAPWAP问题陈述[3]中提出了需要一种协议，通过该协议，无线LAN（WLAN）访问控制器（ACs）可以控制和管理来自不同供应商的无线终端点（WTP）。我们认为，该问题比[3]中所述的更为普遍，并且可以在任何应用中发现，包括需要中央控制器控制和管理来自不同供应商的一个或多个网络元件的非无线应用。
One way to solve the CAPWAP problem is to define a complete control protocol that enables an AC from one vendor to control and manage a WTP from a different vendor. But a solution that is primarily focused towards solving the problem for one particular underlying technology (IEEE 802.11, in this case) may find it difficult to address other underlying technologies. Different underlying technologies may differ on the set of configurable options, and different architectural choices that are specific to that underlying technology (similar to the Local Medium Access Control (MAC) versus Split MAC architectures in 802.11). The architectural choices that are good for one underlying technology may not necessarily work for another. Not to forget that there may be multiple architectural choices [2] even for the same underlying technology. A monolithic control protocol that strives to solve this problem for multiple technologies runs the risk of adding too much complexity and not realizing the desired goals, or it runs the risk of being too rigid and hampering technological innovation.
解决CAPWAP问题的一种方法是定义一个完整的控制协议，使一个供应商的AC能够控制和管理另一个供应商的WTP。但是，一个主要集中于解决某一特定底层技术（本例中为IEEE 802.11）问题的解决方案可能会发现很难解决其他底层技术。不同的底层技术可能在可配置选项集上有所不同，以及特定于该底层技术的不同体系结构选择（类似于802.11中的本地媒体访问控制（MAC）与分割MAC体系结构）。对一种底层技术有利的体系结构选择可能不一定适用于另一种技术。不要忘记，即使对于相同的底层技术，也可能有多种体系结构选择[2]。致力于为多种技术解决这一问题的单片控制协议存在增加太多复杂性和无法实现预期目标的风险，或者存在过于僵化和阻碍技术创新的风险。
A different way to solve this problem is to split the solution space into two components -- one that is technology-agnostic or independent, and another that is specific to the underlying technology or even different approaches to the same underlying technology. The technology-independent component would be a common framework that would be an important component of the solution to this class of problems without any dependency on the underlying technology (i.e., 802.11, 802.16, etc.) being used. The technology-specific component would be a control protocol that would be negotiated using this common framework and can be easily defined to be relevant to that technology without the need for having any dependency on other underlying technologies. This approach also lends itself easily to extend the solution as new technologies arise or as new innovative methods to solve the same problem for an existing technology present themselves in the future.
解决这个问题的另一种方法是将解决方案空间分成两个部分——一个是技术不可知的或独立的，另一个是特定于底层技术的，甚至是相同底层技术的不同方法。独立于技术的组件将是一个公共框架，它将是此类问题解决方案的一个重要组件，而不依赖于所使用的底层技术（即802.11、802.16等）。特定于技术的组件将是一个控制协议，该协议将使用此通用框架进行谈判，并且可以轻松定义为与该技术相关，而无需依赖其他基础技术。随着新技术的出现或新的创新方法的出现，这种方法也很容易扩展解决方案，以解决未来现有技术的相同问题。
In this document, we present secure light access point protocol (SLAPP), a technology-independent protocol by which network elements that are meant to be centrally managed by a controller can discover one or more controllers, perform a security association with one of
在本文档中，我们介绍了安全光接入点协议（SLAPP），这是一种独立于技术的协议，通过该协议，拟由控制器集中管理的网络元素可以发现一个或多个控制器，并与其中一个执行安全关联
them, and negotiate a control protocol that they would use to perform the technology-specific components of the control and provisioning protocol. We have also presented two control protocols in this document -- an 802.11 control protocol for provisioning and managing a set of 802.11 WTPs, and an image download protocol that is very generic and can be applied to any underlying technology.
并协商一个控制协议，用于执行控制和供应协议的特定于技术的组件。在本文档中，我们还介绍了两个控制协议——一个用于提供和管理一组802.11 WTP的802.11控制协议，以及一个非常通用且可应用于任何底层技术的图像下载协议。
Figure 1 shows the model by which a technology-specific control protocol can be negotiated using SLAPP to complete a solution for a certain underlying technology. The figure shows a control protocol for 802.11 and 802.16 technology components, but the SLAPP model does not preclude multiple control protocols within a certain technology segment. For example, a certain technology-specific control protocol may choose to support only the Local MAC architecture [2] while deciding not to support the Split MAC architecture [2]. While the image download protocol is presented in this document, a SLAPP implementation MUST NOT assume that this control protocol is supported by other SLAPP implementations.
图1显示了一个模型，通过该模型，可以使用SLAPP协商特定于技术的控制协议，以完成特定底层技术的解决方案。该图显示了802.11和802.16技术组件的控制协议，但SLAP模型并不排除特定技术段内的多个控制协议。例如，特定于技术的控制协议可以选择仅支持本地MAC架构[2]，而决定不支持分割MAC架构[2]。虽然本文档中介绍了映像下载协议，但SLAPP实现不能假定其他SLAPP实现支持此控制协议。
Negotiated SLAPP Control Protocol
协商SLAP控制协议
+-------------------------+ +------------+
| | | |
| SLAPP | | Image |
| (technology-independent +-------+----->| Download |
| framework) | | | protocol |
| | | | |
| negotiate one control | | +------------+
| protocol here | |
+-------------------------+ |
| +------------+
| | |
| | 802.11 |
+----->| control |
| | protocol |
| | |
| +------------+
|
|
| +------------+
| | |
| | 802.16 |
+----->| control |
| | protocol |
| | |
| +------------+
|
| .......
+-------------------------+ +------------+
| | | |
| SLAPP | | Image |
| (technology-independent +-------+----->| Download |
| framework) | | | protocol |
| | | | |
| negotiate one control | | +------------+
| protocol here | |
+-------------------------+ |
| +------------+
| | |
| | 802.11 |
+----->| control |
| | protocol |
| | |
| +------------+
|
|
| +------------+
| | |
| | 802.16 |
+----->| control |
| | protocol |
| | |
| +------------+
|
| .......
Figure 1: SLAPP Protocol Model
图1:SLAPP协议模型
The control protocols that are negotiable using SLAPP are expected to be published ones that have gone through a review process in standards bodies such as the IETF. The control protocols can either re-use the security association created during SLAPP or have the option of clearing all SLAPP state and restarting with whatever mechanisms are defined in the control protocol.
使用SLAPP可协商的控制协议预计将在IETF等标准机构中通过审查程序发布。控制协议可以重新使用在SLAPP期间创建的安全关联，也可以选择清除所有SLAPP状态并使用控制协议中定义的任何机制重新启动。
Recently, there was a significant amount of interest in a similar problem in the Radio Frequency Identification (RFID) space that has led to the definition of a simple lightweight RFID reader protocol (SLRRP) [9]. It is quite possible that SLRRP could be a technology-specific (RFID, in this case) control protocol negotiated during a common technology-independent framework.
最近，人们对射频识别（RFID）领域的一个类似问题产生了极大的兴趣，该问题导致了一个简单的轻量级RFID阅读器协议（SLRRP）[9]的定义。SLRRP很可能是一种特定于技术（在本例中为RFID）的控制协议，在通用的独立于技术的框架中进行协商。
All of the text in the document would seem to be written with a WLAN problem in mind. Please note that while the letter of the document does position the solution to solve a CAPWAP-specific problem, the spirit of the document is to address the more general problem.
文档中的所有文本似乎都是在考虑无线局域网问题的情况下编写的。请注意，虽然本文件的信函确实提出了解决CAPWAP特定问题的解决方案，但本文件的精神是解决更一般的问题。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The SLAPP protocol supports multiple topologies for interconnecting WTPs and ACs as indicated in Figure 2.
如图2所示，SLAPP协议支持多种拓扑，用于互连WTP和ACs。
In Figure 2, we have captured four different interconnection topologies:
在图2中，我们捕获了四种不同的互连拓扑：
1. The WTP is directly connected to the AC without any intermediate nodes. Many WTPs are deployed in the plenum of buildings and are required to be powered over the Ethernet cable that is connecting it to the network. Many ACs in the marketplace can supply power over Ethernet, and in the case where the AC is the one powering the WTP, the WTP is directly connected to the AC.
1. WTP直接连接到AC，无需任何中间节点。许多WTP部署在建筑物的正压室内，需要通过连接到网络的以太网电缆供电。市场上的许多AC都可以通过以太网供电，在AC为WTP供电的情况下，WTP直接连接到AC。
2. The WTP is not directly connected to the AC, but both the AC and the WTP are in the same Layer 2 (L2) (broadcast) domain.
2. WTP不直接连接到AC，但AC和WTP都在同一层2（L2）（广播）域中。
3. The WTP is not directly connected to the AC, and they are not present in the same L2 (broadcast) domain. They are on two different broadcast domains and have a node on the path that routes between two or more subnets.
3. WTP不直接连接到AC，并且它们不在同一L2（广播）域中。它们位于两个不同的广播域上，在两个或多个子网之间路由的路径上有一个节点。
4. The fourth case is a subset of the third one with the exception that the intermediate nodes on the path from the WTP to the AC may not necessarily be in the same administrative domain. The intermediate network may also span one or more WAN links that may have lower capacity than if both the AC and the WTP are within the same building or campus.
4. 第四种情况是第三种情况的子集，但从WTP到AC的路径上的中间节点不一定在同一管理域中。中间网络还可以跨越一个或多个WAN链路，与AC和WTP位于同一建筑或校园内相比，这些WAN链路的容量可能更低。
+-----------------+ +-------+
| | (1) | |
| AC +------------+ WTP |
| | | |
+--------+--------+ +-------+
|
|
|
+---+---+
(2) | |
+------+ L2 +--------+
| | | |
| +---+---+ |
| |
| |
+-----+-----+ +---+---+ +-------+
| | | | (3)| |
| WTP | | L3 +----+ WTP |
| | | | | |
+-----------+ +---+---+ +-------+
|
|
|
+---+----+ +-------+
| | (4)| |
|Internet+----+ WTP |
| | | |
+--------+ +-------+
+-----------------+ +-------+
| | (1) | |
| AC +------------+ WTP |
| | | |
+--------+--------+ +-------+
|
|
|
+---+---+
(2) | |
+------+ L2 +--------+
| | | |
| +---+---+ |
| |
| |
+-----+-----+ +---+---+ +-------+
| | | | (3)| |
| WTP | | L3 +----+ WTP |
| | | | | |
+-----------+ +---+---+ +-------+
|
|
|
+---+----+ +-------+
| | (4)| |
|Internet+----+ WTP |
| | | |
+--------+ +-------+
Figure 2: SLAPP Topology
图2:SLAPP拓扑
The SLAPP state machine for both the WTP and AC is shown in Figure 3. Both the WTP and the AC discover each other, negotiate a control protocol, perform a secure handshake to establish a secure channel between them, and then use that secure channel to protect a Negotiated Control Protocol.
WTP和AC的SLAPP状态机如图3所示。WTP和AC彼此发现，协商控制协议，执行安全握手以在它们之间建立安全通道，然后使用该安全通道保护协商的控制协议。
The WTP maintains the following variable for its state machine:
WTP为其状态机维护以下变量：
abandon: a timer that sets the maximum amount of time the WTP will wait for an acquired AC to begin the Datagram Transport Layer Security (DTLS) handshake.
放弃：设置WTP等待获取的AC开始数据报传输层安全（DTLS）握手的最长时间的计时器。
/--------\ /-----------\
| | | |
| v v |
| +-------------+ |
| C| discovering |<-\ |
| +-------------+ | |
| | | |
| v | |
| +-----------+ | |
\--| acquiring | | |
+-----------+ | |
| | |
v | |
+----------+ | |
C| securing |-----/ |
+----------+ |
| |
v |
+----------------+ |
| negotiated | |
C| control |-----/
| protocol |
+----------------+
/--------\ /-----------\
| | | |
| v v |
| +-------------+ |
| C| discovering |<-\ |
| +-------------+ | |
| | | |
| v | |
| +-----------+ | |
\--| acquiring | | |
+-----------+ | |
| | |
v | |
+----------+ | |
C| securing |-----/ |
+----------+ |
| |
v |
+----------------+ |
| negotiated | |
C| control |-----/
| protocol |
+----------------+
Figure 3: SLAPP State Machine
图3:SLAPP状态机
Note: The symbol "C" indicates an event that results in the state remaining the same.
注：符号“C”表示导致状态保持不变的事件。
Discovering
发现
AC: This is a quiescent state for the AC in which it waits for WTPs to request its acquisition. When a request is received, the AC transitions to Acquiring.
AC：这是AC的静态状态，在此状态下，它等待WTP请求采集。当收到请求时，AC转换为获取。
WTP: The WTP is actively discovering an AC. When the WTP receives a response to its Discover Request, it transitions to Acquiring.
WTP：WTP正在主动发现AC。当WTP收到对其发现请求的响应时，它将转换为获取。
Acquiring
获取
AC: A discover request from a WTP has been received. If the request is invalid or the AC wishes to not acquire the WTP, it drops the packet and transitions back to Discovering. Otherwise, a Discover Response is sent and the AC transitions to Securing.
AC：已收到来自WTP的发现请求。如果请求无效或AC希望不获取WTP，它将丢弃数据包并转换回发现。否则，将发送一个Discover响应，AC将转换为security。
WTP: A discover response from an AC has been received. If the response is not valid, the WTP transitions to Discovering; otherwise, it sets the abandon timer to a suitable value to await a DTLS exchange. If the timer fires in Acquiring, the WTP transitions back to Discovering. If a DTLS "client hello" is received, the WTP transitions to Securing and cancels the abandon timer.
WTP：已收到来自AC的发现响应。如果响应无效，WTP将转换为发现；否则，它会将放弃计时器设置为合适的值，以等待DTLS交换。如果计时器在获取时触发，WTP将转换回发现。如果收到DTLS“client hello”，WTP将转换为安全并取消放弃计时器。
Securing
确保
AC: The AC performs the "client end" of the DTLS exchange. Any error in the DTLS exchange results in the AC transitioning to Discovering. When the DTLS exchange finishes, the AC transitions to the Negotiated Control Protocol.
AC：AC执行DTLS交换的“客户端”。DTLS交换中的任何错误都会导致AC转换为发现。DTLS交换完成后，AC转换到协商控制协议。
WTP: The WTP performs the "server end" of the DTLS exchange. Any error in the DTLS exchange results in the WTP transitioning to Discovering. When the DTLS exchange finishes, the WTP transitions to the Negotiated Control Protocol.
WTP：WTP执行DTLS交换的“服务器端”。DTLS交换中的任何错误都会导致WTP转换为发现。DTLS交换完成后，WTP转换到协商控制协议。
Negotiated Control Protocol
协商控制协议
AC: The AC performs its side of the protocol agreed to during the discovery process. Please refer to Section 6.1 for the SLAPP 802.11 Control Protocol. For the Image Download Protocol example, see Section 6.2.
AC：AC执行其在发现过程中同意的协议。请参阅第6.1节了解SLAPP 802.11控制协议。有关图像下载协议示例，请参见第6.2节。
WTP: The WTP performs its side of the protocol agreed to during the discovery process. Please refer to Section 6.1 for the SLAPP 802.11 Control Protocol. For the Image Download Protocol example, see Section 6.2.
WTP：WTP执行其在发现过程中同意的协议。请参阅第6.1节了解SLAPP 802.11控制协议。有关图像下载协议示例，请参见第6.2节。
All SLAPP packets begin with the same header as shown in Figure 4.
所有SLAP数据包都以相同的头开始，如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SLAPP Header
图4:SLAPP标题
Where:
哪里：
Maj (4 bits): the major number of the SLAPP version
Maj（4位）：SLAPP版本的主要编号
Min (4 bits): the minor number of the SLAPP version
最小值（4位）：SLAPP版本的次编号
Type (1 octet): the type of SLAPP message
类型（1个八位组）：SLAPP消息的类型
Length (two octets): the length of the SLAPP message, including the entire SLAPP header
长度（两个八位字节）：SLAPP消息的长度，包括整个SLAPP头
The following types of SLAPP messages have been defined:
已定义以下类型的SLAP消息：
name type
----- ------
discover request 1
discover response 2
image download control 3
control protocol packet 4
reserved 5-255
name type
----- ------
discover request 1
discover response 2
image download control 3
control protocol packet 4
reserved 5-255
SLAPP messages include a version in the form of major.minor. This document describes the 1.0 version of SLAPP, that is the major version is one (1) and the minor version is zero (0).
SLAPP消息包括一个major.minor形式的版本。本文档描述了SLAPP的1.0版本，即主版本为一（1），次版本为零（0）。
Major versions are incremented when the format of a SLAPP message changes or the meaning of a SLAPP message changes such that it would not be properly parsed by an older, existing version of SLAPP. Minor versions are incremented when some incremental additions have been made to SLAPP that enhance its capabilities or convey additional information in a way that does not change the format or meaning of the SLAPP message.
当SLAPP消息的格式更改或SLAPP消息的含义更改时，主版本将增加，从而导致旧版本的SLAPP无法正确解析该消息。如果对SLAPP进行了一些增量添加，以增强其功能或以不改变SLAPP消息格式或含义的方式传递附加信息，则次要版本将增加。
Future versions of SLAPP MAY NOT mandate support for earlier major versions of SLAPP, so an implementation MUST NOT assume that a peer that supports version "n" will therefore support version "n - i" (where both "n" and "i" are non-zero integers and "n" is greater than "i").
SLAPP的未来版本可能不会强制支持SLAPP的早期主要版本，因此实现不能假设支持版本“n”的对等方将因此支持版本“n-i”（其中“n”和“i”都是非零整数，“n”大于“i”）。
A SLAPP implementation that receives a SLAPP message with a higher major version number MUST drop that message. A SLAPP implementation that receives a SLAPP message with a lower major version SHOULD drop down to the version of SLAPP the peer supports. If that version of SLAPP is not supported, the message MUST be dropped. However, there may be valid reasons for which a peer wishes to drop a SLAPP message with a supported major version.
接收具有更高主版本号的SLAPP消息的SLAPP实现必须删除该消息。接收主版本较低的SLAPP消息的SLAPP实现应下降到对等方支持的SLAPP版本。如果不支持该版本的SLAPP，则必须删除该消息。但是，对等方希望删除具有支持的主要版本的SLAPP消息可能有正当的原因。
A SLAPP implementation that receives a SLAPP message with a higher minor version number MUST NOT drop that message. It MUST respond with the minor version number that it supports and will necessarily
接收具有较高次要版本号的SLAPP消息的SLAPP实现不得删除该消息。它必须响应它支持的次要版本号，并且必须
not support whatever incremental capabilities were added that justified the bump in the minor version. A SLAPP implementation that receives a SLAPP message with a lower minor version MUST NOT drop that message. It SHOULD revert back to the minor version that the peer supports and not include any incremental capabilities that were added that justified the bump in the minor version.
不支持在次要版本中添加的任何增量功能。接收具有较低次要版本的SLAPP消息的SLAPP实现不得删除该消息。它应该恢复到对等方支持的次要版本，并且不包括在次要版本中添加的任何增量功能。
SLAPP is a request response protocol. Discovery and security handshake requests are made by the WTP, and responses to them are made by the AC. Image Download packets are initiated by the AC and acknowledged by the WTP (in a negative fashion, see Section 6.2).
SLAPP是一种请求-响应协议。发现和安全握手请求由WTP发出，并由AC作出响应。图像下载数据包由AC发起并由WTP确认（以否定方式，见第6.2节）。
Retransmissions are handled solely by the initiator of the packet. After each packet for which a response is required is transmitted, the sender MUST set a retransmission timer and resend the packet upon its expiry. The receiver MUST be capable of either regenerating a previous response upon receipt of a retransmitted packet or caching a previous response and resending upon receipt of a retransmitted packet.
重传仅由数据包的发起方处理。在发送每个需要响应的数据包之后，发送方必须设置重传计时器，并在数据包到期时重新发送数据包。接收器必须能够在接收到重新传输的数据包时重新生成先前的响应，或者缓存先前的响应并在接收到重新传输的数据包时重新发送。
The retransmission timer MUST be configurable and default to one (1) second. No maximum or minimum for the timer is specified by this version of SLAPP.
重传计时器必须是可配置的，默认为一（1）秒。此版本的SLAPP未指定计时器的最大值或最小值。
Each time a retransmission is made, a counter SHOULD be incremented, and the number of retransmissions attempted by a sender before giving up and declaring a SLAPP failure SHOULD be four (4)-- that is, the number of attempts made for each packet before declaring failure is five (5).
每次进行重新传输时，计数器应递增，并且发送方在放弃并声明SLAPP失败之前尝试的重新传输次数应为四（4）——也就是说，在声明失败之前对每个数据包进行的尝试次数为五（5）。
The exception to this rule is Image Download packets, which are not individually acknowledged by the WTP (see Section 6.2). The final packet is acknowledged and lost packets are indicated through Image Download Requests.
此规则的例外是图像下载数据包，WTP未单独确认这些数据包（见第6.2节）。最后的数据包被确认，丢失的数据包通过图像下载请求指示。
When a WTP boots up and wants to interoperate with an Access Controller so that it can be configured by the AC, one of the first things it needs to do is to discover one or more ACs in its network neighborhood. This section contains the details of this discovery mechanism.
当WTP启动并希望与访问控制器进行互操作以便AC可以对其进行配置时，它首先需要做的事情之一是在其网络邻居中发现一个或多个AC。本节包含此发现机制的详细信息。
As described in Section 3, an AC and a WTP could reside in the same Layer 2 domain, or be separated by a Layer 3 cloud including intermediate clouds that are not under the same administrative domain
如第3节所述，AC和WTP可以位于相同的第2层域中，或者由第3层云（包括不在同一管理域下的中间云）分隔
(for example, an AC and a WTP separated by a wide-area public network). So any proposed discovery mechanism should have provisions to enable a WTP to discover an AC across all these topologies.
（例如，由广域公共网络分隔的AC和WTP）。因此，任何建议的发现机制都应该具有使WTP能够跨所有这些拓扑发现AC的规定。
We assume that a WTP, prior to starting the discovery process, has already obtained an IP address on its wired segment.
我们假设WTP在开始发现过程之前已经在其有线网段上获得了IP地址。
The SLAPP discovery process is initiated by sending a SLAPP discover request packet. The packet can be addressed to the broadcast IP address, a well-known multicast address, or (if the IP address of an AC is either configured prior to the WTP booting up or is learned during the boot-up sequence) addressed to a unicast IP address. Lack of a response to one method of discovery SHOULD result in the WTP trying another method of discovery. The SLAPP discover request packet is a UDP packet addressed to port [TBD] designated as the SLAPP discovery port. The source port can be any random port. The payload of the SLAPP discover request packet is shown in Figure 5.
SLAPP发现过程通过发送SLAPP发现请求数据包来启动。该分组可以被寻址到广播IP地址、众所周知的多播地址，或者（如果AC的IP地址在WTP引导之前被配置或者在引导序列期间被读入）寻址到单播IP地址。对一种发现方法缺乏响应应导致WTP尝试另一种发现方法。SLAPP发现请求数据包是一个UDP数据包，地址为指定为SLAPP发现端口的端口[TBD]。源端口可以是任意随机端口。SLAPP discover请求包的有效负载如图5所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n controltypes| control 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n controltypes| control type | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SLAPP Discover Request
Figure 5: SLAPP Discover Requesttranslate error, please retry
The transaction ID is a randomly generated, 32-bit number that is maintained during one phase of the SLAPP discovery process. It is generated by a WTP starting a discovery process. When one discovery method fails to find an AC and the WTP attempts another discovery
事务ID是一个随机生成的32位数字，在SLAP发现过程的一个阶段中进行维护。它由启动发现过程的WTP生成。当一种发现方法无法找到AC且WTP尝试另一种发现时
method it MUST NOT re-use the Transaction ID. All ACs that intend to respond to a SLAPP discover request must use the same value for this field as in the request frame.
方法它不能重复使用事务ID。所有打算响应SLAPP discover请求的AC必须使用与请求帧中相同的此字段值。
This field allows the WTP to specify a unique identifier for itself. This MAY be, for instance, its 48-bit MAC address or it could be any other string such as a serial number.
此字段允许WTP为自己指定唯一标识符。例如，这可能是其48位MAC地址，也可能是任何其他字符串，如序列号。
The Flags field is used to indicate certain things about the discover request. For example, bit 0 in the Flags field indicates whether the discover request packet is being sent to the AC, if unicast, based on a configuration at the WTP or based on some other means of discovery. This bit should always be set to the discover mode if the SLAPP discover request packet is being sent to either a broadcast or multicast address. Here are the valid values for various bits in the Flags field.
Flags字段用于指示有关discover请求的某些内容。例如，Flags字段中的位0指示基于WTP处的配置或基于某些其他发现手段，如果是单播，则发现请求分组是否正在发送到AC。如果SLAPP discover请求数据包被发送到广播或多播地址，则该位应始终设置为discover模式。以下是标志字段中各种位的有效值。
Bit 0: 0 - Configuration mode 1 - Discover mode
位0:0-配置模式1-发现模式
Bits 1-15: Must always be set to 0 by the transmitter Must be ignored by the receiver
位1-15：发射机必须始终设置为0，接收机必须忽略
This 32-bit field is the WTP vendor's Structure of Management Information (SMI) enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA).
此32位字段是WTP供应商的管理信息（SMI）企业代码结构，按网络八位字节顺序排列（这些企业代码可从IANA获得并注册）。
This 32-bit field indicates the version of hardware present in the WTP. This is a number that is totally left to the WTP vendor to choose.
此32位字段表示WTP中存在的硬件版本。这是一个完全由WTP供应商选择的数字。
This 32-bit field indicates the version of software present in the WTP. This is a number that is totally left to the WTP vendor to choose.
此32位字段表示WTP中存在的软件版本。这是一个完全由WTP供应商选择的数字。
This 8-bit field indicates the number of 8-bit control protocol indicators that follow it and therefore implicitly indicates the number of different control protocols the WTP is capable of supporting. This number MUST be at least one (1).
此8位字段指示其后面的8位控制协议指示器的数量，因此隐式指示WTP能够支持的不同控制协议的数量。此数字必须至少为一（1）。
This 8-bit field indicates the type of control protocol the WTP supports and is willing to use when communicating with an AC. There MAY be multiple "control type" indicators in a single SLAPP Discover Request.
此8位字段表示WTP支持并愿意在与AC通信时使用的控制协议类型。单个SLAPP发现请求中可能有多个“控制类型”指示器。
Valid Control Types
-------------------
0 - RESERVED (MUST not be used)
1 - Image Download Control Protocol
2 - 802.11 SLAPP Control Protocol
3-255 - RESERVED (to IANA)
Valid Control Types
-------------------
0 - RESERVED (MUST not be used)
1 - Image Download Control Protocol
2 - 802.11 SLAPP Control Protocol
3-255 - RESERVED (to IANA)
An AC that receives a SLAPP discover request packet from a WTP can choose to respond with a SLAPP discover response packet. The format of the SLAPP discover response packet is shown in Figure 6.
从WTP接收SLAPP discover请求数据包的AC可以选择使用SLAPP discover响应数据包进行响应。SLAPP discover响应包的格式如图6所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| control 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| control type |
+-+-+-+-+-+-+-+-+
Figure 6: SLAPP Discover Response
图6:SLAPP发现响应
The SLAPP discover response packet is a UDP packet. It is always unicast to the WTP's IP address. The source IP address is that of the AC sending the response. The source port is the SLAPP discover port [TBD] and the destination port is the same as the source port used in the SLAPP discover request. The WTP's MAC address and the transaction ID must be identical to the values contained in the SLAPP discover request. The Status field indicates to the WTP whether the AC is either accepting the discover request and is willing to allow the WTP to proceed to the next stage (ACK) or whether it is denying the WTP's earlier request (NACK). The AC includes its own vendor ID, hardware, and software versions in the response.
SLAPP发现响应数据包是UDP数据包。它总是单播到WTP的IP地址。源IP地址是发送响应的AC的IP地址。源端口是SLAPP discover端口[TBD]，目标端口与SLAPP discover请求中使用的源端口相同。WTP的MAC地址和事务ID必须与SLAPP discover请求中包含的值相同。状态字段向WTP指示AC是否接受发现请求并愿意允许WTP进入下一阶段（ACK）或是否拒绝WTP的早期请求（NACK）。AC在响应中包括其自己的供应商ID、硬件和软件版本。
The value of the Transaction ID field should be identical to its value in the SLAPP discover request packet sent by the WTP.
事务ID字段的值应与WTP发送的SLAPP discover请求数据包中的值相同。
The WTP Identifier that was sent in the corresponding SLAPP discover request frame.
在相应的SLAP discover请求帧中发送的WTP标识符。
This field is unused by this version of SLAPP. It MUST be set to zero (0) on transmission and ignored upon receipt.
此版本的SLAPP未使用此字段。传输时必须将其设置为零（0），并在接收时忽略。
If the value of the Status field is a 1, indicating that the AC is sending a successful response, then the values in this field and the following two are valid. The 32-bit AC Vendor ID points to the vendor ID of the AC. If the value of the Status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP.
如果状态字段的值为1，表示AC正在发送成功响应，则此字段和以下两个字段中的值有效。32位AC供应商ID指向AC的供应商ID。如果状态字段的值不是1，则AC应将该字段设置为0，WTP将忽略该字段。
If the value of the Status field is 1, then this 32-bit field contains the value of the AC's hardware version. This value is chosen by the AC vendor. If the value of the Status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP.
如果状态字段的值为1，则此32位字段包含AC硬件版本的值。该值由AC供应商选择。如果状态字段的值不是1，则AC应将该字段设置为0，WTP应忽略该字段。
If the value of the Status field is 1, then this 32-bit field contains the value of the AC's software version. This value is chosen by the AC vendor. If the value of the Status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP.
如果状态字段的值为1，则此32位字段包含AC软件版本的值。该值由AC供应商选择。如果状态字段的值不是1，则AC应将该字段设置为0，WTP应忽略该字段。
The control type that the AC will use to communicate with the WTP. This value MUST match one of the control types passed in the corresponding SLAPP Discover Request.
AC将用于与WTP通信的控制类型。此值必须与相应的SLAPP Discover请求中传递的控件类型之一匹配。
There are multiple ways in which a WTP can discover an AC.
WTP可以通过多种方式发现AC。
1. Static configuration: An administrator, prior to deploying a WTP, can configure an IP address of an AC on the WTP's non-volatile memory. If this is the case, then the SLAPP discover request packet is addressed to the configured IP address.
1. 静态配置：在部署WTP之前，管理员可以在WTP的非易失性内存上配置AC的IP地址。如果是这种情况，则SLAPP discover请求数据包将寻址到配置的IP地址。
2. DHCP options: As part of the DHCP response, the DHCP server could be configured to use option 43 to deliver the IP address of an AC to which the WTP should address the SLAPP discover request packet. If the IP address of an AC is handed to the WTP as part of the DHCP response, then the WTP should address the SLAPP discover request packet to this IP address.
2. DHCP选项：作为DHCP响应的一部分，DHCP服务器可以配置为使用选项43来传递WTP应将SLAPP发现请求数据包寻址到的AC的IP地址。如果AC的IP地址作为DHCP响应的一部分传递给WTP，则WTP应将SLAPP discover请求数据包寻址到此IP地址。
3. DNS configuration: Instead of configuring a static IP address on the WTP's non-volatile memory, an administrator can configure a Fully-Qualified Domain Name (FQDN) of an AC. If the FQDN of an AC is configured, then the WTP queries its configured DNS server for the IP address associated with the configured FQDN of the AC. If the DNS query is successful and the WTP acquires the IP address of an AC from the DNS server, then the above discover request packet is addressed to the unicast address of the AC.
3. DNS配置：管理员可以配置AC的完全限定域名（FQDN），而不是在WTP的非易失性内存上配置静态IP地址。如果配置了AC的FQDN，然后，WTP向其配置的DNS服务器查询与AC的配置FQDN相关联的IP地址。如果DNS查询成功，并且WTP从DNS服务器获取AC的IP地址，则上述发现请求数据包将寻址到AC的单播地址。
4. Broadcast: The WTP sends a discover request packet addressed to the broadcast IP address with the WTP's IP address as the source. A network administrator, if necessary, could configure the default router for the subnet that the WTP is on with a helper address and unicast it to any address on a different subnet.
4. 广播：WTP发送一个地址为广播IP地址的发现请求包，其中WTP的IP地址作为源。如有必要，网络管理员可以为WTP所在的子网配置带有帮助器地址的默认路由器，并将其单播到不同子网上的任何地址。
5. IP Multicast: A WTP can send the above payload to a SLAPP IP multicast address [TBD].
5. IP多播：WTP可以将上述有效负载发送到SLAPP IP多播地址[TBD]。
6. DNS: If there is no DNS FQDN configured on the WTP, and the WTP is unable to discover an AC by any of the above methods, then it should attempt to query the DNS server for a well-known FQDN of an AC [TBD]. If this DNS query succeeds, then the WTP should address the SLAPP discover request packet to the unicast address of the AC.
6. DNS：如果WTP上没有配置DNS FQDN，并且WTP无法通过上述任何方法发现AC，则它应尝试查询DNS服务器以获取AC[TBD]的已知FQDN。如果此DNS查询成功，则WTP应将SLAPP discover请求数据包寻址到AC的单播地址。
The above process is summarized in the sequence shown in Figure 7.
图7所示的顺序总结了上述过程。
SLAPP discovery start: Static IP address config option: Is a static IP address for an AC configured? If yes, send SLAPP discover request to that unicast IP address SLAPP discover response within discovery_timer? If yes, go to "done" If not, go to "Static FQDN config option" If not, go to "Static FQDN config option" Static FQDN config option: Is a static FQDN configured? If yes, send a DNS query for the IP address for the FQDN. Is DNS query successful? If yes, send SLAPP discover request to that IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "DHCP options option" If not, go to "DHCP options option" DHCP options option: Is the IP address of an AC present in the DHCP response? If yes, send SLAPP discover request to the AC's IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "Broadcast option" If not, go to "Broadcast option" Broadcast option: Send SLAPP discover packet to the broadcast address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "Multicast option" Multicast option: Send SLAPP discover packet to the SLAPP multicast address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "DNS discovery option" DNS discovery option: Query the DNS server for a well-known DNS name Is the DNS discovery successful? If yes, send SLAPP discover request to that IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "SLAPP discovery restart" If not, go to "SLAPP discovery restart"
SLAPP发现开始：静态IP地址配置选项：是否为AC配置了静态IP地址？如果是，将SLAPP discover请求发送到发现计时器内的单播IP地址SLAPP discover响应？如果是，则转到“完成”，如果不是，则转到“静态FQDN配置选项”，如果不是，则转到“静态FQDN配置选项”静态FQDN配置选项：是否配置了静态FQDN？如果是，请发送FQDN IP地址的DNS查询。DNS查询成功吗？如果是，是否在发现计时器内向该IP地址发送SLAPP discover请求SLAPP discover响应？如果是，则转到“完成”，如果不是，则转到“DHCP选项”，如果不是，则转到“DHCP选项”DHCP选项：DHCP响应中是否存在AC的IP地址？如果是，在发现计时器内向AC的IP地址发送SLAPP discover请求SLAPP discover响应？如果是，则转到“完成”，如果不是，则转到“广播选项”，如果不是，则转到“广播选项”广播选项：将SLAPP discover数据包发送到发现计时器内的广播地址SLAPP discover响应？如果是，转到“完成”如果不是，转到“多播选项”多播选项：将SLAPP discover数据包发送到SLAPP多播地址SLAPP discover response IN discovery timer？如果是，请转至“完成”。如果不是，请转至“DNS发现选项”DNS发现选项：查询DNS服务器以获取已知的DNS名称DNS发现是否成功？如果是，是否在发现计时器内向该IP地址发送SLAPP discover请求SLAPP discover响应？如果是，请转至“完成”如果不是，请转至“SLAPP发现重新启动”如果不是，请转至“SLAPP发现重新启动”
SLAPP discovery restart: Set timer for SLAPP discovery idle timer When timer expires, go to "SLAPP discovery start" done: Go to the next step
SLAPP发现重启：为SLAPP发现空闲计时器设置计时器当计时器过期时，转到“SLAPP发现启动”完成：转到下一步
Figure 7
图7
When an AC receives a SLAPP discover request, it must determine whether or not it wishes to acquire the WTP. An AC MAY only agree to acquire those WTPs whose WTP Identifiers are statically configured in its configuration. Or an AC that is willing to gratuitously acquire WTPs MAY accept any request pending authentication. An AC MUST only choose to acquire WTPs that speak a common Negotiated Control Protocol, but other factors may influence its decision. For instance, if the Negotiated Control Protocol is the Image Download protocol defined in this memo, the AC MUST NOT acquire a WTP for which it does not have a compatible image to download as determined by the WTP's HW Vendor ID, HW Version, and Software Version. Whatever its decision, the AC MUST respond one of two ways.
当AC收到SLAPP发现请求时，它必须确定是否希望获取WTP。AC可能只同意获取其WTP标识符在其配置中静态配置的那些WTP。或者，愿意无偿获取WTP的AC可以接受任何待验证的请求。AC只能选择获取使用通用协商控制协议的WTP，但其他因素可能会影响其决策。例如，如果协商控制协议是本备忘录中定义的映像下载协议，则AC不得获取WTP，因为根据WTP的硬件供应商ID、硬件版本和软件版本确定，其没有可下载的兼容映像。无论其决定如何，AC必须以两种方式之一作出回应。
1. The AC sends a SLAPP discover response indicating its agreement to acquire the WTP.
1. AC发送SLAPP discover响应，指示其同意获取WTP。
2. The AC silently drops the SLAPP discover request and does not respond at all.
2. AC无声地放弃SLAPP发现请求，根本不响应。
Once an AC has been discovered by a WTP and agreed to acquire it (by sending a Discover Response), it will initiate a DTLS [6] [8] exchange with the WTP by assuming the role of the "client". The WTP assumes the role of the "server". The port used by both the WTP and AC for this exchange will be [TBD].
一旦WTP发现AC并同意获取它（通过发送发现响应），它将通过扮演“客户”的角色启动与WTP的DTLS[6][8]交换。WTP承担“服务器”的角色。WTP和AC用于此交换的端口均为[TBD]。
An obvious question is "Why is the AC acting as a client?". The reason is to allow for non-mutual authentication in which the WTP is authenticated by the AC (see Section 5.1.2).
一个明显的问题是“为什么AC充当客户？”。原因是允许非相互认证，其中WTP由AC认证（见第5.1.2节）。
Informational note: DTLS is used because it provides a secure and connectionless channel using a widely accepted and analyzed protocol. In addition, the myriad of authentication options in DTLS allows for a wide array of options with which to secure the channel between the WTP and the AC -- mutual and certificate-based; asymmetric or non-mutual authentication; anonymous authentication, etc. Furthermore, DTLS defines its own fragmentation and reassembly techniques as well
信息性说明：使用DTLS是因为它使用广泛接受和分析的协议提供了一个安全和无连接的通道。此外，DTLS中无数的身份验证选项允许使用广泛的选项来保护WTP和AC之间的通道——相互的和基于证书的；非对称或非相互认证；匿名身份验证等。此外，DTLS还定义了自己的碎片和重组技术
as ways in which peers agree on an effective MTU. Using DTLS obviates the need to redefine these aspects of a protocol and therefore lessens code bloat as the same problem doesn't need to be solved yet again in another place.
作为同行就有效MTU达成一致的方式。使用DTL无需重新定义协议的这些方面，因此减少了代码膨胀，因为同样的问题不需要在其他地方再次解决。
Failure of the DTLS handshake protocol will cause both parties to abandon the exchange. The AC SHOULD blacklist this WTP for a period of time to prevent a misconfigured WTP from repeatedly discovering and failing authentication. The WTP MUST return to the discovery state of SLAPP to locate another suitable AC with which it will initiate a DTLS exchange.
DTLS握手协议失败将导致双方放弃交换。AC应在一段时间内将此WTP列入黑名单，以防止配置错误的WTP重复发现和验证失败。WTP必须返回SLAPP的发现状态，以找到另一个合适的AC，并与之启动DTLS交换。
Once the DTLS handshake has succeeded, the WTP and AP transition into "image download state" and protect all further SLAPP messages with the DTLS-negotiated cipher suite.
一旦DTLS握手成功，WTP和AP将转换为“映像下载状态”，并使用DTLS协商密码套件保护所有进一步的SLAPP消息。
Any valid cipher suite in [7] can be used to authenticate the WTP and/or the AC. Different scenarios require different authentication models. The following examples are illustrative only and not meant to be exhaustive.
[7]中的任何有效密码套件都可用于验证WTP和/或AC。不同的场景需要不同的验证模型。以下示例仅为说明性示例，并非详尽无遗。
Since neither side typically involves a human being, a username/ password-based authentication is not possible.
由于双方通常都不涉及人员，因此不可能进行基于用户名/密码的身份验证。
Zero-config requirements on certain WTP deployments can predicate certain authentication options and eliminate others.
某些WTP部署上的零配置要求可以断言某些身份验证选项并消除其他选项。
When mutually authenticating, the WTP authenticates the AC, thereby ensuring that the AC to which it is connecting is a trusted AC, and the AC authenticates the WTP, thereby ensuring that the WTP that is connecting is a trusted WTP.
当相互认证时，WTP认证AC，从而确保其连接到的AC是可信AC，并且AC认证WTP，从而确保正在连接的WTP是可信WTP。
Mutual authentication is typically achieved by using certificates on the WTP and AC, which ensure public keys each party owns. These certificates are digitally signed by a Certification Authority, a trusted third party.
相互认证通常通过使用WTP和AC上的证书来实现，以确保各方拥有公钥。这些证书由证书颁发机构（可信的第三方）进行数字签名。
Enrolling each WTP in a Certification Authority is outside the scope of this document, but it should be noted that a manufacturing Certification Authority does not necessarily provide the level of assurance necessary as it will only guarantee that a WTP or AC was manufactured by a particular company and cannot distinguish between a trusted WTP and a WTP that is not trusted but was purchased from the same manufacturer as the AC.
在证书颁发机构中注册每个WTP不在本文件范围内，但应注意的是，制造认证机构不一定提供必要的保证水平，因为其仅保证WTP或AC由特定公司制造，并且不能区分受信任的WTP和不受信任但从与AC相同的制造商处购买的WTP。
Some deployments may only require the WTP to authenticate to the AC and not the other way around.
某些部署可能只需要WTP向AC进行身份验证，而不是相反。
In this case, the WTP has a keypair that can uniquely identify it (for example, using a certificate) and, that keypair is used in a "server-side authentication" [7] exchange.
在这种情况下，WTP有一个可以唯一标识它的密钥对（例如，使用证书），并且该密钥对用于“服务器端身份验证”[7]交换。
This authentication model does not authenticate the AC and a rogue AC could assert control of a valid WTP. It should be noted, though, that this will only allow the WTP to provide service for networks made available by the rogue AC. No unauthorized network access is possible.
此身份验证模型不会对AC进行身份验证，流氓AC可以断言对有效WTP的控制。但应注意，这只允许WTP为流氓AC提供的网络提供服务。不可能进行未经授权的网络访问。
In some deployments, it MAY just be necessary to foil the casual snooping of packets. In this case, an unauthenticated, but encrypted, connection can suffice. Typically a Diffie-Hellman exchange is performed between the AC and WTP and the resulting unauthenticated key is used to encrypt traffic between the AC and WTP.
在某些部署中，可能只需要屏蔽对数据包的随意窥探。在这种情况下，未经验证但加密的连接就足够了。通常，在AC和WTP之间执行Diffie-Hellman交换，得到的未经验证的密钥用于加密AC和WTP之间的通信量。
In this section, we describe two extensions for SLAPP -- one that is specific to 802.11 WLANs and another that is a technology-neutral protocol by which an AC can download a bootable image to a WTP.
在本节中，我们将介绍SLAP的两个扩展——一个是特定于802.11 WLAN的扩展，另一个是技术中立的协议，AC可以通过该协议将可引导映像下载到WTP。
This section describes a SLAPP extension that is targeted towards WTPs and ACs implementing the IEEE 802.11 WLAN standard. This extension contains all the technology-specific components that will be used by an AC to control and manage 802.11 WTPs.
本节描述了针对实现IEEE 802.11 WLAN标准的WTP和ACs的SLAPP扩展。此扩展包含AC用于控制和管理802.11 WTP的所有特定于技术的组件。
The CAPWAP architecture taxonomy document [2] describes multiple architectures that are in use today in the WLAN industry. While there is a wide spectrum of variability present in these documented architectures, supporting every single variation or choice would lead to a complex protocol and negotiation phase. In the interest of limiting the complexity of the 802.11 component, we have limited the negotiation to four different architectural choices as listed below:
CAPWAP体系结构分类文档[2]描述了目前在WLAN行业中使用的多种体系结构。尽管在这些有文档记录的体系结构中存在着广泛的变化，但支持每一个变化或选择将导致复杂的协议和协商阶段。为了限制802.11组件的复杂性，我们将协商限制为以下四种不同的体系结构选择：
Local MAC, bridged mode: This mode of operation falls under the Local MAC architecture. The 802.11 MAC is terminated at the WTP. The WTP implements an L2 bridge that forwards packets between its WLAN interface and its Ethernet interface.
本地MAC，桥接模式：此操作模式属于本地MAC架构。802.11 MAC在WTP处终止。WTP实现一个L2网桥，在其WLAN接口和以太网接口之间转发数据包。
Local MAC, tunneled mode: This mode of operation also falls under the Local MAC architecture where the 802.11 MAC is terminated at the WTP. The difference between this mode and the previous one is that in this mode, the WTP tunnels 802.3 frames to the AC using the mechanisms defined in Section 6.1.2.
本地MAC，隧道模式：此操作模式也属于本地MAC架构，其中802.11 MAC在WTP处终止。此模式与前一种模式的区别在于，在此模式下，WTP使用第6.1.2节中定义的机制将802.3帧传输到AC。
Split MAC, L2 crypto at WTP: This mode of operation falls under the Split MAC architecture. The 802.11 MAC is split between the WTP and the AC, the exact nature of the split is described in Section 6.1.1.2. The L2 crypto functions are implemented in the WTP are the ones used to satisfy this function irrespective of whether or not the AC is also capable of this function. The WTP tunnels L2 frames to the AC using mechanisms defined in Section 6.1.2.
WTP的拆分MAC、L2加密：此操作模式属于拆分MAC架构。802.11 MAC在WTP和AC之间拆分，拆分的确切性质在第6.1.1.2节中描述。WTP中实现的L2加密函数是用于满足此函数的函数，无论AC是否也能够实现此函数。WTP使用第6.1.2节中定义的机制将L2框架隧道至AC。
Split MAC, L2 crypto at AC: This mode of operation also falls under the Split MAC architecture. The difference between this one and the previous one is that the L2 crypto functions implemented in the AC are used to satisfy this function irrespective of whether or not these functions are also available at the WTP. The WTP tunnels L2 frames to the AC using mechanisms defined in Section 6.1.2.
AC的拆分MAC、L2加密：这种操作模式也属于拆分MAC架构。此函数与前一个函数的区别在于，AC中实现的L2加密函数用于满足此函数，而不管这些函数是否在WTP中也可用。WTP使用第6.1.2节中定义的机制将L2框架隧道至AC。
The Local MAC architecture as documented in the CAPWAP architecture taxonomy document [2] performs all 802.11 frame processing at the WTP. The conversion from 802.11 to 802.3 and vice versa is also implemented at the WTP. This would mean that other functions like fragmentation/reassembly of 802.11 frames, and encryption/decryption of 802.11 frames is implemented at the WTP.
CAPWAP体系结构分类文件[2]中记录的本地MAC体系结构在WTP执行所有802.11帧处理。WTP也实现了从802.11到802.3的转换，反之亦然。这将意味着在WTP上实现诸如802.11帧的分段/重组和802.11帧的加密/解密等其他功能。
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and bridged onto the Ethernet interface of the WTP. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
在本地MAC架构的这一子模式中，802.11帧被转换为802.3帧，并桥接到WTP的以太网接口上。这些帧可以使用AC分配的802.1Q VLAN标记进行标记。
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and are tunneled (using the tunneling mechanism defined in Section 6.1.2) to the AC to which the WTP is attached. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
在本地MAC架构的该子模式中，802.11帧被转换为802.3帧，并通过隧道（使用第6.1.2节中定义的隧道机制）连接到WTP所连接的AC。这些帧可以使用AC分配的802.1Q VLAN标记进行标记。
In the Split MAC architecture, the MAC functions of an 802.11 AP are split between the WTP and the AC. The exact nature of the split is dependent upon the sub-modes listed in this section. In both cases, frames are tunneled to the AC using the mechanism defined in Section 6.1.2.
在拆分MAC架构中，802.11 AP的MAC功能在WTP和AC之间拆分。拆分的确切性质取决于本节中列出的子模式。在这两种情况下，使用第6.1.2节中定义的机制将框架隧道至AC。
Some of these Split MAC architectures convert the 802.11 frames into 802.3 frames, which may be 802.1Q-tagged using tags assigned by the AC, while other of these Split MAC architectures will tunnel the entire 802.11 frame to the AC. The AC and WTP agree on what type of frame will be tunneled during the control protocol registration in Section 6.1.3
其中一些拆分MAC架构将802.11帧转换为802.3帧，可以使用AC分配的标签对其进行802.1Q标记，而这些拆分MAC架构中的其他架构将通过隧道将整个802.11帧传输到AC。AC和WTP在第6.1.3节中的控制协议注册期间就将通过隧道传输的帧类型达成一致
For this sub-mode of the Split MAC architecture, the 802.11 AP functions are split as follows:
对于拆分MAC架构的此子模式，802.11 AP功能拆分如下：
At the WTP:
在WTP：
802.11 control frame processing
802.11控制帧处理
802.11 encryption and decryption
802.11加密和解密
802.11 fragmentation and reassembly
802.11碎片和重组
Rate Adaptation
速率自适应
802.11 beacon generation
802.11信标生成
Power-save buffering and Traffic Indication Map (TIM) processing
节能缓冲和交通指示图（TIM）处理
At the AC:
在交流中心：
802.11 Management frame processing
802.11管理帧处理
802.11 DS and portal
802.11 DS和门户
Split MAC implementations of this kind may tunnel either 802.11 or 802.3 frames between the AC and the WTP.
这种分割MAC实现可以在AC和WTP之间隧道802.11或802.3帧。
For this sub-mode of the Split MAC architecture, the 802.11 AP functions are split as follows:
对于拆分MAC架构的此子模式，802.11 AP功能拆分如下：
At the WTP:
在WTP：
802.11 control frame processing
802.11控制帧处理
Rate Adaptation
速率自适应
802.11 beacon generation
802.11信标生成
Power-save buffering and TIM processing
节能缓冲和TIM处理
At the AC:
在交流中心：
802.11 Management frame processing
802.11管理帧处理
802.11 encryption and decryption
802.11加密和解密
802.11 fragmentation and reassembly
802.11碎片和重组
802.11 DS and portal
802.11 DS和门户
Split MAC implementations of this kind tunnel 802.11 frames between the AC and the WTP.
在AC和WTP之间拆分这种类型的MAC实现隧道802.11帧。
The 802.11 Control Protocol has two components, one for transporting the specific control and provisioning messages and another to tunnel data traffic from the WTP to the AC.
802.11控制协议有两个组件，一个用于传输特定的控制和供应消息，另一个用于将数据流量从WTP传输到AC。
The SLAPP 802.11 Control Protocol uses the Generic Routing Encapsulation (GRE) [4] to encapsulate L2 frames. Depending on whether and how an architecture splits its MAC, some architectures may tunnel 802.11 frames directly to the AC while others may tunnel 802.3 frames, which may be optionally 802.1Q-tagged using tags assigned by the AC.
SLAPP 802.11控制协议使用通用路由封装（GRE）[4]来封装L2帧。根据架构是否拆分其MAC以及如何拆分其MAC，一些架构可以将802.11帧直接隧道到AC，而其他架构可以隧道802.3帧，其可以使用AC分配的标签选择性地进行802.1Q标记。
The delivery mechanism of these GRE packets is IP. Therefore, the IP protocol of the outer packet is 47, indicating a GRE header follows. When GRE encapsulates 802.11 frames, the ether type in the GRE header is TBD; when GRE encapsulates 802.3 frames, the ether type in the GRE header is TBD2.
这些GRE数据包的传送机制是IP。因此，外部分组的IP协议是47，指示遵循GRE报头。当GRE封装802.11帧时，GRE报头中的以太类型为TBD；当GRE封装802.3帧时，GRE报头中的以太类型为TBD2。
Since IP is the delivery mechanism, all issues governing fragmentation and reassembly are handled by [5].
由于IP是交付机制，所有控制碎片和重组的问题都由[5]处理。
When using the 802.11 Control Protocol, the type of SLAPP message is four (4), "control protocol packet". In this case, a two (2) octet field is appended to the SLAPP header to indicate the control protocol type as shown in Figure 8. The SLAPP 802.11 Control Protocol takes place in the "Negotiated Control Protocol" phase of Section 4.1, and all SLAPP 802.11 Control Protocol messages are therefore secured by the security association created immediately prior to entering that phase.
使用802.11控制协议时，SLAPP消息的类型为四（4）“控制协议包”。在这种情况下，一个两（2）个八位组字段附加到SLAPP报头，以指示控制协议类型，如图8所示。SLAPP 802.11控制协议发生在第4.1节的“协商控制协议”阶段，因此，所有SLAPP 802.11控制协议消息都由在进入该阶段之前创建的安全关联进行保护。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 Control Protocol 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 Control Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SLAPP Control Protocol Header
图8:SLAPP控制协议头
Where valid 802.11 Control Protocol Types are:
其中，有效的802.11控制协议类型为：
1 : Registration Request - sent from WTP to AC
1：注册请求-从WTP发送至AC
2 : Registration Response - sent from AC to WTP
2：注册响应-从AC发送到WTP
3 : De-Registration Request - sent by either WTP or AC
3：注销请求-由WTP或AC发送
4 : De-Registration Response - sent by the recipient of the corresponding request
4：注销响应-由相应请求的收件人发送
5 : Configuration Request - sent by WTP to AC
5：配置请求-由WTP发送至AC
6 : Configuration Response - sent by AC to WTP
6：配置响应-由AC发送至WTP
7 : Configuration Update - sent by AC to WTP
7：配置更新-由AC发送至WTP
8 : Configuration Acknowledgment - sent by the WTP to AC
8：配置确认-由WTP发送至AC
9 : Status Request - sent by the AC to the WTP
9：状态请求-由AC发送至WTP
10 : Status Response - sent by the WTP to the AC
10：状态响应-由WTP发送至AC
11 : Statistics Request - sent by the AC to the WTP
11：统计请求-由AC发送至WTP
12 : Statistics Response - sent by the WTP to the AC
12：统计响应-由WTP发送至AC
13 : Event - sent by the WTP to the AC
13：事件-由WTP发送至AC
14 : Keepalive - sent either way
14：Keepalive-以任意方式发送
15 : Key Config Request - sent by the AC to the WTP
15：钥匙配置请求-由AC发送至WTP
16 : Key Config Response - sent by the WTP to the AC
16：密钥配置响应-由WTP发送至AC
All basic configuration functions are applicable per-Extended Service Set Identifier (ESSID) per-radio in a WTP. Some WTPs MAY support more than one ESSID per-radio, while all WTPs MUST support at least one ESSID per-radio, which may be considered the primary ESSID in case of multiple ESSID support. All per-WTP configurations and capabilities (e.g., number of radios) are handled as part of the discovery and initialization process.
所有基本配置功能均适用于WTP中每个无线电的扩展服务集标识符（ESSID）。一些WTP可能支持每个无线电不止一个ESSID，而所有WTP必须支持每个无线电至少一个ESSID，在多个ESSID支持的情况下，可以将其视为主ESSID。所有每个WTP配置和功能（例如，无线电数量）都作为发现和初始化过程的一部分进行处理。
The provisioning of the regulatory domain of a WTP is beyond the scope of this document. A WTP, once provisioned for a specific regulatory domain, MUST restrict the operational modes, channel, transmit power, and any other necessary limits based on the knowledge contained within its software image and hardware capabilities. The WTP MUST communicate its capabilities limited by the regulatory domain as well as by the WTP hardware, if any, to the AC during the capability exchange.
WTP监管域的设置超出了本文件的范围。WTP一旦为特定监管领域提供，必须根据其软件映像和硬件功能中包含的知识限制操作模式、信道、发射功率和任何其他必要限制。在能力交换期间，WTP必须将其受监管域以及WTP硬件（如有）限制的能力传达给AC。
The allocation and assignment of Basic Service Set Identifiers (BSSIDs) to the primary interface and to the virtual access point (AP) interfaces, if supported, are outside the scope of this document.
将基本服务集标识符（BSSID）分配给主接口和虚拟接入点（AP）接口（如果支持）不在本文档范围内。
Information elements (IEs) are used to communicate capability, configuration, status, and statistics information between the AC and the WTP.
信息元素用于交流AC和WTP之间的能力、配置、状态和统计信息。
The structure of an information element is show below. The element ID starts with an element ID octet, followed by a 1-octet length, and the value of the element ID whose length is indicated in the Length field. The maximum length of an element is 255 octets.
信息元素的结构如下所示。元素ID以元素ID八位字节开始，后跟1个八位字节的长度，元素ID的值的长度在长度字段中指示。元素的最大长度为255个八位字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This element defines the MAC architecture modes (Section 6.1.1).
该元素定义了MAC架构模式（第6.1.1节）。
Element ID : 1
元素ID:1
Length : 1
长度：1
Value : The following values are defined.
值：定义了以下值。
Bit 0 : CAPWAP mode 1 - Local MAC, bridged mode
位0:CAPWAP模式1-本地MAC，桥接模式
Bit 1 : CAPWAP mode 2 - Local MAC, tunneled mode
位1:CAPWAP模式2-本地MAC，隧道模式
Bit 2 : CAPWAP mode 3 - Split MAC, WTP encryption, 802.3 tunneling
比特2:CAPWAP模式3-拆分MAC、WTP加密、802.3隧道
Bit 3 : CAPWAP mode 4 - Split MAC, WTP encryption, 802.11 tunneling
比特3:CAPWAP模式4-拆分MAC、WTP加密、802.11隧道
Bit 4 : CAPWAP mode 5 - Split MAC, AC encryption, 802.11 tunneling
第4位：CAPWAP模式5-拆分MAC、AC加密、802.11隧道
Bits 5-7 : Set to 0
位5-7：设置为0
When this element is included in the capabilities message, then the setting of a bit indicates the support for this CAPWAP mode at the WTP. When this element is used in configuration and status messages, then exactly one of bits 0-4 MUST be set.
当此元素包含在功能消息中时，位的设置表示WTP支持此CAPWAP模式。当在配置和状态消息中使用此元素时，必须恰好设置位0-4中的一个。
This element refers to the number of 802.11 WLANs present in the WTP.
此元素表示WTP中存在的802.11 WLAN的数量。
Element ID : 2
元素ID:2
Length : 1
长度：1
Value : 0-255
数值：0-255
This element is used to refer to a particular instance of a WLAN interface when used in configuration and status messages. When used within a recursion element, the elements within the recursion element correspond to the WLAN interface specified in this element.
此元素用于在配置和状态消息中使用时引用WLAN接口的特定实例。当在递归元素中使用时，递归元素中的元素对应于此元素中指定的WLAN接口。
Element ID : 3
元素ID:3
Length : 1
长度：1
Value : 0 - (Number of WLAN interfaces - 1)
Value : 0 - (Number of WLAN interfaces - 1)
This element is the WLAN Interface hardware vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). This field appears once for each instance of WLAN interface present in the WTP.
此元素是WLAN接口硬件供应商的SMI企业代码，按网络八位字节顺序排列（这些企业代码可从IANA获得并在IANA注册）。对于WTP中存在的每个WLAN接口实例，此字段显示一次。
Element ID : 4
元素ID:4
Length : 4
长度：4
Value : 32-bit value
值：32位值
This element is an ID assigned by the WLAN Interface hardware vendor to indicate the type of the WLAN interface. It is controlled by the hardware vendor and the range of possible values is beyond the scope of this document. This field appears once for each instance of a WLAN interface present in the WTP.
此元素是WLAN接口硬件供应商分配的ID，用于指示WLAN接口的类型。它由硬件供应商控制，可能值的范围超出了本文档的范围。对于WTP中存在的WLAN接口的每个实例，此字段显示一次。
Element ID : 5
元素ID:5
Length : 4
长度：4
If a regulatory domain is provisioned in the WTP, then the WTP indicates this by including this element in the capabilities list. If this information is not available at the WTP, then this element SHOULD not be included in the capabilities list. The process by which this information is provisioned into the WTP is beyond the scope of this document.
如果在WTP中设置了监管域，则WTP通过将此元素包括在能力列表中来指示这一点。如果此信息在WTP中不可用，则此元素不应包含在能力列表中。将此信息提供给WTP的过程超出了本文档的范围。
Element ID : 6
元素ID:6
Length : 4
长度：4
Value : ISO code assigned to the regulatory domain
值：分配给监管领域的ISO代码
This element indicates the list of 802.11 Physical Layer (PHY) modes supported by the WTP along with a list of channels and maximum power level supported for this mode. This element appears once for each instance of WLAN interface at the WTP. There could be multiple instances of this element if the WLAN interface supports multiple PHY types.
此元素表示WTP支持的802.11物理层（PHY）模式列表，以及此模式支持的信道和最大功率级别列表。此元素在WTP的每个WLAN接口实例中显示一次。如果WLAN接口支持多种PHY类型，则此元素可能有多个实例。
Element ID : 7
元素ID:7
Length : Variable
长度：可变
Valid : This field consists of
有效：此字段包括
PHY mode : With a length of 1 octet with values as follows:
PHY模式：长度为1个八位字节，值如下：
0 : Radio Disabled/Inactive
0：无线电已禁用/未激活
1 : IEEE 802.11b
1:IEEE 802.11b
2 : IEEE 802.11g
2:IEEE 802.11g
3 : IEEE 802.11a
3:IEEE 802.11a
4-255 : Reserved
4-255：保留
Power Level : In the capabilities messages, this indicates the maximum power level supported in this mode by the WTP; while in the configuration and status messages, this field indicates the desired power level or the current power level that the WTP is operating at. The field has a length of 1 octet and the power level is indicated in dBm.
功率级别：在能力消息中，这表示WTP在此模式下支持的最大功率级别；在配置和状态消息中，此字段表示WTP运行的所需功率级别或当前功率级别。该字段的长度为1个八位字节，功率级别以dBm表示。
Channel Information : A variable number of 2-octet values that indicate the center frequencies (in KHz) of all supported channels in this PHY mode.
信道信息：2个八位组值的可变数量，表示此PHY模式下所有受支持信道的中心频率（以KHz为单位）。
When this element is used in configuration and status messages, the Power Level field indicates the desired or current operating power level. The Channel field has exactly one 2-octet value indicating the desired or current operating frequency.
在配置和状态消息中使用此元素时，功率级别字段指示所需或当前工作功率级别。信道字段正好有一个2-octet值，指示所需或当前工作频率。
In the capabilities message, this element contains the list of cryptographic algorithms that are supported by the WTP. This appears once for each instance of the WLAN interface present in the WTP. In configuration and status messages, this element is used to indicate the configured cryptographic capabilities at the WTP.
在capabilities消息中，此元素包含WTP支持的加密算法列表。对于WTP中存在的WLAN接口的每个实例，此选项都会出现一次。在配置和状态消息中，此元素用于指示WTP上已配置的加密功能。
Element ID : 8
元素ID:8
Length : 1
长度：1
Value : The following bits are defined:
值：定义了以下位：
Bit 0 : WEP
第0位：WEP
Bit 1 : TKIP
第1位：TKIP
Bit 2 : AES-CCMP
第2位：AES-CCMP
Bits 3-7 : Reserved
第3-7位：保留
This element contains a bitmap indicating support at the WTP for various IEEE 802.11 standards.
此元素包含一个位图，指示WTP对各种IEEE 802.11标准的支持。
Element ID : 9
元素ID:9
Length : 4
长度：4
Value : A bitmap as follows:
值：位图，如下所示：
Bit 0 : WPA
位0:WPA
Bit 1 : 802.11i
第1位：802.11i
Bit 2 : WMM
第2位：WMM
Bit 3 : WMM-SA
第3位：WMM-SA
Bit 4 : U-APSD
第4位：U-APSD
Bits 5-32 : Reserved
第5-32位：保留
In the capabilities message, this element is formatted as follows
在capabilities消息中，此元素的格式如下
Element ID : 10
元素ID:10
Length : 4
长度：4
Value : Formatted as follows:
值：格式如下：
Bits 0-7 : Number of Antennae
位0-7：天线数量
Bit 8 : Individually Configurable, 0 = No, 1 = Yes
Bit 8 : Individually Configurable, 0 = No, 1 = Yes
Bit 9 : Diversity support, 0 = No, 1 = Yes
Bit 9 : Diversity support, 0 = No, 1 = Yes
Bit 10 : 0 = Internal, 1 = External
Bit 10 : 0 = Internal, 1 = External
Bits 11-31 : Reserved
第11-31位：保留
In configuration and status messages, this element is formatted as follows:
在配置和状态消息中，此元素的格式如下：
Element ID : 10
元素ID:10
Length : 4
长度：4
Value : Formatted as follows:
值：格式如下：
Bits 0-7 : Antenna Number - is a number between 0 and the number of antennae indicated by the WTP. The value is valid only if Bit 8 is set; otherwise, it MUST be ignored.
位0-7：天线编号-是介于0和WTP指示的天线编号之间的数字。仅当设置了位8时，该值才有效；否则，它必须被忽略。
Bit 8 : Antenna Select - if this bit is reset, then the antenna selection is left to the algorithm on the WTP. If this bit is set, then the Antenna Number field indicates the antenna that should be used for transmit and receive.
位8：天线选择-如果该位被重置，则天线选择由WTP上的算法决定。如果设置了此位，则天线编号字段指示应用于发送和接收的天线。
Bits 9-31 : Reserved
第9-31位：保留
This element indicates the number of BSSIDs supported by the WLAN interface. This element is optional in the capabilities part of the registration request message, and if it is absent, then the number of BSSIDs is set to 1. This element appears once for each instance of a WLAN interface present in the WTP.
此元素表示WLAN接口支持的BSSID数量。该元素在注册请求消息的功能部分是可选的，如果不存在，则BSSID的数量设置为1。此元素对于WTP中存在的WLAN接口的每个实例显示一次。
Element ID : 11
元素ID:11
Length : 1
长度：1
Value : The number of BSSIDs that the WLAN interface is capable of supporting.
值：WLAN接口能够支持的BSSID数。
This element is used when sending configuration or status specific to a certain BSSID in the WTP.
此元素用于发送特定于WTP中特定BSSID的配置或状态。
Element ID : 12
元素ID:12
Length : 1
长度：1
Valid values are from 0 to (Number of BSSIDs -1)
有效值为0到（BSSID的数量-1）
This element is used in configuration and status messages to either configure the ESSID on a certain BSSID or report the current operating value.
此元素在配置和状态消息中用于在特定BSSID上配置ESSID或报告当前操作值。
Element ID : 13
元素ID:13
Length : Variable, between 0 and 32 both inclusive.
长度：变量，介于0和32之间（包括0和32）。
Value : Variable, contains ASCII characters.
值：变量，包含ASCII字符。
There is no default value for this parameter.
此参数没有默认值。
This element is used in configuration and status messages to control the announcement of the ESSID in 802.11 beacons. For the Local MAC modes of operation, this field is also used to control whether the WTP should respond to Probe Requests that have a NULL ESSID in them.
此元素用于配置和状态消息中，以控制802.11信标中ESSID的宣布。对于本地MAC操作模式，此字段还用于控制WTP是否应响应包含空ESSID的探测请求。
Element ID : 14
元素ID:14
Length : 1
长度：1
Value : Defined as follows:
值：定义如下：
Bit 0 : ESSID announcement, 0 = Hide ESSID, 1 = Display ESSID in 802.11 beacons. The default value for this bit is 1.
位0:ESSID公告，0=隐藏ESSID，1=在802.11信标中显示ESSID。此位的默认值为1。
Bit 1 : Probe Response policy, 0 = Respond to Probe Requests that contain a NULL ESSID, 1 = Respond only to Probe Requests that match the configured ESSID. The default value for this bit is 0.
位1：探测响应策略，0=响应包含空ESSID的探测请求，1=仅响应与配置的ESSID匹配的探测请求。此位的默认值为0。
Bit 2-7 : Reserved
第2-7位：保留
This element is used to configure the beacon interval on a BSSID on the WTP.
此元素用于在WTP上的BSSID上配置信标间隔。
Element ID : 15
元素ID:15
Length : 2
长度：2
Value : Valid values for the beacon interval as allowed by IEEE 802.11
值：IEEE 802.11允许的信标间隔的有效值
The default value for this parameter is 100.
此参数的默认值为100。
This element is used to configure the DTIM period on a BSSID present on the WTP.
This element is used to configure the DTIM period on a BSSID present on the WTP.translate error, please retry
Element ID : 16
元素ID:16
Length : 2
长度：2
Value : Valid values for the DTIM period as allowed by IEEE 802.11.
值：IEEE 802.11允许的DTIM周期的有效值。
The default value for this parameter is 1.
此参数的默认值为1。
Configure or report the configured set of basic rates.
配置或报告已配置的基本费率集。
Element ID : 17
元素ID:17
Length : 4
长度：4
Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a basic rate. If the bit is reset, then the rate is not to be configured as a basic rate.
值：以下列表中的每个位解释如下。如果设置了位，则该特定速率将配置为基本速率。如果该位被重置，则该速率不会被配置为基本速率。
Bit 0 : 1 Mbps
比特0:1Mbps
Bit 1 : 2 Mbps
比特1:2Mbps
Bit 2 : 5.5 Mbps
比特2:5.5 Mbps
Bit 3 : 11 Mbps
比特3:11Mbps
Bit 4 : 6 Mbps
比特4:6Mbps
Bit 5 : 9 Mbps
比特5:9 Mbps
Bit 6 : 12 Mbps
比特6:12Mbps
Bit 7 : 18 Mbps
比特7:18Mbps
Bit 8 : 24 Mbps
比特8:24Mbps
Bit 9 : 36 Mbps
比特9:36Mbps
Bit 10 : 48 Mbps
比特10:48Mbps
Bit 11 : 54 Mbps
比特11:54 Mbps
Bits 12-31 : Reserved
第12-31位：保留
Configure or report the configured set of basic rates.
配置或报告已配置的基本费率集。
Element ID : 18
元素ID:18
Length : 4
长度：4
Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a supported rate. If the bit is reset, then the rate is not to be configured as a supported rate.
值：以下列表中的每个位解释如下。如果设置了位，则该特定速率将配置为支持的速率。如果位被重置，则不将速率配置为支持的速率。
Bit 0 : 1 Mbps
比特0:1Mbps
Bit 1 : 2 Mbps
比特1:2Mbps
Bit 2 : 5.5 Mbps
比特2:5.5 Mbps
Bit 3 : 11 Mbps
比特3:11Mbps
Bit 4 : 6 Mbps
比特4:6Mbps
Bit 5 : 9 Mbps
比特5:9 Mbps
Bit 6 : 12 Mbps
比特6:12Mbps
Bit 7 : 18 Mbps
比特7:18Mbps
Bit 8 : 24 Mbps
比特8:24Mbps
Bit 9 : 36 Mbps
比特9:36Mbps
Bit 10 : 48 Mbps
比特10:48Mbps
Bit 11 : 54 Mbps
比特11:54 Mbps
Bits 12-31 : Reserved
第12-31位：保留
This element is used to configure long and short retries for each BSSID present on the WTP.
此元素用于为WTP上存在的每个BSSID配置长重试和短重试。
Element ID : 19
元素ID:19
Length : 2
长度：2
Value : as follows:
价值：如下所示：
Bits 0-7 : Short retry count, default value is 3.
位0-7：短重试计数，默认值为3。
Bits 8-15 : Long retry count, default value is 3.
位8-15：长重试计数，默认值为3。
This element is used to configure the fragmentation threshold on a BSSID present on the WTP.
此元素用于在WTP上存在的BSSID上配置碎片阈值。
Element ID : 20
元素ID:20
Length : 2
长度：2
Value : Valid values for the fragmentation threshold as allowed by IEEE 802.11.
值：IEEE 802.11允许的碎片阈值的有效值。
The default value for this parameter is 2346.
此参数的默认值为2346。
This element is used to configure the Request to Send (RTS) threshold on a BSSID present on the WTP.
此元素用于在WTP上存在的BSSID上配置发送请求（RTS）阈值。
Element ID : 21
元素ID:21
Length : 2
长度：2
Value : Valid values for RTS threshold as allowed by IEEE 802.11.
值：IEEE 802.11允许的RTS阈值的有效值。
The default value for this parameter is 2346.
此参数的默认值为2346。
This element is used to configure the preamble type used for transmission in 802.11b mode.
此元素用于配置用于802.11b模式下传输的前导码类型。
Element ID : 22
元素ID:22
Length : 1
长度：1
Value : Defined as follows:
值：定义如下：
0 : Disable Short preamble
0：禁用短前导码
1 : Enable Short preamble
1：启用短前导码
2-255 : Reserved
2-255：保留
The default value for this parameter is 0.
此参数的默认值为0。
This element is used to configure the tagging of packets belonging to a particular SSID when transferred between the AC and the WTP in CAPWAP modes 2-3, or before the WTP bridges the 802.3 frame to its wired interface when operating in CAPWAP mode 1.
此元素用于在CAPWAP模式2-3下在AC和WTP之间传输时，或在CAPWAP模式1下运行时，在WTP将802.3帧桥接到其有线接口之前，配置属于特定SSID的数据包的标记。
Element ID : 23
元素ID:23
Length : 2
长度：2
Value : 802.1Q tag
值：802.1Q标签
If this element is absent in the configuration, then the WTP MUST assume that no tagging is required and should expect to receive untagged frames on frames destined towards the wireless interface.
如果该元素在配置中不存在，则WTP必须假设不需要标记，并且应该期望在发送到无线接口的帧上接收未标记的帧。
A successful registration response from an AC to a WTP MUST contain this element. It is used in messages between the WTP and the AC on all other messages during the duration for which the registration is active.
从AC到WTP的成功注册响应必须包含此元素。在注册有效期间，它用于WTP和AC之间的所有其他消息中的消息。
Element ID : 24
元素ID:24
Length : 4
长度：4
Value : A 32-bit unsigned number allocated by the AC
值：由AC分配的32位无符号数
The AC uses this element to assign a string of ASCII characters to the WTP.
AC使用此元素将ASCII字符字符串分配给WTP。
Element ID : 25
元素ID:25
Length : Variable, between 0 and 64 both inclusive
长度：变量，介于0和64之间（包括0和64）
Value : A variable length string of ASCII characters
值：ASCII字符的可变长度字符串
The AC uses this element to assign importance to events, enable or disable notification, and to configure the global event notification policy. When the Event Identifier is 0, this element serves as a global notification policy message. The bitmap indicates the types of events that require the WTP to generate a notification. When the Event Identifier is non-zero, this element is used to configure a specific event for notification and its importance level. The importance level is specified by setting exactly one bit in the bitmap. If none of the bits are set in the bitmap, the element should be interpreted as a cancellation request. The WTP should stop sending notifications for the corresponding event specified in the Element Identifier.
AC使用此元素为事件分配重要性、启用或禁用通知以及配置全局事件通知策略。当事件标识符为0时，此元素用作全局通知策略消息。位图指示需要WTP生成通知的事件类型。当事件标识符为非零时，此元素用于配置通知的特定事件及其重要性级别。通过在位图中精确设置一位来指定重要性级别。如果位图中未设置任何位，则该元素应解释为取消请求。WTP应停止发送元素标识符中指定的相应事件的通知。
Element ID : 26
元素ID:26
Length : 4
长度：4
Value : Defined as follows:
值：定义如下：
Bits 0 - 15: Event Identifier
位0-15：事件标识符
Bit 16: Fatal - The system is not usable.
第16位：致命-系统不可用。
Bit 17: Alert - Immediate action is required.
第17位：警报-需要立即采取行动。
Bit 18: Critical
第18位：关键
Bit 19: Error
第19位：错误
Bit 20: Warning
第20位：警告
Bit 21: Notification
第21位：通知
Bit 22: Informational
第22位：信息性
Bit 23: Debug
第23位：调试
Bits 24 - 31: Reserved
第24-31位：保留
The AC uses this element to indicate the mode of operation for the radio for each WLAN interface.
AC使用此元素指示每个WLAN接口的无线电操作模式。
Element ID : 27
元素ID:27
Length : 1
长度：1
Value : The following are valid values:
值：以下是有效值：
0 : Radio is disabled
0:收音机已禁用
1 : Radio is enabled
1：收音机已启用
2-255 : Reserved
2-255：保留
The AC uses this element to configure 802.11e functions at the WTP.
AC使用此元素在WTP上配置802.11e功能。
Element ID : 28
元素ID:28
Length : 4
长度：4
Value : A bitmap as follows:
值：位图，如下所示：
Bit 0 : WMM
位0:WMM
Bit 1 : WMM-SA
第1位：WMM-SA
Bit 2 : U-APSD
第2位：U-APSD
Bits 3-32 : Reserved
第3-32位：保留
This element defines the statistics relating to configuration and registration events as seen by the WTP.
此元素定义与WTP看到的配置和注册事件相关的统计信息。
Element ID : 29
元素ID:29
Length : 32
长度：32
Value : The value is as follows:
值：该值如下所示：
* Configuration Requests : 4 octets - Number of Configuration Request messages sent by the WTP since the last reboot or reset of the counters.
* 配置请求：4个八位字节-自上次重新启动或重置计数器以来WTP发送的配置请求消息数。
* Configuration Responses : 4 octets
* 配置响应：4个八位字节
* Configuration Updates : 4 octets
* 配置更新：4个八位字节
* Configuration ACKs : 4 octets
* 配置确认：4个八位字节
* Registration Requests : 4 octets
* 注册要求：4个八位字节
* Registration Responses : 4 octets
* 注册响应：4个八位字节
* De-Registration Requests : 4 octets
* 取消注册请求：4个八位字节
* De-Registration Responses : 4 octets
* 取消注册响应：4个八位字节
This information element contains a set of counters relating to the transmit side of the wireless link at the WTP. These counters apply to either a BSS or an Access Category (if Wireless Multimedia (WMM) is enabled).
此信息元素包含一组与WTP处无线链路的传输侧相关的计数器。这些计数器适用于BSS或访问类别（如果启用了无线多媒体（WMM））。
Element ID : 30
元素ID:30
Length : 112 octets
长度：112个八位字节
Value : The value of this element is defined as follows:
值：此元素的值定义如下：
* Total received from the network : 4 octets
* 从网络接收的总数：4个八位字节
* Successfully transmitted frames (total) : 4 octets
* 成功传输的帧（总数）：4个八位字节
* Successfully transmitted 802.11 Mgmt frames : 4 octets
* 已成功传输802.11管理帧：4个八位字节
* Successfully transmitted 802.11 Data frames : 4 octets
* 成功传输802.11数据帧：4个八位字节
* Transmitted 802.11 Control frames : 4 octets
* 传输的802.11控制帧：4个八位字节
* Frames that reached max-retry limit : 4 octets
* 达到最大重试限制的帧：4个八位字节
* Transmitted frames with 1 retry attempt : 4 octets
* 传输的帧有1次重试尝试：4个八位字节
* Transmitted frames with 2 retry attempts : 4 octets
* 有2次重试尝试的传输帧：4个八位组
* Transmitted frames with more than 2 retry attempts : 4 octets
* 重试次数超过2次的传输帧：4个八位字节
* Frames transmitted at each 802.11 PHY rate : 12*4 octets - The counters indicate the number of frames at each of the following rates, respectively: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mbps.
* 以每个802.11物理层速率传输的帧：12*4个八位字节-计数器分别指示以下速率下的帧数：1、2、5.5、11、6、9、12、18、24、36、48、54 Mbps。
* Total frame dropped : 4 octets
* 丢弃的总帧数：4个八位字节
* Frames dropped due to insufficient resources : 4 octets
* 由于资源不足而丢弃的帧：4个八位字节
* Frames dropped due to power-save timeouts : 4 octets
* 由于省电超时而丢失的帧：4个八位字节
* Frames dropped due to other reasons : 4 octets
* 由于其他原因而丢弃的帧：4个八位字节
* Fragments transmitted : 4 octets
* 传送片段：4个八位组
* Fragments dropped : 4 octets
* 片段丢失：4个八位组
* Power-save multicast frames : 4 octets
* 节能多播帧：4个八位字节
* Power-save unicast frames : 4 octets
* 节能单播帧：4个八位字节
This information element includes all statistics related to the reception of the frames by WTP. These counters apply to either a BSS or an Access Category (if WMM is enabled).
该信息元素包括与WTP接收帧相关的所有统计信息。这些计数器适用于BSS或访问类别（如果启用了WMM）。
Element ID : 31
元素ID:31
Length : 108 octets
长度：108个八位字节
Value : The value of this element is defined as follows:
值：此元素的值定义如下：
* Total Frames received : 4 octets
* 接收的帧总数：4个八位字节
* Frames with the retry bit set : 4 octets
* 设置了重试位的帧：4个八位字节
* 802.11 Data frames received : 4 octets
* 接收到802.11数据帧：4个八位字节
* 802.11 Mgmt frames received : 4 octets
* 接收到802.11管理帧：4个八位组
* 802.11 Control frames received : 4 octets
* 接收到802.11控制帧：4个八位字节
* Cyclic Redundancy Check (CRC) errors : 4 octets
* 循环冗余校验（CRC）错误：4个八位字节
* PHY errors : 4 octets
* 物理错误：4个八位字节
* Total Fragments received : 4 octets
* 收到的碎片总数：4个八位组
* Reassembled frames : 4 octets
* 重组帧：4个八位组
* Reassembly failures : 4 octets
* 重组失败：4个八位组
* Successful Decryption : 4 octets
* 成功解密：4个八位组
* Decryption failures : 4 octets
* 解密失败：4个八位字节
* Rate statistics : 48 octets - The number of frames received at each of the 802.11 PHY rates, respectively - 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 49, 54 Mbps.
* 速率统计：48个八位字节-分别以802.11物理层速率接收的帧数-1、2、5.5、11、6、9、12、18、24、36、49、54 Mbps。
* Total frames dropped : 4 octets
* 丢弃的总帧数：4个八位字节
* Frames dropped due to insufficient resources : 4 octets
* 由于资源不足而丢弃的帧：4个八位字节
* Frames dropped due to other reasons : 4 octets
* 由于其他原因而丢弃的帧：4个八位字节
This element includes information about the current stations associated with the BSS.
此元素包括与BSS关联的当前电台的信息。
Element ID : 32
元素ID:32
Length : Variable
长度：可变
Value : The value is defined as follows:
值：该值定义如下：
* Total association requests : 4 octets
* 关联请求总数：4个八位字节
* Total associations accepted : 4 octets
* 接受的关联总数：4个八位字节
* Total associations rejected : 4 octets
* 拒绝的关联总数：4个八位字节
* Current associations : 4 octets
* 当前关联：4个八位字节
* For each associated station,
* 对于每个相关站，
+ Station MAC address : 6 octets
+ 站点MAC地址：6个八位字节
+ Power save state : 1 octet
+ 节能状态：1个八位字节
+ Current Tx rate : 1 octet
+ 当前发送速率：1个八位字节
+ Rate of last packet : 1 octet
+ 最后一个数据包的速率：1个八位字节
+ Preamble type : 1 octet
+ 前导码类型：1个八位组
+ WMM/U-APSD state : 1 octet
+ WMM/U-APSD状态：1个八位组
The status IE is included in the status response message sent by the WTP to the AC. It contains a set of fields that are used to indicate the status of various states at the WTP or each BSS configured in the WTP.
状态IE包含在WTP发送给AC的状态响应消息中。它包含一组字段，用于指示WTP或WTP中配置的每个BSS的各种状态。
Element ID : 33
元素ID:33
Length : 2 octets
长度：2个八位字节
Value : The value is defined as follows:
值：该值定义如下：
Enterprise Resource Planning (ERP) element, if applicable. If not applicable, then this field MUST be set to 0.
企业资源规划（ERP）要素，如适用。如果不适用，则此字段必须设置为0。
Noise Floor : 1 octet
噪音地板：1个八位组
This element is used by the AC to configure the set of events that it wants to be notified by the WTP.
AC使用此元素配置它希望由WTP通知的事件集。
Element ID : 34
元素ID:34
Length : 4 octets
长度：4个八位字节
Value : The value is defined as follows:
值：该值定义如下：
* Radar Detection - 1 octet
* 雷达探测-1八位组
+ Bit 0 : 1 = notify on detecting radar interference, 0 otherwise.
+ 位0:1=检测到雷达干扰时通知，否则为0。
+ Bit 1 : 1 = notify of channel change due to radar interference, 0 otherwise.
+ 第1位：1=通知由于雷达干扰导致的信道变化，否则为0。
+ All other bits are reserved.
+ 所有其他位均保留。
* Excessive Retry Event - 1 octet. Number of successive frames that have not been acknowledged by a client. A value of 0 disables notification.
* 重试事件过多-1个八位字节。客户端尚未确认的连续帧数。值为0将禁用通知。
* Noise Floor Threshold - 1 octet. Defines the threshold above which an event would be generated by the WTP.
* 噪音下限-1个八位组。定义WTP生成事件的阈值。
* 802.11 Management and Action Frame Notification - 1 octet.
* 802.11管理和操作帧通知-1个八位组。
+ Bit 0 : If set, notify the AC of Probe Requests from stations (please use with caution). If reset, then no Probe Response notification is needed.
+ 位0：如果设置，通知AC来自站点的探测请求（请小心使用）。如果重置，则不需要探测器响应通知。
+ Bit 1 : If set, the WTP should notify the AC of all other management frames from stations.
+ 位1：如果设置，WTP应通知AC来自站点的所有其他管理帧。
+ All other bits are reserved.
+ 所有其他位均保留。
This element is used by the WTP to notify the AC of the detection of radar interference and any channel changes as a result of this detection.
WTP使用该元件通知AC检测到雷达干扰以及该检测导致的任何信道变化。
Element ID : 35
元素ID:35
Length : 10 octets
长度：10个八位字节
Value : Defined as follows:
值：定义如下：
BSSID : 6 octets. The BSSID of the WLAN interface that detected the radar interference.
BSSID:6个八位组。检测到雷达干扰的WLAN接口的BSSID。
Channel : 2 octets. The channel on which radar interference was detected.
频道：2个八位组。检测到雷达干扰的通道。
New Channel : 2 octets. The new channel to which the WTP moved as a result of the detection of radar interference.
新频道：2个八位组。由于检测到雷达干扰，WTP移动到的新信道。
This element is used by the WTP to indicate excessive retry events on transmission to an associated station.
WTP使用此元素指示传输到相关站点时发生的过多重试事件。
Element ID : 36
元素ID:36
Length : 14 octets
长度：14个八位字节
Value : Defined as follows:
值：定义如下：
Station MAC : 6 octets
MAC站：6个八位组
Associated BSSID : 6 octets
相关BSSID:6个八位组
Length of last burst of excessive retries : 2 octets.
最后一次过度重试突发的长度：2个八位字节。
This element is used by the WTP to notify the AC of the current noise floor at one of the WLAN interfaces exceeding the configured noise floor threshold.
WTP使用此元素通知AC其中一个WLAN接口处的当前噪声地板超过配置的噪声地板阈值。
Element ID : 37
元素ID:37
Length : 10 octets
长度：10个八位字节
Value : Defined as follows:
值：定义如下：
BSSID : 6 octets
BSSID:6个八位组
Current Channel : 2 octets
当前频道：2个八位组
Current Noise Floor : 2 octets
当前噪声下限：2个八位字节
This element provides a generic capability for either a WTP or an AC to send a raw 802.11 frame to the other party. For example, it can be used to notify the AC of station association/disassociation events in the case of Local MAC architectures.
该元素为WTP或AC提供向另一方发送原始802.11帧的通用能力。例如，在本地MAC架构的情况下，它可用于通知AC站点关联/解除关联事件。
Element ID : 252
元素ID:252
Length : Variable
长度：可变
Value : A raw 802.11 frame
值：原始802.11帧
This element is used to transfer vendor-specific information between the WTP and the AC.
此元素用于在WTP和AC之间传输供应商特定信息。
Element ID : 253
元素ID:253
Length : Variable, > 3
长度：可变，>3
Value : This variable-length element starts with a 3-octet Organizationally Unique Identifier (OUI), followed by a series of octets that are specific to the vendor represented by the OUI.
值：此可变长度元素以3个八位字节的组织唯一标识符（OUI）开始，然后是一系列八位字节，这些八位字节特定于由OUI表示的供应商。
This element type can be used to recursively define a variable-length element that should be interpreted as a series of other elements defined in this section. It can be used to bound a set of elements as a unit.
此元素类型可用于递归定义可变长度元素，该元素应解释为本节中定义的一系列其他元素。它可以用于将一组元素绑定为一个单元。
Element ID : 254
元素ID:254
Length : Variable
长度：可变
Value : A variable length element that contains a set of one or more elements defined in this section.
值：一个可变长度的元素，包含一组在本节中定义的一个或多个元素。
This is a generic element type that can be used to pad the packets, if necessary.
这是一种通用元素类型，如有必要，可用于填充数据包。
Element ID : 255
元素ID:255
Length : Variable
长度：可变
Value : A variable-length element that MUST be filled with all 0s at the source and MUST be ignored at the destination.
Value：一个可变长度元素，必须在源位置用所有0填充，在目标位置必须忽略。
At the start of the SLAPP 802.11 Control Protocol, the WTP sends a registration request to the AC that it authenticated with. The registration request carries a list of information elements indicating the WTP's capabilities to the AC. The message starts with the SLAPP 802.11 Control Protocol header (Figure 8) with a SLAPP Control Protocol message type of 1.
在SLAPP 802.11控制协议开始时，WTP向其进行身份验证的AC发送注册请求。注册请求携带一个信息元素列表，指示WTP对AC的能力。该消息以SLAPP 802.11控制协议头（图8）开始，SLAPP控制协议消息类型为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SLAPP 802.11 Registration Request
图9:SLAPP802.11注册请求
Flags : Reserved
旗帜：保留
Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request.
事务ID：WTP在新注册阶段开始时选择的32位随机数。AC在注册响应中使用此编号，以使响应与相应的请求相匹配。
The following information elements are mandatory in the capabilities exchange:
以下信息元素在功能交换中是必需的：
1 : CAPWAP mode
1:CAPWAP模式
2 : Number of WLAN interfaces
2：WLAN接口的数量
For each WLAN interface:
对于每个WLAN接口：
7 : 802.11 PHY mode and Channel Information
7:802.11物理层模式和信道信息
8 : Cryptographic Capability
8：加密能力
9 : Other 802.11 standards support
9：其他802.11标准支持
The following information elements may be optionally included in the registration request:
以下信息元素可选择性地包括在注册请求中：
For each WLAN interface:
对于每个WLAN接口：
4 : WLAN Interface HW Vendor ID
4:WLAN接口硬件供应商ID
5 : WLAN Interface Type ID
5:WLAN接口类型ID
6 : Regulatory Domain
6：监管领域
10 : Antenna Information Element
10：天线信息元
11 : Number of BSSIDs
11：BSSID的数量
253 : Vendor-Specific Element
253：特定于供应商的要素
Upon receiving a registration request, the AC may either chose to accept the WTP or reject its registration request.
收到注册请求后，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SLAPP 802.11 Registration Response
图10:SLAPP802.11注册响应
Flags :
旗帜：
Bit 0 : Indicates the status of the transaction, 0 = successful response from the AC, 1 = the registration request is being rejected by the AC.
位0：表示事务的状态，0=来自AC的成功响应，1=AC拒绝注册请求。
Bits 1-7 : Reserved
第1-7位：保留
Bits 8-15 : If bit 0 = 1 (i.e., the registration request is being rejected by the AC), then this field contains a reason code. Otherwise, these bits are currently set to 0. The following reason codes are currently defined:
位8-15：如果位0=1（即，注册请求被AC拒绝），则该字段包含原因码。否则，这些位当前设置为0。目前定义了以下原因代码：
0 : Reserved
0:保留
1 : Unspecified reason
1：未说明原因
2 : Unable to handle more WTPs
2:无法处理更多WTP
3 : Incompatible capabilities
3：不兼容的能力
4-255 : Reserved
4-255：保留
Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request.
事务ID：WTP在新注册阶段开始时选择的32位随机数。AC在注册响应中使用此编号，以使响应与相应的请求相匹配。
The following information elements are mandatory if the transaction is successful:
如果交易成功，则以下信息元素是必需的：
1 : CAPWAP mode - the mode that the AC chooses from among the list of supported modes sent by the WTP in the registration request.
1:CAPWAP模式-AC在注册请求中从WTP发送的支持模式列表中选择的模式。
24 : SLAPP registration ID
24:SLAPP注册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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SLAPP 802.11 De-Registration Request
图11:SLAPP 802.11注销请求
Flags : Reserved
旗帜：保留
SLAPP Registration ID : The registration ID assigned by the AC upon successful registration.
SLAPP注册ID：成功注册后AC分配的注册ID。
Reason Code : The following are valid values:
原因代码：以下是有效值：
0 : Unspecified reason
0:未指定原因
1 : The device that is the source of the frame is going down.
1：作为帧源的设备正在下降。
All other values are reserved.
所有其他值均保留。
The De-Registration Response is a simple ACK from the recipient of the corresponding De-Registration Request.
注销响应是来自相应注销请求接收者的简单确认。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SLAPP 802.11 De-Registration Response
图12:SLAPP 802.11注销响应
Flags : Reserved
旗帜：保留
SLAPP Registration ID : The registration ID assigned by the AC upon successful registration.
SLAPP注册ID：成功注册后AC分配的注册ID。
Reason Code : The same reason code used in the corresponding request.
原因代码：与相应请求中使用的原因代码相同。
The Configuration Request message is used by the WTP to request a set of configurations for each BSS that the AC wishes to configure at the WTP.
WTP使用配置请求消息为AC希望在WTP处配置的每个BSS请求一组配置。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: SLAPP 802.11 Configuration Request
图13:SLAPP802.11配置请求
The Information Element ID list field contains the list of IEs that the WTP is interested in obtaining configuration information for.
信息元素ID列表字段包含WTP有兴趣获取配置信息的IE列表。
The Configuration Response message is used by the AC to respond to a Configuration Request by the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SLAPP 802.11 Configuration Response
图14:SLAPP 802.11配置响应
The following information elements are mandatory in the Configuration Response:
配置响应中必须包含以下信息元素：
01: CAPWAP mode
01:CAPWAP模式
For each WLAN interface:
对于每个WLAN接口：
03: WLAN Interface Index
03:WLAN接口索引
27: Radio Mode
27：无线电模式
07: 802.11 PHY mode and Channel Selection
07:802.11物理层模式和信道选择
For each BSSID:
对于每个BSSID：
12: BSSID Index
12:BSSID索引
13: ESSID
13:ESSID
08: Cryptographic Selection
08：加密选择
The following information elements may be optionally included in the Configuration Response:
以下信息元素可以选择性地包括在配置响应中：
10: Antenna Information Element
10：天线信息元
25: WTP Name
25:WTP名称
For each WLAN interface:
对于每个WLAN接口：
For each BSSID:
对于每个BSSID：
14: ESSID Announcement Policy
14:ESSID公告政策
15: Beacon Interval
15：信标间隔
16: DTIM Period
16:DTIM周期
17: Basic Rates
17：基本费率
18: Supported Rates
18：支持的费率
19: Retry Count
19:重试计数
20: Fragmentation Threshold
20：碎片阈值
21: RTS Threshold
21:RTS阈值
22: Short/Long Preamble
22：短/长序言
23: 802.1Q Tag
23:802.1Q标签
253: Vendor-Specific Element
253：特定于供应商的要素
If any of the optional IEs is absent in the Configuration Response message, then their default values are applied by the WTP.
如果配置响应消息中缺少任何可选IE，则WTP将应用它们的默认值。
The Configuration Update message is initiated by the AC to push modified or updated configuration to the WTP. It has a format similar to that of the Configuration Response message defined above.
配置更新消息由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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: SLAPP 802.11 Configuration Update
图15:SLAPP 802.11配置更新
The list of mandatory and optional IEs for the Configuration Update message is the same as that for the Configuration Response message.
配置更新消息的强制和可选IE列表与配置响应消息的列表相同。
The Configuration Acknowledgment message is used by the WTP to inform the AC whether it has accepted the prior Configuration Update or Configuration Response message. The WTP can reject the configuration sent by the AC, in which case it MUST return to the discovery state.
WTP使用配置确认消息通知AC是否已接受先前的配置更新或配置响应消息。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: SLAPP 802.11 Configuration ACK
图16:SLAPP 802.11配置确认
The Status Code field contains one of the following values:
状态代码字段包含以下值之一：
0 : Success - The WTP accepts that the configuration pushed by the AC and has applied it.
0：成功-WTP接受AC推送的配置并已应用该配置。
1 : Failure - The WTP did not accept the configuration pushed by the AC and MUST be de-registered at the AC.
1：故障-WTP不接受AC推送的配置，必须在AC取消注册。
The status request message is used by the AC to request the configuration and operational status from the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SLAPP 802.11 Status Request
图17:SLAPP 802.11状态请求
The Information Element ID list contains the list of IEs for which the AC requests status.
信息元素ID列表包含AC请求其状态的IE列表。
The status response message is used by the WTP to respond to a status request from the AC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SLAPP 802.11 Status Response
图18:SLAPP 802.11状态响应
The Flags field contains one of the following values:
“标志”字段包含以下值之一：
Bit 0 : If set, Unknown AC or SLAPP registration ID. If this bit is reset, then this indicates a successful response.
位0：如果设置，未知AC或SLAPP注册ID。如果重置此位，则表示响应成功。
Bit 1 : If set, the WTP indicates that it has not been configured yet; otherwise, the WTP is in a configured state.
位1：如果设置，则WTP指示尚未配置；否则，WTP处于已配置状态。
All other values are reserved.
所有其他值均保留。
The status IE is mandatory in a status response message.
状态IE在状态响应消息中是必需的。
The Statistics request message is used by the AC to request statistics information from the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SLAPP 802.11 Statistics Request
图19:SLAPP802.11统计数据请求
The Flags field contains the following bits:
标志字段包含以下位：
Bit 0 : If set to 1, then the WTP should reset the counters after sending the statistics response message.
位0：如果设置为1，则WTP应在发送统计响应消息后重置计数器。
All other bits are reserved and MUST be set to 0 by the source and ignored by the destination.
所有其他位都是保留的，必须由源设置为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: SLAPP 802.11 Statistics Response
图20:SLAPP802.11统计响应
The Flags field contains the following bits:
标志字段包含以下位：
Bit 0 : If set, then the counters have been reset as requested by the AC.
位0：如果设置，则计数器已按照AC的要求重置。
Bit 1 : If set, then the WTP has encountered a statistics request from either an unknown AC or with an unknown SLAPP registration ID.
位1：如果设置，则WTP遇到来自未知AC或具有未知SLAP注册ID的统计信息请求。
Bit 2 : If set, WTP indicates that it has not been configured yet; otherwise, the WTP is in a configured state.
位2：如果设置，WTP表示尚未配置；否则，WTP处于已配置状态。
All other bits are reserved.
所有其他位均保留。
The keepalive messages can be initiated by either the WTP or the AC. It is used to probe the availability of the other party and the path between them. The initial message is termed the keepalive request, while the response to that message is termed the keepalive response.
keepalive消息可以由WTP或AC启动。它用于探测另一方的可用性以及它们之间的路径。初始消息称为keepalive请求，而对该消息的响应称为keepalive响应。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: SLAPP Keepalive Packet
图21:SLAPP保留数据包
The Flags field has the following values:
“标志”字段具有以下值：
Bit 0 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message.
位0：在keepalive请求消息中设置为0，在keepalive响应消息中设置为1。
Bit 1 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message if the initiator of the keepalive request is unknown or the SLAPP registration ID is incorrect, and set to 0 otherwise.
位1：在keepalive请求消息中设置为0，如果keepalive请求的发起人未知或SLAP注册ID不正确，则在keepalive响应消息中设置为1，否则设置为0。
All other bits are reserved and must be set to 0 by the source and ignored at the destination.
所有其他位都是保留的，必须由源设置为0，并在目标处忽略。
In CAPWAP mode 5, the 802.11 crypto functions are performed at the AC. So there is no need for the AC to send PTKs/GTKs to the WTP. When one of the CAPWAP Modes 1-4 has been negotiated between the AC and WTP, it is necessary for the AC to send both unicast and broadcast/multicast keys to the WTP. This is accomplished after the 802.1x authenticator (which resides on the AC) has successfully authenticated the supplicant. Key Configuration Requests are differentiated -- unicast or broadcast -- by setting or clearing the high-order bit of the "Flags" field. The setting of this bit determines the contents of the Key Configuration Request following the SLAPP Registration ID.
在CAPWAP模式5中，802.11加密功能在AC处执行。因此AC无需向WTP发送PTK/GTK。当AC和WTP之间协商CAPWAP模式1-4之一时，AC需要向WTP发送单播和广播/多播密钥。这是在802.1x认证器（位于AC上）成功认证请求者后完成的。通过设置或清除“标志”字段的高位，可以区分关键配置请求（单播或广播）。该位的设置确定SLAP注册ID之后的密钥配置请求的内容。
The Unicast Key Configuration Request is used by the AC to inform the WTP of the key to use when protecting unicast frames to and from a specified supplicant.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast key length | unicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast key length | unicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Unicast Key Configuration Request
图22：单播密钥配置请求
Note the high-order bit of the "Flags" field is cleared to indicate a unicast key is being sent. The 802.1Q tag field is used to indicate to the WTP which VLAN this supplicant is in and which broadcast/ multicast key to use when communicating to it with broadcast/ multicast frames.
注意，“标志”字段的高位被清除，以指示正在发送单播密钥。802.1Q标记字段用于向WTP指示此请求者所在的VLAN以及使用广播/多播帧与其通信时要使用的广播/多播密钥。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |1| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD | broadcast/multicast key length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ broadcast/multicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |1| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD | broadcast/multicast key length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ broadcast/multicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Group Key Configuration Request
图23：组密钥配置请求
Note the high-order bit of the "Flags" field is set, indicating a broadcast/multicast key is being sent. The bits marked "RSVD" are reserved and MUST be set to zero by the AC and ignored by the WTP.
注：设置了“标志”字段的高位，表示正在发送广播/多播密钥。标记为“RSVD”的位是保留的，AC必须将其设置为零，WTP将其忽略。
The WTP acknowledges receipt of a Unicast Key Configuration Request by sending a Unicast Key Configuration Response. This response mirrors the request but does not send back the key length or the key itself. (The RSVD bits are returned for alignment purposes and MUST be set to zero by the WTP and ignored by the AC.)
WTP通过发送单播密钥配置响应来确认收到单播密钥配置请求。此响应镜像请求，但不发回密钥长度或密钥本身。（RSVD位返回用于对齐目的，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Unicast Key Configuration Response
图24：单播密钥配置响应
The WTP acknowledges receipt of a Multicast Key Configuration Request by sending a Multicast Key Configuration Response. This response mirrors the request, but it does not send back the key length or the key itself. (The RSVD bits are returned for alignment purposes and MUST be set to zero by the WTP and ignored by the AC.)
WTP通过发送多播密钥配置响应来确认接收到多播密钥配置请求。此响应镜像请求，但不会发回密钥长度或密钥本身。（RSVD位返回用于对齐目的，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Group Key Configuration Response
图25：组密钥配置响应
An AC may want to periodically monitor the health of a WTP, collect the necessary information for diagnostics, and get notifications on pre-defined events at the WTP that may be of interest. This section defines a set of WTP statistics and events and describes the process of collecting statistics from WTPs and configuring the event notification mechanism at the WTP. It is beyond the scope of this document to describe what should/could be done with the collected information.
AC可能希望定期监控WTP的运行状况，收集诊断所需的信息，并获取有关WTP中可能感兴趣的预定义事件的通知。本节定义了一组WTP统计信息和事件，并描述了从WTP收集统计信息和在WTP配置事件通知机制的过程。描述应/可利用收集的信息做些什么超出了本文件的范围。
The simple statistics collection procedure defined here does not require the WTP to maintain any timers or any similar mechanisms. A WTP is responsible only for maintaining the statistics defined in Information Elements 29, 30, 31, and 32. The WTP must also respond to a statistics request message from the AC by delivering the appropriate statistics to the AC using a statistics response message. For example, if an AC is interested in gathering periodic statistics about some specific statistics, it is the responsibility of the AC to poll the WTP at the appropriate intervals.
此处定义的简单统计数据收集过程不需要WTP维护任何计时器或任何类似机制。WTP仅负责维护信息元素29、30、31和32中定义的统计信息。WTP还必须通过使用统计响应消息向AC发送适当的统计信息来响应来自AC的统计信息请求消息。例如，如果AC有兴趣收集有关某些特定统计数据的定期统计数据，则AC有责任在适当的时间间隔轮询WTP。
The event notification process includes the following: 1) Event Registration: the registration of events of interest at the WTP by the AC and 2) Notification: The communication of event-related information by the WTP to the AC whenever the conditions for a specific registered event has occurred. The set of events supported by a WTP and the event-specific parameters that may be configured as part of a event registration are given in Section 6.1.3.3.3.
事件通知流程包括以下内容：1）事件登记：AC在WTP登记感兴趣的事件；2）通知：每当发生特定登记事件的条件时，WTP向AC传达事件相关信息。第6.1.3.3节给出了WTP支持的事件集和可配置为事件注册一部分的事件特定参数。
This section defines a set of WTP events along with the event-specific parameters that may be configured by ACs and the event-related information that should be delivered to the ACs by WTPs when the conditions for a particular configured event have occurred.
本节定义了一组WTP事件，以及可能由ACs配置的事件特定参数，以及当特定配置事件的条件发生时，WTP应向ACs发送的事件相关信息。
Radar Detection Event: Configure whether the AC is interested in receiving a notification whenever a radar event is detected. The WTP may notify the AC about the type of radar interference and the new channel that the WTP has moved to as a result, if any, using the Radar Detection Event Element (element ID: 35).
雷达检测事件：配置AC是否有兴趣在检测到雷达事件时接收通知。WTP可使用雷达检测事件元素（元素ID:35）将雷达干扰类型和WTP移动到的新信道（如有）通知AC。
Excessive Retry Event: Configure the number of consecutive transmission failures before a notification is generated. The WTP may notify the MAC address of the station (STA) and the number of consecutive unacknowledged frames so far using the Excessive Retry Event Element (element ID : 36).
过度重试事件：配置在生成通知之前连续传输失败的次数。WTP可以使用过度重试事件元素（元素ID:36）通知站（STA）的MAC地址和到目前为止连续的未确认帧的数目。
Noise Floor Event: Configure the noise floor threshold above which an event notification would be generated by the WTP. The WTP may notify the AC with the most recent measured noise floor that exceeded the configured threshold using the Noise Floor Event Element (element ID : 37).
噪声地板事件：配置噪声地板阈值，超过该阈值时，WTP将生成事件通知。WTP可使用噪声地板事件元素（元素ID:37）通知AC最近测量的噪声地板超过配置的阈值。
De-Authentication Event: Configure whether the AC is interested in receiving a notification whenever a station has been de-authenticated by the WTP. The WTP may notify the AC with the MAC address of the STA along with a reason code (inactivity, etc.).
取消身份验证事件：配置AC是否有兴趣在WTP取消身份验证站点时接收通知。WTP可以向AC通知STA的MAC地址以及原因码（不活动等）。
Association Event: Needed in Local MAC architecture.
关联事件：在本地MAC架构中需要。
Disassociation Event: Needed in Local MAC architecture.
解除关联事件：在本地MAC体系结构中需要。
The SLAPP 802.11 Control Protocol operation is described in this section.
本节描述了SLAPP 802.11控制协议的操作。
+-------------+
| discovering |<-------------------------------+<----+
+-------------+ | |
^ ^ | |
| | +-----------+ | |
| | | securing | | |
| | +----+------+ | |
| | | | |
| | v | |
| | +--------------+ | |
| | +--->| Unregistered | | |
| | | +------+-------+ | |
| | | | | |
| | | |Registration | |
| | |Timeout |Request | |
| | | | | |
| | | v | |
| | | +--------------+ | |
| | +----+ Registration | | |
| | | | | |
| | Reject | | | |
| +--------+ Pending | | |
| nTimeout>3| | | |
| | | | |
| +------+-------+ | |
| | | |
| |Accept | |
| | | |
| | | |
| v | |
| +------+-------+ | |
| | Registered | | |
| +--->| | | |
| | +------+-------+ | |
| | | | |
| |Timeout |Config | |
| | |Request | |
| | | | |
| | v | |
| | +------+-------+ | |
| +----+ | Reject| |
| |Configuration | | |
| Reject | Pending | | |
+-----------+ | | |
+-------------+
| discovering |<-------------------------------+<----+
+-------------+ | |
^ ^ | |
| | +-----------+ | |
| | | securing | | |
| | +----+------+ | |
| | | | |
| | v | |
| | +--------------+ | |
| | +--->| Unregistered | | |
| | | +------+-------+ | |
| | | | | |
| | | |Registration | |
| | |Timeout |Request | |
| | | | | |
| | | v | |
| | | +--------------+ | |
| | +----+ Registration | | |
| | | | | |
| | Reject | | | |
| +--------+ Pending | | |
| nTimeout>3| | | |
| | | | |
| +------+-------+ | |
| | | |
| |Accept | |
| | | |
| | | |
| v | |
| +------+-------+ | |
| | Registered | | |
| +--->| | | |
| | +------+-------+ | |
| | | | |
| |Timeout |Config | |
| | |Request | |
| | | | |
| | v | |
| | +------+-------+ | |
| +----+ | Reject| |
| |Configuration | | |
| Reject | Pending | | |
+-----------+ | | |
^ nTimeout>3+------+-------+ | |
| | | |
| | | |
De-reg| | +----------------+ | |
resp | | v Accept | | |
+----+---+ +------+----+--+ +-+---+--+ |
| | De-reg| | | Update | |
| De +<------+ Configured +-----------+ | |
|Register| req | | | Pending| |
| | | | +----+---+ |
+--------+ +------+-------+ |
| |
| |
| |
Too |Many |
Keepalive |
Failures |
| |
| |
| De-Register |
+-------------------------------+
^ nTimeout>3+------+-------+ | |
| | | |
| | | |
De-reg| | +----------------+ | |
resp | | v Accept | | |
+----+---+ +------+----+--+ +-+---+--+ |
| | De-reg| | | Update | |
| De +<------+ Configured +-----------+ | |
|Register| req | | | Pending| |
| | | | +----+---+ |
+--------+ +------+-------+ |
| |
| |
| |
Too |Many |
Keepalive |
Failures |
| |
| |
| De-Register |
+-------------------------------+
In Configured and/or Registered states, respond to Status Requests, Statistics Requests, Keepalives, Key Config
在已配置和/或已注册状态下，响应状态请求、统计信息请求、Keepalives、密钥配置
Figure 26: SLAPP 802.11 Control Protocol at the WTP
图26:WTP上的SLAPP 802.11控制协议
Unregistered: The transition into this state is from the securing state (Figure 3). Send registration request message to move to Registration Pending state, set timer for registration response.
未注册：从安全状态转换到该状态（图3）。发送注册请求消息以移动到注册挂起状态，为注册响应设置计时器。
Registration Pending: On a registration response from the AC, cancel registration timer. If the response is successful, move to Registered state. If not, move to discovering state (Figure 3). If timer expires, if nTimeout >3, then move to discovering state. If not, return to Unregistered state.
注册挂起：在来自AC的注册响应上，取消注册计时器。如果响应成功，则移动到注册状态。如果不是，则转到发现状态（图3）。如果计时器过期，如果nTimeout>3，则移动到发现状态。如果不是，则返回未注册状态。
Registered: Send Configuration Request message to AC to move to Configuration Pending state, and set timer for Configuration Response. In this state, respond to status request, statistics request, and keepalive messages from the AC.
已注册：向AC发送配置请求消息以移动到配置挂起状态，并为配置响应设置计时器。在此状态下，响应来自AC的状态请求、统计信息请求和保留消息。
Configuration Pending: If a Configuration Response is received from the AC, cancel the Configuration Response timer. If the response is successful and the configuration is acceptable, then send the Configuration ACK message to AC, and move to Configured state. If
配置挂起：如果从AC接收到配置响应，请取消配置响应计时器。如果响应成功且配置可接受，则向AC发送配置确认消息，并移至配置状态。如果
the Configuration Request is rejected or the configuration is not acceptable, then send a de-register request to the AC and move to discovering. If the Configuration Response timer expires, move to Registered state unless nTimeout >3, in which case move to discovering state.
配置请求被拒绝或配置不可接受，然后向AC发送取消注册请求，并转至查找。如果配置响应计时器过期，则移动到已注册状态，除非nTimeout>3，在这种情况下，移动到发现状态。
Configured: In the Configured state, the WTP responds to the status request, statistics request, and keepalive messages from the AC. If it receives a de-register request message from the AC, then it sends a de-register response to the AC and moves to the discovering state. If the WTP receives a Configuration Update message, then it moves to the Update Pending state. If it receives too many consecutive keepalive failures (no responses from the AC to keepalive requests), then it sends a de-register message to the AC and moves to the discovering state.
已配置：在已配置状态下，WTP响应来自AC的状态请求、统计请求和keepalive消息。如果它从AC接收到注销请求消息，则它向AC发送注销响应并移动到发现状态。如果WTP收到配置更新消息，则它将移动到更新挂起状态。如果它接收到太多连续的keepalive失败（AC没有响应keepalive请求），那么它将向AC发送一条注销消息，并移动到发现状态。
Update Pending: In the Update Pending state, the WTP analyzes the configuration information received in the Configuration Update message. If the configuration is found to be acceptable, then it applies the configuration and returns to the Configured state. If the WTP chooses to reject the configuration update, then it sends a de-register request to the AC and moves to the discovering state.
更新挂起：在更新挂起状态下，WTP分析配置更新消息中接收到的配置信息。如果发现配置是可接受的，则应用该配置并返回到已配置状态。如果WTP选择拒绝配置更新，则它会向AC发送一个注销请求，并移动到发现状态。
De-register: From the Configured state, the WTP moves to the De-register state when it receives a de-register request message from the AC. It sends a de-register response to the AC and moves to the discovering state.
取消注册：从配置状态，WTP在收到AC发出的取消注册请求消息时，移动到取消注册状态。它向AC发送取消注册响应，并移动到发现状态。
+----------+
| securing |
+----+-----+
|
|
|
v
+--------------+
+--------| Unregistered |
| +----+---------+
| |
|Timeout |Register
| |request
| v +-------------+
| +----------+ Accept | Registration|
| +---+Register +----------->| Pending |
| | |Processing| +-+-----+-----+
| | +----------+ | |
| | | |
| |Reject Timeout |
| | | |Config
| | | |Request
| | +--------------+ | |
| +----->| |<------+ |
| | discovering | v
+----------->| | +------------+
+--------------+ | Registered |
^ ^ ^ +----+-------+
| | | |
| | | |Config
| | | |Response
| | | v
| | | Timeout +------------+
| | +----------| Config |
| | or Reject | Pending |
| | +----+-------+
| | |
| | |Config ACK
| | v
| |De-Register +------------+
| +-------------| |
| or Keepalive | Configured |<--+
| failures | | |
| +----+-------+ |
+----------+
| securing |
+----+-----+
|
|
|
v
+--------------+
+--------| Unregistered |
| +----+---------+
| |
|Timeout |Register
| |request
| v +-------------+
| +----------+ Accept | Registration|
| +---+Register +----------->| Pending |
| | |Processing| +-+-----+-----+
| | +----------+ | |
| | | |
| |Reject Timeout |
| | | |Config
| | | |Request
| | +--------------+ | |
| +----->| |<------+ |
| | discovering | v
+----------->| | +------------+
+--------------+ | Registered |
^ ^ ^ +----+-------+
| | | |
| | | |Config
| | | |Response
| | | v
| | | Timeout +------------+
| | +----------| Config |
| | or Reject | Pending |
| | +----+-------+
| | |
| | |Config ACK
| | v
| |De-Register +------------+
| +-------------| |
| or Keepalive | Configured |<--+
| failures | | |
| +----+-------+ |
Reject| | |
or| | |
Timeout +-----------+ |Config |
| | Update | |Update |
+-----| Pending |<-----+ |
+----+------+ |
| Accept |
+-------------------------+
Reject| | |
or| | |
Timeout +-----------+ |Config |
| | Update | |Update |
+-----| Pending |<-----+ |
+----+------+ |
| Accept |
+-------------------------+
Figure 27: SLAPP 802.11 Control Protocol at the AC
图27:AC上的SLAPP 802.11控制协议
The states "securing" and "discovering" are described in Figure 3.
图3描述了“安全”和“发现”状态。
Unregistered: This state is entered from the securing state described in Figure 3. In this state, the AC is waiting for a registration request message from the WTP. Upon receiving the registration request message, it moves into the Registration Processing state.
未注册：此状态是从图3中描述的安全状态输入的。在此状态下，AC正在等待来自WTP的注册请求消息。收到注册请求消息后，它将进入注册处理状态。
Registration Processing: In this state, the AC must determine whether or not it can accept the new WTP. If the AC decides to accept the WTP, it must pick a CAPWAP mode to operate in and send a registration response message with a success code and moves to the Registration Pending state. If the AC chooses to reject the current registration request from the WTP, it must send a registration response with a failure code and move to the discovering state.
注册处理：在此状态下，AC必须确定是否可以接受新的WTP。如果AC决定接受WTP，则必须选择CAPWAP模式进行操作，并发送带有成功代码的注册响应消息，然后进入注册挂起状态。如果AC选择拒绝来自WTP的当前注册请求，则必须发送带有故障代码的注册响应，并移动到发现状态。
Registration Pending: If the timer expires before a response from the WTP is received, then the AC destroys the registration state and moves to the discovering state. If a Configuration Request message is received from the WTP, then the AC moves into the Registered state and processes the Configuration Request message. It sends a Configuration Response message to the WTP with the appropriate IEs and moves into the Configuration Pending state.
注册挂起：如果计时器在收到WTP的响应之前过期，则AC将销毁注册状态并移动到发现状态。如果从WTP接收到配置请求消息，则AC进入注册状态并处理配置请求消息。它使用适当的IEs向WTP发送配置响应消息，并进入配置挂起状态。
Configuration Pending: If the timer expires before a response is received from the WTP, then the AC destroys the current registration and moves into the discovering state. If a Configuration ACK is received from the WTP, but contains a failure code, then the AC again destroys the registration state and moves into the discovering state. If the Configuration ACK from the WTP is successful, then the AC moves to the Configured state.
配置挂起：如果计时器在从WTP收到响应之前过期，则AC将销毁当前注册并进入发现状态。如果从WTP接收到配置ACK，但包含故障代码，则AC再次破坏注册状态并进入发现状态。如果来自WTP的配置确认成功，则AC移动到已配置状态。
Configured: In the Configured state, the AC can send a status request, statistics request, keepalive, and Key Configuration messages to the WTP. Any response to these messages from the WTP
已配置：在已配置状态下，AC可以向WTP发送状态请求、统计信息请求、keepalive和密钥配置消息。WTP对这些消息的任何响应
that indicates an unknown SLAPP registration ID or an unknown AC causes the AC to destroy any registration or configuration state and move to the discovering state. From the configured state, the AC can send a Configuration Update message and move into the Update Pending state. If it receives a de-register request from the WTP, then it destroys all current registration and configuration state and moves into the discovering state. If a number of successive keepalive messages go unacknowledged by the WTP, then the AC moves into the discovering state.
表示未知SLAP注册ID或未知AC导致AC破坏任何注册或配置状态并移动到发现状态。从配置状态，AC可以发送配置更新消息并进入更新挂起状态。如果它收到来自WTP的注销请求，则它将销毁所有当前注册和配置状态，并进入发现状态。如果WTP未确认多个连续的keepalive消息，则AC进入发现状态。
Update Pending: When the AC receives a Configuration ACK message with a success code, then it returns to the Configured state. If the status code is a failure or if the timer expires before the Configuration ACK is received from the WTP, the AC destroys all registration and configuration state for the WTP and moves into the discovering state.
更新挂起：当AC接收到带有成功代码的配置确认消息时，它将返回到已配置状态。如果状态代码为故障或在从WTP接收到配置确认之前计时器过期，AC将销毁WTP的所有注册和配置状态，并进入发现状态。
The Image Download protocol is a control protocol defined in this document that is generic enough to be agnostic to the underlying technology.
图像下载协议是本文档中定义的一种控制协议，它具有足够的通用性，对底层技术不可知。
In the Image Download protocol, the WTP obtains a bootable image from the AC by receiving a series of image transfer packets. Missed image data packets are re-requested by the WTP by sending image data request packets indicating the missing packets.
在映像下载协议中，WTP通过接收一系列映像传输包从AC获得可引导映像。WTP通过发送指示丢失的分组的图像数据请求分组来重新请求丢失的图像数据分组。
The image to download is divided into slices of equal size (except for the last slice, which can be less than the slice size provided, it is also greater than zero). The size of each slice depends on the MTU determined by the DTLS exchange and SHOULD be the realized MTU minus the size of an Image Download Request (Figure 29).
要下载的图像被分成大小相同的片段（除了最后一个片段，它可以小于提供的片段大小，也可以大于零）。每个切片的大小取决于DTLS交换确定的MTU，应该是实现的MTU减去图像下载请求的大小（图29）。
Note that the Image Download packet and Image Download Request is encapsulated in a DTLS header that secures the image download.
请注意，映像下载包和映像下载请求封装在DTLS报头中，用于保护映像下载。
The format of an Image Download packet is shown in Figure 28.
图像下载包的格式如图28所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ image data slice ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ image data slice ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: SLAPP Image Download Packet
图28:SLAPP映像下载包
where:
哪里：
length: variable
长度：可变
RESERVED: Unused in this version of SLAPP, MUST be zero (0) on transmission and ignored upon receipt.
保留：此版本的SLAPP中未使用，传输时必须为零（0），接收时忽略。
M: The "More" bit indicating that the current packet is not the final one.
M：表示当前数据包不是最终数据包的“更多”位。
R: The "Request" bit. This bit MUST be set to one (1) when the packet is the response to a request and zero (0) otherwise.
R：“请求”位。当数据包是对请求的响应时，该位必须设置为一（1），否则设置为零（0）。
packet sequence number: A monotonically increasing counter that assigns a unique number to each slice of the image.
数据包序列号：一个单调递增的计数器，为图像的每个片段分配一个唯一的编号。
image data slice: A portion of the bootable image.
映像数据片：可引导映像的一部分。
The format of an Image Download Request is shown in Figure 29.
图像下载请求的格式如图29所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: SLAPP Image Download Request Packet
图29:SLAPP映像下载请求包
where:
哪里：
length: eight (8) octets
长度：八（8）个八位字节
RESERVED: Unused in this version of SLAPP, MUST be zero on transmission and ignored upon receipt.
保留：此版本的SLAPP中未使用，传输时必须为零，接收时忽略。
M: The "More" bit. This MUST be equal to the one (1) when negatively acknowledging a missed packet and set to zero (0) when indicating the end of the Image Download protocol.
M：“更多”一点。当负面确认丢失的数据包时，该值必须等于一（1），当指示图像下载协议结束时，该值必须设置为零（0）。
R: the "Request" bit. This MUST be one in an Image Download Request.
R：“请求”位。这必须是图像下载请求中的一个。
packet sequence number: The packet sequence number of the missing image data slice.
packet sequence number：缺失图像数据片的数据包序列号。
The AC will divide the bootable image into a series of slices and send each slice as an Image Download packet. The size of each image data slice (and therefore the size of each Image Download packet) depends on the MTU of the connection determined during the DTLS handshake. With the transmission of each slice, the AC MUST increment the packet sequence number.
AC将可引导映像划分为一系列片，并将每个片作为映像下载包发送。每个图像数据片的大小（因此每个图像下载包的大小）取决于DTLS握手期间确定的连接的MTU。随着每个片的传输，AC必须增加数据包序列号。
Image Download packets are negatively ACK'd. An AC MUST NOT assume anything about the reception of packets; it sends based upon negative ACKs. One could naively assume that since the packets are sent sequentially, that all packets with a sequence number of "n - 1" are implicitly ack'd by the receipt of a request for the packet with sequence number "n" to be retransmitted. Such an assumption would be incorrect since previous requests could, themselves, have been dropped.
图像下载数据包已被反向确认。AC不得对数据包的接收进行任何假设；它基于否定应答发送消息。人们可以天真地假设，由于分组是按顺序发送的，因此序列号为“n-1”的所有分组都通过接收对序列号为“n”的分组进行重新传输的请求而被隐式地确认。这种假设是不正确的，因为以前的请求本身可能已经被删除。
The Image Download process is initiated by the WTP requesting a packet with the packet sequence number of zero (0). The AC sets the packet sequence counter for this WTP to one (1) and sends the first slice. The "Request" bit for the first slice sent by the AC MUST be set to zero (0) since the first slice was technically not requested.
图像下载过程由WTP发起，WTP请求分组序号为零（0）的分组。AC将该WTP的分组序列计数器设置为一（1），并发送第一个片。AC发送的第一个切片的“请求”位必须设置为零（0），因为第一个切片在技术上没有被请求。
The WTP sets a periodic timer that, when it fires, causes the WTP to send Image Download Requests for slices that have been missed since the last periodic timer had fired. Since individual Image Download packets are not ack'd, the AC MUST NOT set a timer when each one is sent.
WTP设置一个定期计时器，当它启动时，会导致WTP发送自上次定期计时器启动以来丢失的片段的图像下载请求。由于单个图像下载数据包未确认，AC在发送每个数据包时不得设置计时器。
If a WTP notices missed image transfer packets -- when the difference between the packet sequence number of a received image transfer packet and the packet sequence number of the last image transfer packet previously received is greater than one -- it will note that fact in a bitmask. When the periodic timer fires, the WTP will request the slices that are absent from that bitmask. Each slice
如果WTP注意到丢失的图像传输数据包——当接收到的图像传输数据包的数据包序列号与之前接收到的最后一个图像传输数据包的数据包序列号之间的差值大于1时——它将在位掩码中注意到这一事实。当周期计时器触发时，WTP将请求该位掩码中缺少的片。每片
will be requested by sending a Download Request with a length of eight (8) and indicating the sequence number of the packet requested. The AC MUST interleave these retransmissions with packets in the sequence.
将通过发送长度为八（8）的下载请求并指示所请求数据包的序列号来请求。AC必须将这些重传与序列中的数据包交错。
Since both sides implicitly agree upon the MTU of the link, the WTP will know the slice size that the AC will use during the Image Download process. A dropped packet will therefore result in an internal buffer pointer on the WTP being incremented by the slice size and the lost packet requested. When the lost packet is received, it can be inserted into the buffer in the space provided by the pointer increment when its loss was first detected. That is, loss of packet <n> will result in packet <n> being re-requested and when received inserted into the buffer at an offset of <n-1> * <slicesize> from the start of the buffer.
由于双方都隐式地同意链路的MTU，因此WTP将知道AC在图像下载过程中将使用的切片大小。因此，丢弃的数据包将导致WTP上的内部缓冲区指针增加片大小和请求的丢失数据包。当接收到丢失的数据包时，它可以在第一次检测到丢失时插入到指针增量提供的缓冲区中。也就是说，数据包<n>的丢失将导致重新请求数据包<n>，并且当接收到数据包时，将其插入到缓冲区中，从缓冲区开始的偏移量为<n-1>*<slicesize>。
The final packet sent by the AC will not have the "more" bit set, and this indicates to the WTP that the end of the image has been received. This final packet is acknowledged by the WTP indicating the end of the Image Download process.
AC发送的最终数据包将不会设置“更多”位，这向WTP指示已接收到图像的结尾。WTP确认该最终数据包，指示图像下载过程结束。
A lost final packet will result in the AC resending the final packet again (see Section 4.4).
丢失的最终数据包将导致AC重新发送最终数据包（见第4.4节）。
The Image Download protocol is a Negotiated Control Protocol defined for SLAPP. Transitions to it come from the "secure" state and transitions out of it go to the "acquire" state. See Figure 3.
映像下载协议是为SLAP定义的协商控制协议。到它的转换来自“安全”状态，从它到“获取”状态的转换。参见图3。
The AC's state machine for the Image Download protocol is shown in Figure 30. The AC maintains the following variables for its state machine:
图像下载协议的AC状态机如图30所示。AC为其状态机维护以下变量：
seq_num: The current slice that is being sent.
seq_num：正在发送的当前切片。
nslices: The total number of slices in the image.
nslices：图像中的切片总数。
req_num: The number of the slice that was requested.
req_num：请求的切片的编号。
more: Whether the "More bit" in the packet should be set.
更多：是否应设置数据包中的“更多位”。
starved: A timer that sets the maximum amount of time in which an AC will attempt to download an image.
饥饿：设置AC尝试下载图像的最大时间的计时器。
Note: The symbol "C" indicates an event in a state that results in the state remaining the same.
注：符号“C”表示处于导致状态保持不变的状态的事件。
|
v
+----------+
| waiting |
+----------+
|
| seq_num = 1, more = 1,
| nslices = x, starved = t
M bit v
+----------+ is 0 +-------------+
| finished |<-------| received |<------\
+----------+ | |<----\ |
+-------------+ | |
req_num = requested | | |
packet | M bit is 1 | |
V | |
+----------+ | |
seq_num++, C| sending |------/ |
req_num=0 +----------+ |
| |
| | |
+-------------+ | | |
| discovering |<----/ | |
| |<----\ | |
+-------------+ | | |
| v v
+--------+ |
| idle |---------/
+--------+
|
v
+----------+
| waiting |
+----------+
|
| seq_num = 1, more = 1,
| nslices = x, starved = t
M bit v
+----------+ is 0 +-------------+
| finished |<-------| received |<------\
+----------+ | |<----\ |
+-------------+ | |
req_num = requested | | |
packet | M bit is 1 | |
V | |
+----------+ | |
seq_num++, C| sending |------/ |
req_num=0 +----------+ |
| |
| | |
+-------------+ | | |
| discovering |<----/ | |
| |<----\ | |
+-------------+ | | |
| v v
+--------+ |
| idle |---------/
+--------+
Figure 30: SLAPP Image Download Protocol State Machine at the AC
图30:AC上的SLAPP映像下载协议状态机
The following states are defined:
定义了以下状态：
Waiting: When the AC leaves the SLAPP state of "Secure", it enters the "Waiting" state of the Image Download protocol. seq_num is set to one (1), more is set to one (1), nslices is set to the number of slices in the particular image to download, and starved is set to the maximum amount of time the AC will devote to downloading a particular image.
等待：当AC离开SLAPP状态“安全”时，它进入图像下载协议的“等待”状态。seq_num设置为一（1），more设置为一（1），nslices设置为要下载的特定图像中的切片数，而饥饿设置为AC将用于下载特定图像的最大时间。
Received: The AC enters this state when it has received an Image Download Request. If the sequence number of the packet is zero (0), it sets seq_num to one (1) and transitions to Sending; else, if the M bit is set, it sets req_num to the sequence number of the request and transitions to Sending; else, (if the M bit is clear) it transitions to Finished.
已接收：AC在收到图像下载请求时进入此状态。如果数据包的序列号为零（0），则将seq_num设置为一（1），并转换为发送；否则，如果设置了M位，则将req_num设置为请求的序列号，并转换为发送；否则，（如果M位是清除的）它将转换为Finished。
Sending: The AC is sending a slice to the WTP. If req_num is equal to zero (0), it sends the slice indicated by seq_num and increments seq_num. If req_num is greater than zero (0), it sends the slice indicated by req_num and sets req_num to zero (0). The "More" bit in either case is set depending on the value of more. As long as no request packets are received Sending transitions to Sending. When seq_num equals nslices "More" is set to zero (0) and the state transitions to Idle. If the starved timer expires, the AC transitions to the SLAPP state of Discovering.
发送：AC正在向WTP发送一个切片。如果req_num等于零（0），则发送由seq_num指示的切片并递增seq_num。如果req_num大于零（0），则发送由req_num指示的切片并将req_num设置为零（0）。两种情况下的“更多”位均根据“更多”的值进行设置。只要没有收到请求数据包，发送转换为发送。当seq_num等于nslices时，“More”设置为零（0），状态转换为空闲。如果耗尽的计时器过期，AC将转换为发现的SLAPP状态。
Idle: The AC has sent all the slices in the image and is just waiting for requests. If the starved timer expires the AC transitions to the SLAPP state of Discovering.
空闲：AC已发送图像中的所有切片，正在等待请求。如果耗尽的计时器过期，AC将转换为SLAPP状态。
Finished: The Image Download protocol has terminated. The starved timer is canceled.
已完成：映像下载协议已终止。饥饿计时器被取消。
The WTP's state machine for the Image Download protocol is shown in Figure 31. The WTP maintains the following variables for its state machine:
图像下载协议的WTP状态机如图31所示。WTP为其状态机维护以下变量：
recv_num: The sequence number of the last received slice.
recv_num：最后接收的切片的序列号。
req: A bitmask whose length equals the number of slices in the image.
req：一种位掩码，其长度等于图像中的切片数。
retry: A timer.
重试：计时器。
giveup: A timer.
放弃：计时器。
final: The sequence number of the last slice.
final：最后一个切片的序列号。
Note: The symbol "C" indicates an event in a state that results in the state remaining the same.
注：符号“C”表示处于导致状态保持不变的状态的事件。
|
v
+----------+
| init | recv_num = 0,
+----------+ final = 0, req = 0,
| giveup = t
v
+----------+ +-----------+
| finished |<------- | sending |<-------\
+----------+ +-----------+ |
| | retry fires
v |
+--------------+ |
bit in req = C| receiving |------/
seq_num in packet +--------------+
is set |
| giveup fires
v
+-------------+
| discovering |
+-------------+
|
v
+----------+
| init | recv_num = 0,
+----------+ final = 0, req = 0,
| giveup = t
v
+----------+ +-----------+
| finished |<------- | sending |<-------\
+----------+ +-----------+ |
| | retry fires
v |
+--------------+ |
bit in req = C| receiving |------/
seq_num in packet +--------------+
is set |
| giveup fires
v
+-------------+
| discovering |
+-------------+
Figure 31: SLAPP Image Download Protocol State Machine at the WTP
图31:WTP上的SLAPP映像下载协议状态机
The following states are defined:
定义了以下状态：
Init:
初始化：
When the WTP leaves the SLAPP state of "Secure", it enters the "Init" state of the Image Download protocol. recv_num, final, and the req bitmask are set to zero (0), and the giveup timer is set to a suitably large number. The WTP transitions directly to Sending.
当WTP离开SLAPP状态“Secure”时，它进入映像下载协议的“Init”状态。recv_num、final和req位掩码设置为零（0），放弃计时器设置为适当大的数字。WTP直接转换为发送。
Sending:
发送：
If recv_num is zero (0) the WTP sends a request for a packet with sequence number of zero (0) and the "More" bit set to one (1). Otherwise, for every unset bit in req between one (1) and recv_num, a request packet is sent with the sequence number corresponding to the unset bit in req and the "More" bit set to more.
如果recv_num为零（0），则WTP发送对序列号为零（0）且“更多”位设置为一（1）的数据包的请求。否则，对于一（1）和recv_num之间的req中的每个未设置位，发送一个请求数据包，序列号对应于req中的未设置位，“更多”位设置为更多。
If there are no unset bits in req and final is non-zero, a request packet is sent for the sequence number represented by final with the "More" bit cleared, giveup is cleared and the state machine transitions to Finished. Otherwise, retry is set to a suitable value and the WTP transitions to Receiving.
如果req中没有未设置的位，且final为非零，则发送一个请求数据包，请求序列号由final表示，清除“更多”位，放弃被清除，状态机转换为完成。否则，将“重试”设置为合适的值，WTP将转换为“接收”。
Receiving:
接收：
In this state, the WTP receives Image Download packets. The bit in req corresponding to the sequence number in the received packet is set, indicating this packet has been received. If the sequence number of the received packet has already been received, the packet is silently dropped; otherwise, the data in the packet is stored as the indicated slice in a file that represents the downloaded image. If the received packet has the "More" bit cleared, final is set to the sequence number in that packet. When the retry timer fires, the WTP transitions to Sending. If the giveup timer fires, the WTP transitions to the SLAPP state of Discovering.
在此状态下，WTP接收图像下载包。设置req中与所接收数据包中的序列号相对应的位，表示该数据包已被接收。如果已经接收到所接收的分组的序列号，则该分组被静默地丢弃；否则，分组中的数据作为指示的片段存储在表示下载图像的文件中。如果接收到的数据包清除了“更多”位，则final设置为该数据包中的序列号。当重试计时器启动时，WTP将转换为发送。如果放弃计时器触发，WTP将转换为发现的SLAPP状态。
Finished:
完成：
The Image Download protocol has finished.
图像下载协议已完成。
This document describes a protocol, SLAPP, which uses a different protocol, DTLS, to provide for authentication, key exchange, and bulk data encryption of a Negotiated Control Protocol. Its security considerations are therefore those of DTLS.
本文档描述了一个协议SLAPP，它使用不同的协议DTLS来提供协商控制协议的身份验证、密钥交换和批量数据加密。因此，它的安全考虑是DTL的安全考虑。
The AC creates state upon receipt of an acceptable Discover Request. AC implementations of SLAPP SHOULD therefore take measures to protect themselves from denial-of-service attacks that attempt to exhaust resources on target machines. These measures could take the form of randomly dropping connections when the number of open connections reaches a certain threshold.
AC在收到可接受的发现请求时创建状态。因此，SLAPP的AC实现应该采取措施保护自己免受试图耗尽目标机器上资源的拒绝服务攻击。当打开的连接数达到某个阈值时，这些措施可以采取随机丢弃连接的形式。
The WTP exposes information about itself during the discovery phase. Some of this information could not be gleaned by other means.
WTP在发现阶段公开有关其自身的信息。其中一些信息无法通过其他方式收集。
The SLAPP protocol can be considered to be a technology-independent protocol that can be extended with technology-specific components to solve an interoperability problem where a central controller from one vendor is expected to control and manage network elements from a different vendor.
SLAPP协议可被视为独立于技术的协议，可通过特定于技术的组件进行扩展，以解决互操作性问题，其中来自一个供应商的中央控制器有望控制和管理来自不同供应商的网络元件。
While the description of the SLAPP protocol in this document assumes that it is meant to solve the multi-vendor interoperability problem, as defined in the CAPWAP problem statement [3], splitting the
虽然本文档中对SLAPP协议的描述假设其旨在解决CAPWAP问题声明[3]中定义的多供应商互操作性问题，但将
solution to two components where technology-dependent control protocols are negotiated using a technology-independent framework enables the use of SLAPP as the common framework for multiple underlying technologies that are vastly different from one another.
两个组件的解决方案，其中使用技术独立框架协商技术相关的控制协议，使得可以使用SLAPP作为多个基础技术的通用框架，这些基础技术彼此之间存在巨大差异。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[2] Yang，L.，Zerfos，P.，和E.Sadot，“无线接入点控制和供应的体系结构分类法（CAPWAP）”，RFC 4118，2005年6月。
[3] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[3] O'Hara，B.，Calhoun，P.，和J.Kempf，“无线接入点（CAPWAP）的配置和供应问题声明”，RFC 39902005年2月。
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[4] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[5] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[5] Braden，R.，Ed.“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[6] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[6] Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[7] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[8] Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", <http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>.
[8] Modadugu，N.和E.Rescorla，“数据报TLS的设计和实现”<http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>。
[9] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader Protocol", Work in Progress, August 2005.
[9] Krishna，P.和D.Husak，“简单轻量级RFID阅读器协议”，正在进行的工作，2005年8月。
Authors' Addresses
作者地址
Partha Narasimhan Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
帕塔·纳拉西姆汉阿鲁巴网络公司加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089
Phone: +1 408-480-4716
EMail: partha@arubanetworks.com
Phone: +1 408-480-4716
EMail: partha@arubanetworks.com
Dan Harkins Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
Dan Harkins Aruba Networks加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089
EMail: dharkins@arubanetworks.com
EMail: dharkins@arubanetworks.com
Subbu Ponnuswamy Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
Subbu Ponnuswamy Aruba Networks加利福尼亚州桑尼维尔市克罗斯曼大道1322号，邮编94089
Phone: +1 408-754-1213
EMail: subbu@arubanetworks.com
Phone: +1 408-754-1213
EMail: subbu@arubanetworks.com