2.5.7 CAPWAP传输机制
WTP和AC之间使用标准的UDP客户端/服务器模式来建立通讯。
CAPWAP协议支持UDP和UDP-Lite [RFC3828]。
¢ 在IPv4上，CAPWAP控制和数据通道使用UDP。此时CAPWAP报文中的UDP校验和必须设置为0。AC上的CAPWAP控制报文端口为UDP众所周知端口5246，数据报文端口为UDP众所周知端口5247 ，WTP可以随意选择CAPWAP控制和数据端口。
¢ 在IPv6上，CAPWAP控制通道一般使用UDP，而数据通道可以使用UDP或者UDP-Lite。UDP-Lite为默认的数据通道传输协议。当使用UDP-Lite协议的时候，校验和必须为8. UDP-Lite使用的端口与UDP一致。
2.5.8 分片、重组、MTU发现
CAPWAP协议在应用层上提供IP报文的分配和重组服务，由于使用隧道机制，报文分片中间的传输媒介来说是透明的。因此可以在任何网络架构（防火墙，NAT等）上使用CAPWAP协议。
CAPWAP实现的分片机制也有局限和不足，协议RFC4963中详细描述。
CAPWAP执行MTU发现来避免分片。
一旦WTP发现AC，且想要与这个AC建立一个CAPWAP会话，它必须执行一个Path MTU (PMTU)发现。IPv4的PMTU发现过程在RFC1191中详细描述。IPv6使用RFC4821。
2.5.9 报文格式
CAPWAP协议可靠机制要求消息必须成对，由请求和响应组成。所有的请求消息的消息类型值都为奇数，所有的响应消息类型值都为偶数。
如果WTP或者AC接收到了一个不认识的消息，消息类型是奇数，那么会将消息类型值加一，然后响应给发送者，并且在响应中带有“不认识的消息类型”元素。如果不认识的消息类型为偶数，那么这个消息将会被忽略。
2.5.9.1 UDP-Lite协议的简单介绍
UDP-Lite协议更加适应于网络的差错率比较大，但是应用对轻微差错不敏感的情况，例如实时视频的播放等。
那么它与传统的UDP协议有什么不同呢？
传统的UDP协议是对其载荷（Payload）进行完整的校验的，如果其中的一些位（哪怕只有一位）发生了变化，那么整个数据包都有可能被丢弃，在某些情况下，丢掉这个包的代价是非常大的，尤其当包比较大的时候。
在UDP-Lite协议中，一个数据包到底需不需要对其载荷进行校验，或者是校验多少位都是由用户控制的，并且UDP-Lite协议就是用UDP协议的Length字段来表示其Checksum Coverage的，所以当UDP-Lite协议的Checksum Coverage字段等于整个UDP数据包（包括UDP头和载荷）的长度时，UDP-Lite产生的包也将和传统的UDP包一模一样。事实上，Linux对UDP-Lite协议的支持也是通过在原来的UDP协议的基础上添加了一个setsockopt选项来实现控制发送和接受的checksum coverage的。
2.5.9.2 CAPWAP报文的简单介绍
CAPWAP控制协议包括两个永远不会被DTLS保护的消息：Discovery Request和Discovery Response。
报文格式如下：
其余的CAPWAP控制协议报文必须被DTLS协议加密，因此包括一个CAPWAP DTLS Header。
CAPWAP协议对数据报文的DTLS加密是可选的。
CAPWAP头部格式：
¢ UDP头：所有的CAPWAP报文都被封装在UDP或者UDP-Lite（ipv6）中。
¢ CAPWAP DTLS头：所有的被DTLS加密的CAPWAP报文都有该头部前缀。
¢ DTLS头：DTLS头部为CAPWAP的载荷提供认证和加密服务。DTLS在RFC4347中定义。
¢ CAPWAP头：所有的CAPWAP协议报文都用同一个头部，该头部位于CAPWAP预判码或者DTLS头之后。
¢ 无线载荷：包含无线载荷的CAPWAP协议报文称为CAPWAP数据报文。CAPWAP协议并没有对无线载荷的格式做强制要求，而是由无线协议标准决定。
¢ 控制头：CAPWAP协议包含一个信号元件，称为CAPWAP控制协议。所有的CAPWAP控制报文都包含一个控制头，CAPWAP数据报文则不包含该头部。
¢ 消息元素：CAPWAP控制报文包含一个或者多个消息元素，这些跟在元素在控制头之后。这些消息元素以TLV格式出现（类型/长度/值）
2.5.9.2.1 预判码
2 种 CAPWAP 首部的前 8 位为预判码，用于快速判断此报文是否经过 DTLS 加密。前 4 位指明 CAPWAP 版本，目前的版本号为 0；后 4 位值为 1 时是 CAPWAP DTLS 首部，值为 0 时是 CAPWAP 首部。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version| Type |
2.5.9.2.2 CAPWAP DTLS 首部
标识此报文经过 DTLS 加密。长度为 32 位，包括 8 位预判码和 24 位预留码。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.5.9.2.3 CAPWAP 首部
CAPWAP 协议的所有报文都包含 CAPWAP 首部，在控制信道收到则是控制报文，在数据信道收到则是数据报文，
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Frag Offset |Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Radio MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
报文各部分组成如下：
(1)CAPWAP Preamble：8 位预判码。
(2)HLEN：5 位首部长度，指明 CAPWAP 首部的长度。
(3)RID：5 位射频标识符，指明此报文的来源射频。
(4)WBID：5 位无线帧标识符， 指明无线帧类型， 有 IEEE802.11, IEEE802.16 和 EPCGlobal 3 种。
(5)T：1 位数据帧标识符，值为 1 时数据帧是由 WBID指明的类型，值为 0 时是 IEEE802.3 数据帧。
(6)F：1 位分组标志，值为 1 时此报文是一个 CAPWAP报文分组，需要和其他分组重组成完成的报文。
(7)L：1 位分组结束标志，值为 1 时此报文是最后一个分组。
(8)W：1 位选项标志，值为 1 时存在 Wireless Specific Information 选项。
(9)M：1 位选项标志，值为 1 时存在 Radio MAC Address选项。
(10)K：1 位存活标志，指明此报文用于保持连接存活，不能携带用户数据。
(11)Flags：3 位预留标志。
(12)Fragment ID：16 位分组标识符，识别不同的报文分组，ID 相同的分组属于同一个 CAPWAP 报文。
(13)Fragment Offset：13 位分组位移，各分组在该CAPWAP 报文中的位置。
(14)Reserved：3 位预留码。
(15)Radio MAC Address：32 位射频 MAC 地址，不足32 位以全 0 填充。指明报文来源射频的 MAC 地址。
(16)Wireless Specific Information：32 位特殊无线信息，不足 32 位以全 0 填充。包含特殊信息，如与 IEEE 802.11, IEEE802.16 和 EPCGlobal 的关联等。
(17)Payload：数据报文是用户数据，控制报文则是控制消息，详细的控制消息定义参见文献[1]。
2.5.9.3CAPWAP数据报文
CAPWAP数据报文有两种类型：CAPWAP Data channel Keep-Alive 报文和Data Payload报文。CAPWAP Data hannel Keep-Alive报文用于同步控制和数据通道，维持数据通道的连接。Data Payload报文用于在AC和WTP之间传输用户数据。
2.5.9.3.1 CAPWAP Data Channel Keep-Alive
该报文的目的在于保持通道的可用性。当DataChannelKeepAlive定时器到期，WTP发送该报文，同时设置DataChannelDeadInterval定时器。
在报文中，除了HELN字段和K标志位，其余字段和标志位均被置为0。当收到KEEPALIVE报文，AC将回应一个KEEPALIVE报文给WTP。
WTP在收到AC回应的KEEPALIVE报文后，取消DataChannelDeadInterval定时器并且重设DataChannelKeepAlive定时器。然后WTP将KEEPALIVE报文当做控制消息进行重发。如果在DataChannelDeadInterval定时器到期时仍然没有收到AC的回应报文，WTP将删除DTLS的控制SESSION，如果存在数据SESSION也同时删除。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Element Length | Message Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
报文被封装在CAPWAP报文的payload字段中。
Message Element Length: 16bit的长度字段，最大为65535。
Message Element[0..N]: 携带的KEPPALIVE报文数据，是必须携带的。
2.5.9.3.2 Data Payload
CAPWAP Data Payload报文封装了需要转发的用户数据，里面可能是802.3帧也有可能是无线数据帧，参见3.2章节。
2.5.9.3.3 DTLS数据通道的建立
如果AC和WTP被配置为DTLS隧道传输模式，那么就必须初始化DTLS SESSION。为了避免重新鉴定、认证AC和WTP，DTLS数据通道应该利用TLS SESSION的特征。
AC DTLS实现不应该在没有控制通道的情况下初始化数据通道SESSION。
2.5.9.4 CAPWAP控制报文
CAPWAP控制报文分为以下几种类型：
Discovery：发现网络中的AC，AC位置和能力
Join：WTP用于向AC请求服务，AC用于响应WTP
Control Channel Management：维持控制通道
WTP Configuration Management：AC给WTP发送配置文件。
Station Session Management：AC发送station策略给WTP
Device Management Operations:请求和发送firmware给WTP
Binding-Specific CAPWAP Management Messages: AC和WTP用于交换协议指定的CAPWAP管理信息。可能交换一个station的连接状态信息。
2.5.9.3.1 CAPWAP Discovery Operations
¢ Discovery Request Message
WTP用Discovery Request来自动发现网络中可用的AC，提供自己的基本性能给AC。
¢ Discovery Response Message
AC使用Discovery Response，将自己支持的服务告诉给请求服务的WTP。
¢ Primary Discovery Request Message
WTP发送Primary Discovery Request用于：判断它首选（或者配置的）的AC是否可用或者执行一个Path MTU Discovery
¢ Primary Discovery Response
AC使用Primary Discovery Response告诉WTP自己当前可用，与支持服务。
当WTP被配置了一个首选的AC，但是现在却连接在另外一个AC上，此时会发送Primary Discovery Request。因为WTP只有一个CAPWAP状态机，WTP在run状态发送Primary Discovery Request，AC不传输这个消息
2.5.9.3.2 CAPWAP Join Operations
¢ Join Request
在与AC建立DTLS连接之后，WTP使用Join Request来向一个AC请求服务
¢ Join Response
AC使用Join Response告知WTP是否会向其提供服务
2.5.9.3.3 Control Channel Management
¢ Echo Request
¢ Echo Response
Echo Request和Echo Response用于在控制报文没有发送的时候，来显式的维持控制通道的连接
2.5.9.3.4 WTP Configuration Management
¢ Configuration Status Request
WTP用于发送自己当前的配置给AC
¢ Configuration Status Response
AC提供自己的配置数据给WTP，覆盖WTP所请求的配置
¢ Configuration Update Request
run状态的时候，AC发送给WTP用于修改WTP上的配置。
¢ Configuration Update Response
响应Configuration Update Request
¢ Change State Event Request
1：当WTP收到来自AC的Configuration Status Response，WTP使用Change State Event Request来提供WTP radio的当前状态，确认AC提供的配置已经成功应用
2：在run状态下，WTP发送Change State Event Request来告诉AC，WTP radio发生了意料之外的改变。
¢ Change State Event Response：
响应Change State Event Request
¢ Clear Configuration Request：
AC用于请求WTP将自己的配置恢复至出厂默认值
¢ Clear Configuration Response
WTP恢复出厂默认值后，发送给AC的确认。
CAPWAP协议提供弹性的WTP配置管理机制,有两种方法：
1：WTP没有任何配置，接受AC提供的任何配置
2：WTP保存AC提供的静态内存中的不是默认值的配置数据，然后重启初始化配置。
2.5.9.3.5 Device Management Operations（可选）
¢ Image Data Request
在WTP和AC之间交换，用于WTP下载一个新的firmware
¢ Image Data Response
响应Image Data Response
¢ Reset Request
要求WTP进行重启。
¢ Reset Response
响应Reset Request
¢ WTP Event Request
WTP用来发送信息给AC。WTP Event Request可能是阶段性发送，或者是作为一个WTP同步事件的响应。
¢ WTP Event Response
响应WTP Event Request
¢ Data Transfer Request
将WTP上的调试信息发送给AC
¢ Data Transfer Response
响应 Data Transfer Request
WTP Event Request是WTP发送一些定义好的状态信息，如Decryption Error Report，Duplicate IPv4 Address等等，也能用于发送Vendor Specific Payload
Data Transfer Request可以由AC发送，也可以由WTP发送。
2.5.9.3.6 CAPWAP定义的firmware下载过程:
firmware的下载可以发生在image data状态或者run状态。CAPWAP协议并没有提供让AC来识别是否WTP提供的firmware信息是否正确，或者WTP是否正确存储了firmware。
2.5.9.3.7 Station Session Management
¢ Station Configuration Request
AC用于创建，修改，删除WTP上的staion 会话状态
¢ Station Configuration Response
响应Station Configuration Request