capwap协议特性文档格式.docx

capwap协议特性文档格式.docx

《capwap协议特性文档格式.docx》由会员分享，可在线阅读，更多相关《capwap协议特性文档格式.docx（34页珍藏版）》请在冰豆网上搜索。

无线终端透明：

WTP不需要知道CAPWAP协议的存在，也不需要认识

配置一致性：

CAPWAP应该能交换WTP和AC之间的常规信息，比如WTP的运行状态，内存使用率等，这样AC可以很好的了解诸多WTP当前情况，进行管理

固件触发：

AC必须支持触发和更新WTP的固件

监控和交换系统范围内的资源状态：

CAPWAP应该允许交换WLAN的信息，比如统计数据、拥塞状况等。

资源控制：

CAPWAP应该可以将802.11eQoS优先级映像到等价的在交换上应用的QoS优先级

协议安全性：

CAPWAP必须支持WTP和AC之间的相互认证，比如保证信息交互是完整和保密的，不可阻止使用非对称的认证。

系统范围的安全性：

CAPWAP不允许WLAN之外的实体进入系统

802.11i支持

互操作：

CAPWAP必须支持对Split-Mac和Local-Mac两种模式的WTP进行协商

协定特性：

所有供货商实现CAPWAP的时候，都必须按照特性来，以方便不同厂商之间产品的相互操作

供货商独立性：

对WTP硬件修改，应该不会对AC端使用产生影响

供货商灵活性：

CAPWAP不应该限制WTP供货商使用Split-Mac或者Local-Mac，而是应该都支持

NAT穿越

CAPWAP的控制报文，也许还包括数据报文，都是用数据传输层安全协议DTLS保障的。

CAPWAP协议的传输层包含了两种载荷：

控制信息和数据信息。

数据信息封装了要转发的无线帧。

控制信息则是在一个WTP和AC之间的管理信息的交换。

数据信息和控制信息，使用不同的UDP埠，可以分片。

CAPWAP协议开始会有个发现的过程。

WTP发送一个DiscoveryRequest信息，AC收到之后就会响应一个DiscoveryResponse信息。

收到DR信息之后，WTP会试图和AC建立一个DTLS的会话session。

WTP和AC建立完DTLSsession之后，双方的版本信息统一，并开始交换配置信息。

WTP会收到实现的设置，完毕就可以工作了。

WTP开始工作之后呢，AC和WTP之间就可以依靠CAPWAP协议，把无线帧进行封装。

CAPWAP提供一些命令，可以让AC传给WTP，以便于对连接到WTP的Station进行管理。

也许会包括一些WTP本地数据结构的创建信息，或者WTP和Station之间通讯的一个统计。

同时，AC也可以得到WTP收集到的一些统计信息。

AC和WTP之间，会有一个Keeplive机制，一旦WTP失去了和AC的联系，它会试图寻找一个新的AC。

2.1CAPWAPSession建立过程

========================

WTPAC

[-----------Beginoptionaldiscovery------------]

DiscoverRequest

------------------------------------>

DiscoverResponse

<

------------------------------------

[-----------Endoptionaldiscovery------------]

（--BeginDTLShandshake--）

ClientHello

HelloVerifyRequest（withcookie）

ClientHello（withcookie）

ServerHello,

Certificate,

ServerHelloDone*

（--WTPcalloutforACauthorization--）

Certificate（optional）,

ClientKeyExchange,

CertificateVerify（optional）,

ChangeCipherSpec,

Finished*

------------------------------------

（--ACcalloutforWTPauthorization--）

（--DTLSsessionisestablishednow--）

JoinRequest

JoinResponse

[--JoinStateComplete--]

（--Assumeimageisuptodate--）

ConfigurationStatusRequest

ConfigurationStatusResponse

[--ConfigureStateComplete--]

ChangeStateEventRequest

ChangeStateEventResponse

[--DataCheckStateComplete--]

（--EnterRUNstate--）

EchoRequest

EchoResponse

:

EventRequest

EventResponse

状态机变迁（借用别人的精美图片了）

附带其精妙的解说：

●在一个WTP初始化完成后，它就会从Idle状态Discovery状态：

这是WTP就会发送一个DiscoveryRequest信息来发现AC，这个消息的帧格式为

IPHeader

UDPHeader

CAPWAPHdr

ControlHdr

Messageelement

在这个CAPWAP控制信息包里，它缺少相应的DTLS保护，无法确保信息包的认证和加密，所以这样的CAPWAP控制信息包的组帧方式只有用在前期的Discovery状态的请求和回应里

但是我们如何得知AC的IP地址呢？

CAPWAP为我们提供了四种机制：

1、在WTP的内存中存储了一个ACIP的静态分配

2、通过设置DHCP服务器作一个AC的DHCP，通过它向WTP发送AC的IP列表

