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学习笔记——初识capwap(四)-LMLPHP

其余的CAPWAP控制协议报文必须被DTLS协议加密,因此包括一个CAPWAP DTLS Header。

capwap学习笔记——初识capwap(四)-LMLPHP

CAPWAP协议对数据报文的DTLS加密是可选的。

capwap学习笔记——初识capwap(四)-LMLPHP

CAPWAP头部格式:

capwap学习笔记——初识capwap(四)-LMLPHP

¢ 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的连接状态信息。

capwap学习笔记——初识capwap(四)-LMLPHPcapwap学习笔记——初识capwap(四)-LMLPHP

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下载过程:

capwap学习笔记——初识capwap(四)-LMLPHP

capwap学习笔记——初识capwap(四)-LMLPHP

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

05-08 08:11