CAPWAP协议的隧道建立与维护的实现方式
- CAPWAP（无线接入点控制和配置协议），用于无线终端接入点（AP）和无线网络控制器（AC）之间的通信交互，实现AC对其所关联的AP的集中管理和控制。
- 该协议包含的主要内容有：
- AP对AC的自动发现及AP&AC的状态机运行、维护。
- AC对AP进行管理、业务配置下发。
- STA数据封装CAPWAP隧道进行转发。
CAPWAP协议的隧道建立的协议对比
协议名称 | LWAPP | SLAPP | CTP | WiCoP |
|---|---|---|---|---|
标准 | RFC5412 | RFC5413 | draft-singh-capwap-ctp | RFC5414 |
协议全称 | Light Weight Access Point Protocol | Secure Light Access Point Protocol | CAPWAP Tunneling Protocol | Wireless LAN Control Protocol |
提出厂家 | Cisco - AirSpace | Aruba | Siemens - Chantry | Panasonic |
协议特点 | 全面的描述了AC发现、安全和系统管理方法，支持本地MAC和分离MAC机制。两者连接采用2层或3层连接，2层连接使用以太网帧传输，3层连接使用UDP传输LWAPP报文。 | 支持桥接和隧道两种本地MAC机制。支持直连、2层和3层三种连接方式。使用成熟的技术标准来建立通信隧道，数据信道使用GRE技术。 | 利用扩展的SNMP对WTP进行配置和管理。CTP的控制消息着重于STA连接状态、WTP配置和状态几方面。 | 定义了包括无线终端-AC性能协商功能在内的AC发现机制，定义了QoS参数。 |
加密情况 | 信令 – AES-CCM数据 – 没有加密 | 信令 – DTLS数据 – DTLS | 建立了AP与无线终端互相认证及一套基于AES-CCM的加密规则，但是并不完善。 | 协议建议使用IPsec和EAP安全标准，却并未详细说明实现方法。 |
CAPWAP起源
LWAPP具有完整的协议框架，定义了详细的报文结构及多方面的控制消息元素，但全新制定的安全机制还需实践验证，而SLAPP使用业界认可的DTLS技术是其亮点。相对前两者而言，CTP和WiCoP实现了集中式WLAN体系结构的基本要求，但考虑不够全面，特别是安全性方面有所欠缺。
CAPWAP工作组对以上四种通信协议进行评测后，最终采用LWAPP协议作为基础进行扩展，使用DTLS安全技术，加入其他三种协议的有用特性，制定了CAPWAP协议。
CAPWAP协议的隧道建立过程
CAPWAP协议的隧道建立分为8个过程，如下图：
DHCP下发过程
1、DHCP过程
- AP通常是零配置，当AP加电启动后将使用DHCP协议动态发现AC，并与发现的AC建立隧道。
- 首先是AP发送Discovery广播报文，请求DHCP Server响应。
- DHCP Server侦听到Discovery报文后，会选择一个空闲的IP地址，并响应一个DHCP Offer报文，该报文中会包含租约期限信息及其他的DHCP option信息。AC与AP在同一个网段时，AP可以通过广播方式发现同一网段中的AC，不需要配置option 43字段。当AP和AC不在同一网段，需要配置DHCP代理，还需要在DHCP Server上配置DHCP option 43包含AC的IP地址。如果DHCP Server不支持option 43，则组建WLAN时需要做特殊处理。
- 当AP收到多台DHCP Server的Offer时，AP只会挑选其中一个Offer(通常是最先抵达的那个)，然后向网络中发送一个DHCP Request广播报文，告诉所有的DHCP Server它采用了哪个Offer。同时，AP也会向网络发送一个ARP报文，查询网络上有没有其他设备使用该IP。
- 当DHCP Server接收到AP的Request报文之后，会向AP发送一个DHCP Ack响应，该报文中携带的信息包括了AP的IP地址、租约期限、网关信息及DNS Server IP等。
2、Discovery过程
- AP获得 AC的IP地址或者域名后，将使用AC发现机制来获知哪些AC是可用的，并与最佳AC来建立CAPWAP协议隧道。
- AP启动CAPWAP协议的发现机制，以单播或广播的形式发送Discovery Request试图关联AC。
- AC收到AP的Discovery Request以后，会发送一个单播Discover Response 给AP，AP可以通过Discover Response中所带的AC优先级或者AC上当前AP的个数等，确定与哪个AC建立会话。
3、DTLS握手
- DTLS握手过程是可选的，如果AC上配置了CAPWAP协议采取DTLS加密报文，则启动该过程，大致过程如图9-10所示。该过程包含了多个细小步骤，通过这些步骤AP和AC将协商采用DTLS加密传输UDP报文的加密方式、密钥等参数。
4、Join过程
在完成DTLS握手后，AC与AP开始建立控制通道，在这过程中AC回应的Join Response报文中会携带用户配置的版本号、握手报文间隔、超时时间、控制报文优先级等信息。AC也会检查AP的Image（即VRP）当前版本，如果AP的版本无法与AC要求的相匹配，AP和AC会进入Image Data状态做固件升级，以此来更新AP的版本。如果AP的版本符合要求，则进入Configure过程。
5、Image Data过程（可选）
AP根据协商参数判断当前版本是否是最新版本，如果不是最新版本，则AP将在CAPWAP协议隧道上开始更新软件版本，如图9-12所示。AP在软件版本更新完成后重新启动，重复进行AC发现、建立CAPWAP协议隧道、加入AC的过程。
6、Configure过程
Configure过程是为了做AP的现有配置和AC设定配置的匹配检查。如图9-13所示，AP发送Configuration Status Request到AC，该信息中包含了现有AP的配置，当AP的当前配置与AC的要求不符合时，AC会通过Configuration Status Response通知AP。
7、Data Check过程
当完成Configure后，AP发送Change State Event Request信息，其中包含了radio、result、code等信息，当AC接收到Change State Event Request后，开始回应Change State Event Response。至此已经完成CAPWAP协议隧道建立的过程，开始进入隧道的维护阶段。
8、隧道的维护
隧道包含数据流隧道和管理流隧道。数据流隧道的维护如下图所示。AP发送Keepalive到AC，AC收到Keepalive后表示数据隧道建立，AC回应Keepalive，AP进入“normal”状态，开始正常工作。
管理流隧道的维护如下图所示。AP进入Run状态后，同时发送Echo Request报文给AC，宣布建立好CAPWAP协议管理隧道并启动Echo发送定时器和隧道检测超时定时器以检测管理隧道是否异常。当AC收到Echo Request报文后，同样进入Run状态，并回应Echo Response报文给AP，启动隧道超时定时器。当AP收到Echo Response报文后，会重设检验隧道超时的定时器。
