CAPWAP协议(RFC5415)培训初稿.docx

CAPWAP协议(RFC5415)培训初稿 1概述21.1标准21.2CAPWAP协议系统框架31.2.1Split MAC 模式31.2.2Local MAC 模式31.2.3三种Tunnel模式41.3CAPWAP协议概述41.3.1CAPWAP工作原理51.3.2AP发现AC的过程61.3.3DTLS 握手（DTLS: Datagram Transport Layer Security RFC4347）71.3.4CAPWAP Session建立过程71.3.4.1Capwap状态机各阶段WTP状态介绍81.3.4.2CAPWAP JOIN过程91.3.4.3CAPWAP IMAGE过程111.3.4.4CAPWAP Configuration过程111.3.4.5RUN 过程122CAPWAP协议分析142.1UDP 传输142.2CAPWAP报文格式142.2.1CAPWAP Header分析152.2.1.1CAPWAP数据消息分析172.2.1.2CAPWAP控制消息分析182.2.1.3控制消息格式182.2.2CAPWAP消息元素分析203CAPWAP状态机213.13.1 CAPWAP状态机详解233.1.1Start to Idle233.1.2Idle to Discovery233.1.3Discovery to Discovery233.1.4Discovery to Idle233.1.5Discovery to Sulking243.1.6Sulking to Idle243.1.7Sulking to Sulking243.1.8Idle to DTLS Setup253.1.9Discovery to DTLS Setup253.1.10DTLS Setup to Idle253.1.11DTLS Setup to Sulking263.1.12DTLS Setup to DTLS Setup263.1.13DTLS Setup to Authorize263.1.14Authorize to DTLS Setup273.1.15Authorize to DTLS Connect273.1.16DTLS Connect to DTLS Teardown273.1.17DTLS Connect to Join283.1.18Join to DTLS Teardown283.1.19Join to Image Data293.1.20Join to Configure293.1.21Configure to Reset303.1.22Authorize to DTLS Teardown303.1.23Configure to DTLS Teardown313.1.24Image Data to Image Data313.1.25Image Data to Reset323.1.26Image Data to DTLS Teardown323.1.27Configure to Data Check333.1.28Data Check to DTLS Teardown333.1.29Data Check to Run343.1.30Run to DTLS Teardown343.1.31Run to Run353.1.32Run to Reset373.1.33Reset to DTLS Teardown373.1.34DTLS Teardown to Idle373.1.35DTLS Teardown to Sulking383.1.36DTLS Teardown to Dead384参考文档391 概述1.1 标准自2002年廋AP架构成为WLAN业界新的趋势后，WLAN组网开始通过无线控制器（AC）来管理多个AP。AP和AC间采用各厂家私有的隧道协议进行通讯，这就造成了不同厂家AP与AC互通问题。为了解决隧道协议的不兼容问题，IETF在2005年成立了CAPWAP(Control and Provisioning of Wireless Access Points)工作组以标准化AP和AC间的隧道协议（RFC5415）。该协议主要功能：l AP自动发现AC，AC对AP进行安全认证；l AP从AC获取软件映像，AP从AC获得初始和动态配置等；l 系统可以支持本地数据转发和集中数据转发。该协议的目标：l 通过 AC 对 WLAN 系统集中执行强制策略和认证， 对系统中的 WTP 进行统一配置，把用户流量集中进行桥接、转发和加密，以增强大规模 WLAN 的可管理性，提高 WLAN的性能；l 使 WTP 不再处理高层协议，只执行与无线访问和控制相关且时间关联性强的功能，以有效利用 WTP 的硬件资源；l 提供一类封装和传输机制，使 CAPWAP 协议能够被应用到多种类型的无线接入点上。作为隧道协议的一个重要设计目标，它希望能够承载多种无线接入技术，如802.11和802.16。所以工作组协议包括了两部分：CAPWAP协议和无线binding协议。CAPWAP协议（RFC5415，2009年4月发布）作为通用隧道协议，完成了AP发现AC等基本协议功能，和具体的无线接入技术无关。目前工作组只提供了802.11的binding协议（RFC5416，2009年4月发布），以支持802.11网络的配置管理功能。1.2 CAPWAP协议系统框架1.2.1 Split MAC 模式在分离MAC模式，所有的数据和管理帧通过CAPWAP协议进行封装，在AC与AP之间交换，如图1.1.来自从一个Station收到的无线帧，会被直接封装，然后转发给AC。 +-+ wireless frames +-+ | |-| | | | +-+ | | | |-| |-| | | | wireless PHY | | CAPWAP | | | | MAC SubLayer | | | | +-+ +-+ +-+ STA WTP AC图1.1 CAPWAP的Split MAC 模式 1.2.2 Local MAC 模式 本地转发模式允许数据帧可以用本地桥或者使用802.3的帧形式用隧道转发。在这种情况下，二层无线管理帧在WTP本地已经处理，然后转发给AC。 下图显示了本地转发模式，Station传送的无线帧被封装成802.3数据帧，然后转发给AC，见图1.2：+-+ wireless frames +-+ 802.3 frames +-+ | |-| |-| | | | | | | | | |-| |-| | | | wireless PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC图1.2 CAPWAP的Local MAC 模式1.2.3 三种Tunnel模式CAPWAP协议中定义了三种Tunnel模式（WTP Frame Tunnel Mode）： 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reservd|N|E|L|U| +-+-+-+-+-+-+-+-+1)Local Bridging：Station和WTP之间加解密，流量本地转发；（L）2)802.3 Frame Tunnel：Station和WTP之间加解密，流量转换成802.3帧后通过CAPWAP隧道发往AC转发；(E)3)Native Frame Tunnel：流量保持802.11帧通过CAPWAP隧道发往AC再转发，加解密可以在WTP上进行也可以在AC上进行。(N)其中1和2对应了Local MAC方式；3对应了Split MAC模式。1.3 CAPWAP协议概述CAPWAP 是一个定义AC和WTP控制和数据报文交互的框架性协议。CAPWAP的控制消息以及部分的CAPWAP数据消息，使用UDP层的加密机制（DTLS: Datagram Transport Layer Security）。DTLS是基于TLS的标准IETF协议。CAPWAP传输层携带两种载荷：CAPWAP数据消息和控制消息。数据消息被封装成无线帧，控制消息作为管理消息在WTP与AC间进行交互。数据和控制消息分别传输在不同的UDP端口（AC上的CAPWAP控制报文端口为5246，数据报文端口为5247 ，WTP可以随意选择CAPWAP控制和数据端口）。当数据和控制报文超出了MTU值的长度，这些报文可以分片,CAPWAP在RFC5415 中定义了这种分片机制。1.3.1 CAPWAP工作原理WTP 被连接到网络时即进入发现 AC 的过程。 WTP 使用广播、组播或单播方式发送“发现请求” ， 当使用单播方式时，需首先通过 DHCP 或 DNS 获得 AC 的 IP 地址列表。收到请求的 AC 返回“发送应答”给 WTP，WTP 在应答的 AC 中，选择一个建立 DTLS 连接。 DTLS 连接建立成功后，WTP 发送“加入请求” ，AC 回复“加入应答”确认 WTP 加入该 AC 的管理范围。若 WTP的固件版本过期，则进入升级固件过程，WTP 从 AC 下载最新版本的固件，升级成功以后重启，重新进入发现过程；若WTP 固件为最新版本，则从 AC 下载配置参数，随后进入运行阶段。下图为工作原理示意图。图1.3 CAPWAP工作原理示意图 在运行状态中，AC 通过控制报文动态更改 WTP 配置，获取 WTP 运行状态、STA 信息、射频信息等，由于所有数据都集中在 AC 进行处理， 因此可以很容易实施全网级的 QoS、动态射频管理等策略。1.3.2 AP发现AC的过程我们如何得知AC的IP地址呢？1. 在WTP 内静态配置WTP的发现过程是可选的。如果在WTP上静态配置了AC，那么WTP并不需要完成AC的发现过程。 2. 通过CAPWAP的Discover获得（广播不能跨网段） WTP首先发送一个 Discovery Request message给受限的广播地址，或者CAPWAP的多播地址(224.0.1.140)，或者是预配置的AC的单播地址。在IPV6网络中，由于广播并不存在，因此使用All ACs multicast address (FF0X:0:0:0:0: 0:0:18C)来代替。 3. Option 43通过DHCP获得（如现在已经可用的DHCP Option43）没有配置静态AC IP地址，且通过DHCP获取自己的IP地址，则可以通过OPTION 43选项获取AC IPv4地址和/或OPTION 52获取AC IPv6地址4. 通过DNS解析获得如果AP获取到了DNS服务器地址，则AP可以通过DNS方式来获取AC地址。 1.3.3 DTLS 握手（DTLS: Datagram Transport Layer Security RFC4347）1. WTP首先发送一个ClientHello消息来发起握手，说明它支持的密码算法列表、压缩方法及最高协议版本和其他一些需要的消息。2. AC回复一个HelloVerifyReuqest 消息，client必须重传添加了cookie的ClientHello。server然后验证cookie，如果有效的话才开始进行握手。3. AC回应一个ServerHello消息，包含服务器选择的连接参数，源自客户端初期所提供的ClientHello，确定了这次通信所需要的算法，然后发过去自己的证书(里面包含了身份和自己的公钥)。4. Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。1.3.4 CAPWAP Session建立过程下面简要介绍一下CAPWAP会话建立的流程，对于DTLS连接过程在本文中暂不涉及，交互流程见图1.4：图1.4 CAPWAP消息交互流程图1.3.4.1 Capwap状态机各阶段WTP状态介绍Discovery-Join-(Image Data)-Configuration-Data check-Run1. Discovery：寻找一个最佳AC，与之交互, AP决策选择AC（当收到多个AC回应discover response时）1) AC的优先级2) AC上当前AP个数Join：得到AC的ip后建立socket与AC绑定，建立control channel，接收AC来的控制报文。Data image：软件升级，与AC交互，判定当前AP的软件版本与AC上配置的版本号是否匹配，匹配则不升级，进入到下一个状态，否则从AC下载升级文件，完毕后重启。Config：该状态用于AP配置下发，AP发送 Configuration raquest到AC,AC通过Configuration response 对AP配置做重新设置。 Data check：AC与AP在Join状态建立控制隧道，在Data check状态建立数据隧道，建立线程接收从AC发来的数据发往station。Run：进入run后接收AC下发的配置命令，并可根据需要进行信息的收集和上报AC，AC可事实监控AP运行状态。1.3.4.2 CAPWAP JOIN过程1. AP发送Join Request，该消息包含：AP软硬件信息，AP名称，AP无线信息，隧道报文格式等 2. AC收到Join Request，消息包含:AC名称，AC希望AP运行的版本信息，CAPWAP控制地址.3. AP已有AC下发版本，但未运行，则AP直接重启运行该版本，进入Configuration状态 4. AP已有AC下发版本且正在运行，则AP直接进入Configuration状态1.3.4.3 CAPWAP IMAGE过程1. AP加入AC后，需要与AC确定运行的版本，若没有该版本，需要向AC申请下载。 2. 在Run状态时，AC也会下载新版本给AP.如上流程:如AP处于RUN状态，AC希望AP更新版本，会发送配置更新信息指示AP下载请求。 1.3.4.4 CAPWAP Configuration过程1.3.4.5 RUN 过程AP 进入Run 状态后，AP 与AC 开始转发用户数据，同时也需要定期检查CAPWAP通道是否正常工作。Keepalive 在数据通道传输，是数据通道的保活报文，而控制通道是依靠Echo 进行保活。 通道保持过程： - Data Check State Complete - (- enter RUN state -) : : Echo Request - Echo Response Event Response - : :WTP Data Transfer Case WTP AC Data Transfer Request (Data Transfer Mode = Crash Data) Data Transfer Request (Data Transfer Data = Data) - Data Transfer Response (Result Code = Success) Data Transfer Response (Result Code = Success) - WTP Data Transfer CaseWTP AC Data Transfer Request (Data Transfer Mode = Crash Data) WTP Data Transfer Case 2 CAPWAP协议分析CAPWAP采用UDP的C/S模型进行AP与AC之间的交互, CAPWAP同时支持UDP和UDP-Lite(针对IPv6)传输协议。2.1 UDP 传输CAPWAP协议的控制报文使用控制通道，AC使用UDP的5246端口，AP的控制端口为任意端口；数据报文使用数据通道，使用UDP的5247端口，如果AC的控制端口被替换，AC的数据端口必须为AC控制端口的下一个端口，AP的数据端口为任意端口。当CAPWAP运行在IPv6上，将使用UDP-Lite传输协议。2.2 CAPWAP报文格式CAPWAP报文分为控制和数据两种消息，除了控制消息的Discovery Request和Discovery Response消息外其余的大部分消息均用DTLS进行加密封装。CAPWAP的控制报文格式如下：+-+| IP | UDP | CAPWAP | Control | Message | Hdr | Hdr | Header | Header | Element(s) |+-+图2.1 CAPWAP控制报文帧格式一（Discovery Request/Response）+-+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | +-+ - 认证-/ - 加密-/图2.2 CAPWAP控制报文帧格式二（经DTLS 安全加密处理的）CAPWAP的数据报文格式如下：（CAPWAP协议对数据报文的DTLS加密是可选的。）+-+| IP | UDP | CAPWAP | Wireless | Hdr | Hdr | Header | Payload |+-+图2.3 CAPWAP数据明文帧格式+-+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | | Hdr | Hdr | DTLS Hdr | Hdr | Header | Payload | Trlr | +-+ - 认证-/ - 加密-/图2.4 CAPWAP加密数据报文帧格式2.2.1 CAPWAP Header分析CAPWAP 协议的所有报文都包含 CAPWAP 首部，在控制信道收到则是控制报文，在数据信道收到则是数据报文，其帧格式见下： CAPWAP 首部报文各组成部分如下：(1) CAPWAP Preamble：8 位预判码，2 种 CAPWAP 首部的前 8 位为预判码，用于快速判断此报文是否经过 DTLS 加密。前 4 位指明 CAPWAP 版本，目前的版本号为 0；后 4 位值为 1 时是 CAPWAP DTLS 首部，值为 0 时是 CAPWAP 首部。Version：version of capwap Type：0-capwap header 1-capwap dtls header(2) HLEN：5 位首部长度，指明 CAPWAP 首部的长度。(3) RID：5 位射频标识符，指明此报文的来源射频。(4) WBID： 5 位无线帧标识符， 指明无线帧类型， 有 IEEE 802.11, IEEE802.16 和 EPC Global 3 种。(5) T：1 位数据帧标识符，值为 1 时数据帧是由 WBID指明的类型，值为 0 时是 IEEE802.3 数据帧。(6) F：1 位分组标志，值为 1 时此报文是一个 CAPWAP报文分组(IPV6)，需要和其他分组重组成完成的报文。(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：数据报文是用户数据，控制报文则是控制消息。2.2.1.1 CAPWAP数据消息分析CAPWAP数据包包括CAPWAP数据报文有两种类型：CAPWAP Data channel Keep-Alive 报文和Data Payload报文。 CAPWAP Data hannel Keep-Alive报文用于同步控制和数据通道，维持数据通道的连接。 Data Payload报文用于在AC和WTP之间传输用户数据。 2.2.1.2 CAPWAP控制消息分析CAPWAP控制协议提供了一个在AP与AC之间的控制通道，涉及如下控制消息类型：摘自RFC5415：l Discovery: to identify potential AC, their load and capabilities.l Join: request service from an AC, and for the AC to respond to the WTP.l Control Channel Management: maintain the control channel.l WTP Configuration Management: used by the AC to deliver a specific configuration to the WTP. l Station Session Management: used by the AC to deliver specific station policies to the WTP.l Device Management Operations: to request and deliver a firmware image to the WTP. Discovery, Join, Control Channel Management, WTP Configuration Management, 以及Station Session Management等CAPWAP控制消息是必须实现的，Device Management Operations messages 可以选择实现。2.2.1.3 控制消息格式控制消息封装在CAPWAP头里传输，其帧格式如下： 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 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq Num | Msg Element Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Element 0.N . +-+-+-+-+-+-+-+-+-+-+-+-+图2.6 CAPWAP 控制消息帧格式l 消息类型(Message Type)来指定CAPWAP控制消息的功能，CAPWAP提供的控制消息如下表：CAPWAP控制消息消息类型值Discovery Request 1Discovery Response 2Join Request 3Join Response 4Configuration Status Request 5Configuration Status Response 6Configuration Update Request 7Configuration Update Response 8WTP Event Request 9WTP Event Response 10Change State Event Request 11Change State Event Response 12Echo Request 13Echo Response 14Image Data Request 15Image Data Response 16Reset Request 17Reset Response 18Primary Discovery Request 19Primary Discovery Response 20Data Transfer Request 21Data Transfer Response 22Clear Configuration Request 23Clear Configuration Response 24Station Configuration Request 25Station Configuration Response 26l 消息序号：用于匹配请求与相应数据包，当一个请求类型的数据包被接收后，该消息序号被拷贝进相应的应答消息中。l 消息元素长度l 标志位：需要全部置0l 消息元素：每一个消息元素携带的信息与每一控制消息类型有关，一个控制消息可以携带一个或多个消息元素, Message Element:紧跟控制头，格式为Type/Length/Value这样的TLV三元组2.2.2 CAPWAP消息元素分析 消息元素作为消息的信息载体，其帧格式(TLV格式)见下： 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value . | +-+-+-+-+-+-+-+-+l 类型：16位的类型与使用范围见下：UsageType Values CAPWAP Protocol Message Elements 1 - 1023 IEEE 802.11 Message Elements 1024 - 2047 Reserved for Future Use 2048 - 3071 EPCGlobal Message Elements 3072 - 4095 Reserved for Future Use 4096 - 65535下表提供了CAPWAP支持的消息元素和相关值：CAPWAP Message ElementType ValueCAPWAP Message ElementType Value AC Descriptor 1 Duplicate IPv6 Address 22 AC IPv4 List 2 ECN Support 53 AC IPv6 List 3 Idle Timeout 23 AC Name 4 Image Data 24 AC Name with Priority 5 Image Identifier 25 AC Timestamp 6 Image Information 26 Add MAC ACL Entry 7 Initiate Download 27 Add Station 8 Location Data 28 Reserved 9 Maximum Message Length 29 CAPWAP Control IPV4 Address 10 MTU Discovery Padding 52 CAPWAP Control IPV6 Address 11 Radio Administrative State 31 CAPWAP Local IPV4 Address 30 Radio Operational State 32 CAPWAP Local IPV6 Address 50 Result Code 33 CAPWAP Timers 12 Returned Message Element 34 CAPWAP Transport Protocol 51 Session ID 35 Data Transfer Data 13 Statistics Timer 36 Data Transfer Mode 14 Vendor Specific Payload 37 Decryption Error Report 15 WTP Board Data 38 Decryption Error Report Period 16Reserved 43 Delete MAC ACL Entry 17WTP MAC Type 44 Delete Station 18WTP Name 45 Reserved 19Unused/Reserved 46 Discovery Type 20WTP Radio Statistics 47 Duplicate IPv4 Address 21WTP Reboot Statistics 483 CAPWAP状态机3.1 3.1 CAPWAP状态机详解3.1.1 Start to Idle这个状态变迁发生在设备初始化完成。WTP: 开启CAPWAP状态机。 AC: 开启CAPWAP状态机。3.1.2 Idle to Discovery这个状态变迁发生是为了支持CAPWAP发现进程。 WTP:WTP进入发现状态是为了优先去传输第一个Discovery Request message。在进入这个状态之前，WTP设置发现DiscoveryInterval timer，将DiscoveryCount counter为0.同时清理以前的发现过程中可能会从AC收到的所有信息。 AC：由发现线程执行，且发生在收到一个发现请求报文的时候。此时，AC需要给这个报文响应一个Discovery Response message 。3.1.3 Discovery to Discovery在这个发现状态，WTP决定连接哪个AC。 WTP：这个状态变迁发生在发现DiscoveryInterval timer触发的时候。对于这个事件的每次变迁，Discover