capwap学习笔记——初识capwap（四）

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报文数据，SEESION ID是必须携带的。

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