3、为AC做一个DNS的注册，让WTP通过域名解析获得AC的地址

4、在发现一个AC的情况下,AC在回复响应时回附带一个ACIPList，向WTP提供更多的可用AC的IP信息

WTP初始化完成后，进入Discovery状态，同时开启DiscoveryInterval定时器，设DiscoveryCount计数器为0，WTP在等待一个小于MaxDiscoveryInterval的随机时间后发送了DiscoveryRequest信息，其每发送一个这样信息的都要等待一个小于MaxDiscoveryInterval的随机时间。

如果在发送了最大数量的DiscoveryRequest信息后仍没有收到Response信息，那么WTP就要进入Sulking状态，在该状态它要等待一个SilentInterval的时间间隔后才能重新发送Request信息，而且在此期间收到的信息全部忽略

当AC收到一个DiscoveryRequest信息时，它会向该WTP发送一个DiscoveryResponse信息，WTP收到该响应信息后必须在等待一个不小于DiscoveryInterval的时间来接收其他的Response信息，当DiscoveryInterval定时器到期后就会进入DTLS-Init并选择它收到Response信息的AC的其中一个作为主AC，并发送DTLS握手信息

●接着WTP就从Discovery状态DTLSsetup来创建一个安全的DTLSsession，WTP这时会调用DTLSStart命令开始与选择的AC创建DTLS连接。

与此同时AC则会调用DTLSListen命令，该命令来通知DTLS协议栈监听一个接入的session

如果DTLS建立失败WTP就会收到一个DTLSEstablishFail的通知，该错误通知会中止DTLS的建立，这时WTP就会从DTLSsetupIdle状态。

●如果DTLSsession建立成功，那么就会从DTLSsetupAuthorize状态，这个状态是在DTLS连接建立下，DTLS协议栈需要后续session建立的授权的时候发生。

在这个阶段，WTP和AC都会收到DTLSPeerAuthorize通知，这是他们会执行一个对对方信任的授权检查。

●如果WTP和AC都放弃检查或者都通过对方的授权检查是他们会调用DTLSAccept命令向DTLS发送一个session可以建立的通知，这时AuthorzeDTLSConnect状态。

但是如果在WTP或AC中有任何一方无法对对方的信任状做授权，都会调用DTLSAbortSession命令通知DTLS协议栈终止session，这时AuthorizeDTLSTeardown状态

●当DTLSSession建立成功后，WTP和AC就会收到一个DTLSEstablished通知表明DTLSsession建立成功，同时它们会将FailedDTLSSessionCount计数器置0，同时AC会开启WaitJoin定时器，这时DTLSConnectJoin状态，在Join状态，WTP发送JoinRequest信息来请求AC提供服务，当AC收到JoinRequest后就会对JoinRequest里的信息进行处理，如果信息无误，他就会清除WaitJion定时器并发送给WTP一个JoinResponse的成功说明，并进入Configure状态，如果在WaitJoin期满后AC就会中断握手，调用DTLSAbort命令来终止session

●当WTP与AC的session建立成功后就要双方就要对配置信息进行交互，这就是Joinconfigure状态。

在configure状态时，WTP会将自己的配置状态信息提交给AC，信息中带有WTP现有功能的描述，当AC收到此信息后就会给WTP发送配置状态响应信息，AC用这个信息来覆盖掉WTP请求配置，对WTP做配置管理。

接着WTP收到该响应信息后就会做配置的相应修改，并通过ChangStateEventRequest向AC报告对WTPRadio的操作状态的更新并确认AC提供的配置已经应用成功。

AC在收到此请求后回复一个ChangStateEventResponse，当这一切成功后，这时DataCheckRun状态，WTP和AC的交互开始真正运作起来

在CAPWAP中有两种信息数据：

控制信息和数据信息

在信息数据里又分两种：

●第一种控制信息包由于是在DTLS建立前使用的，没有任何安全保护机制，只用来做DiscoveryRequest/Response

其帧格式：

●第二种是在DTLS建立后，有了DTLS协议保护的信息包帧格式：

IPHdr

UDPHdr

CAPWAPDTLSHdr

DTLSHdr

CAPWAPHeader

ControlHeader

MessageElement

DTLSTrLr

|-------------------------------authenticated-----------------------------|

|---------------------------encryted------------------------------------|

在数据信息中也分为两种帧格式，根据AC的策略选用不同的格式

●CAPWAP纯文本数据包：

Wirelesspayload

●基于DTLS安全CAPWAP数据报;

WirelessPayload

|-------------------------------authenticated----------------------|

|-----------------------encryted---------------------------------|

在数据报中，我们要考虑CAPWAP协议和IEEE802.11的绑定相关问题：

●分离MAC问题：

就是要将802.11的MAC功能做分割，实时功能由WTP处理，而所有MAC管理功能的数据交由AC处理：

FunctionLocation

DistributionServiceAC

