capwap协议特性.docx
《capwap协议特性.docx》由会员分享，可在线阅读，更多相关《capwap协议特性.docx（34页珍藏版）》请在冰豆网上搜索。
capwap协议特性
Capwap协议特性草案10学习理解
一．名词解释
1.AccessController（AC）:
为WTP提供在数据平面、控制平面和管理平面上接入集中式结构网络的实体
2.CAPWAPControlChannel:
一个双向的数据流。
由AC的IP、WTP的IP、AC的控制埠、WTP的控制端口以及传输层协议（UDP或者UDP-Lite）这个五元组决定，负责收发CAPWAP控制报文。
3.CAPWAPDataChannel:
一个双向的数据流。
由AC的IP、WTP的IP、AC的控制埠、WTP的控制端口以及传输层协议（UDP或者UDP-Lite）这个五元组决定，负责收发CAPWAP数据报文。
4.Station（STA）:
包含连接到无线介质接口的设备
5.WirelessTerminationPoint（WTP）:
包含射频天线和无线物理介质，可以发送和接受无线接入网的基站流量的设备。
二．协议综述
CAPWAP协议主要是通过特定的传输机制对AC和WTP之间的通讯进行定义。
CAPWAP协议目前仍然是一个草案，没有确定的规则。
从概念上说，CAPWAP其实是一类管理功能的综合体现，这些功能包括：
1.必须实现的：
Ø逻辑组管理：
将WTP按照BSSID分成组进行管理和控制
Ø流量分类：
将控制信息和数据报文分开处理
Ø无线终端透明：
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--）
ChangeCipherSpec,
Finished*
<------------------------------------
（--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
其帧格式：
IPHeader
UDPHeader
CAPWAPHdr
ControlHdr
Messageelement
●第二种是在DTLS建立后，有了DTLS协议保护的信息包帧格式：
IPHdr
UDPHdr
CAPWAPDTLSHdr
DTLSHdr
CAPWAPHeader
ControlHeader
MessageElement
DTLSTrLr
|-------------------------------authenticated-----------------------------|
|---------------------------encryted------------------------------------|
在数据信息中也分为两种帧格式，根据AC的策略选用不同的格式
●CAPWAP纯文本数据包：
IPHeader
UDPHeader
CAPWAPHeader
Wirelesspayload
●基于DTLS安全CAPWAP数据报;
IPHdr
UDPHdr
CAPWAPDTLSHdr
DTLSHdr
CAPWAPHeader
WirelessPayload
DTLSTrLr
|-------------------------------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
<--------------------------------------------------------->
StationConfigurationRequest
[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
升级会员 