IntegrationServiceAC

BeaconGenerationWTP

ProbeResponseGenerationWTP

PowerMgmt/PacketBufferingWTP

Fragmentation/DefragmentationWTP/AC

Assoc/Disassoc/ReassocAC

IEEE802.11QOS

ClassifyingAC

SchedulingWTP/AC

QueuingWTP

IEEE802.11RSN

IEEE802.1X/EAPAC

RSNAKeyManagementAC

IEEE802.11Encryption/DecryptionWTP/AC

下图可以对整个的MAC功能分配做一个说明：

ClientWTPAC

Beacon

-----------------------------

ProbeRequest

----------------------------（-）------------------------->

ProbeResponse

802.11AUTH/Association

--------------------------------------------------------->

StationConfigurationRequest

[AddStation（StationMessage

Elements）]

-------------------------->

802.1XAuthentication&

802.11KeyExchange

[AddStation（AES-CCMP,

PTK=x）]

802.11ActionFrames

802.11DATA

（1）

---------------------------（-）------------------------->

以上说明其实只是状态机的一部分，所有的状态迁移加起来内容非常复杂，有兴趣的可以自己去看这个draft的2.3节。

2.2CAPWAP传输过程概述

CAPWAP的传输，是建立在AC和WTP的一个UDPServer/Client架构上的，可以利用UDP或者UDPLite完成。

后者是个新鲜东西，报文类型是136，在rfc3828中得到定义，可以视为一个轻量级的UDP（LightWeight）。

UDPLite的产生是因为一些应用程序对报文能否到达最为关心，至于报文是否有错并不是最重要的实情。

传统IP报文对出错的检测比较严格，一个报文任何地方出错都会影响校验和，但是UDPLite中定义了一个Checksumcoverage域，用于限定需要做校验和处理的敏感区域，非敏感区域出错，是无所谓的。

实际上，在这个draft中规定，UDPLite在Ipv6的环境中是CAPWAP默认的数据信道方式，如果是Ipv4到Ipv6的网关存在的话，则需要使用UDP了。

AC发现阶段允许WTP知道AC都藏在哪儿，哪些可以用，然后选择一个最好的建立一个CAPWAP连接。

如果WTP上预先配置了AC的信息，那么它可以不用经过这个阶段了。

这个主要是用来动态的发现AC的。

WTP试图找寻AC的时候，就会发送一个DiscoveryRequestMessage报文，这个报文可以是广播（255.255.255.255）或者是多播，也可以是某个AC的单播地址。

如果是Ipv6网络，则使用一个全体AC多播地址。

AC则回应一个单播报文，无视DiscoveryRequest的报文形式。

如果WTP发送的是单播报文到AC，那么有几种可能。

一个是WTP上配置了AC的信息，第二个是利用DHCP的机制发现AC，第三个就是通过DNS解析了。

当然，还有一种情况是某个AC很慷慨的告诉WTP一些候选的AC的Ipv4和Ipv6的地址列表，然后WTP就可以得到更多的选择了。

但是WTP只能按照AC所给的AC列表顺序选择AC，当然WTP会有一定的选择标准，这会用到很多其他的信息。

WTP发现它心仪的AC之后，就要在建立CAPWAP会话之前，进行一个PathMTU发现的行动。

这个是为了DTLS的建立使用的，而其他非DTLS的信息将会根据实际需要进行分片。

WTP会周期性的重新估计一下MTU的值

2.3CAPWAP报文格式

CAPWAP协议报文，包括一个或者多个CAPWAP传输层报文头。

它可以是包含信号的控制报文，也可以是包含用户负荷的数据报文。

CAPWAP的实现，必须能够接收长度为4096的重组报文。

CAPWAP的控制帧包含两个绝对不会被DTLS加密的信息：

发现请求报文和发现回应报文：

CAPWAPControlPacket（DiscoveryRequest/Response）:

+-------------------------------------------+

|IP|UDP|CAPWAP|Control|Message|

|Hdr|Hdr|Header|Header|Element（s）|

其他的控制信息都必须在DTLS保护之下传送的，这样的报文都会包含一个DTLS头部

CAPWAPControlPacket（DTLSSecurityRequired）:

+------------------------------------------------------------------+

|IP|UDP|CAPWAP|DTLS|CAPWAP|Control|Message|DTLS|

|Hdr|Hdr|DTLSHdr|Hdr|Header|Header|Element（s）|Trlr|+------------------------------------------------------------------+

\----------authenticated-----------/

\-------------encrypted------------/

CAPWAP数据报文的格式如下，和控制报文很像：

CAPWAPPlainTextDataPacket:

+-------------------------------+

|IP|UDP|CAPWAP|Wireless|

|Hdr|Hdr|Header|Payload|

DTLSSecuredCAPWAPDataPacket:

+--------------------------------------------------------+

|IP