CAPWAP基础教程
Table of Contents
1 capwap
1.1 Related
1.1.1 LWAPP
Lightweight Access Point Protocol
LWAPP defines the state machine that governs both the AP and the controller’s communication with each other. The basic functionality that is encapsulated within this protocol is as follows.
- Discovery - New APs must seek out a controller with which to associate. This is accomplished by the AP broadcasting a Discovery Request. A controller must respond with a Discovery Response. The AP then joins to a controller, and is acknowledged by the controller.
- Image Download - The newly joined AP then may request a firmware update, upon seeing the controller advertise a higher version of code. The AP then downloads the firmware, and once completed, enters the Reset state, and then attempts to rejoin a controller.
- Configure - An AP with a sufficient version of code may then request to be configured by the controller. The AP sends the controller its current configuration, and the controller responds with an updated configuration. Once the AP has received the configuration, it may enter the Run state.
- Run - Both the controller and AP operate in the Run state. The AP forwards packets to the controller, and maintains normal operation. From the Run state, an AP and controller may exchange new key material, by entering the Key Update state. This state updates the encryption keys on both devices, which is used to encrypt all further messages, until a new key is requested.
1.1.2 SLAPP
Secure Light Access Point Protocol
SLAPP operates as the framework to make a connection between two devices, and negotiate a protocol. The same SLAPP protocol would be used by an AP to decide how to download updated firmware, as would be used to determine a protocol to communicate with the controller. The state machine in [fig6] show the 4 states attainable during protocol negotiation by a device. [RFC5413]
- Discovery - Discovery is the initial broadcast from an AP, informing controllers that they are interested in communicating in a specific protocol. The controller awaits a Discovery Request from an AP. Once received, the controller moves to the Acquiring phase without responding yet.The AP broadcasts a Discovery Request, and upon reception of the response, moves to the Acquiring phase as well.
- Acquiring - This state represents both devices connecting to each other, to begin encrypting their communications. The controller processes the Discovery Request, and if valid, responds in the positive, and moves to Securing. Otherwise it moves back to the Discovery state. The AP transitions to the Securing phase when a “client hello” message has been received. This marks the beginning of a DTLS conversation, or Datagram Transport Layer Security [RFC4347]. If a timer expires while the AP is in the Acquiring phase before receiving a “client hello”, the AP goes back to Discovery mode.
- Securing - This phase establishes an encrypted tunnel, over which a protocol can be agreed upon. The controller transmits a “client end” message, to signify the termination of the DTLS exchange. The controller then moves into the Negotiated Control Protocol state. The AP reciprocates the DTLS connection, and when finished, transmits the “server end” message. When the DTLS exchange is completed, the AP moves to Negotiated Control Protocol.
- Negotiated Control Protocol - Here both devices begin communicating in the previously agreed-upon protocol. This protocol can be anything, as long as both sides agreed on it.
1.2 CAPWAP Packet Format
- Not protected by DTLS
- DTLS Security Required
IP Hdr UDP Hdr CAPWAP DTLS Hdr DTLS Hdr CAPWAP Header Control Header Message Element(s) DTLS Trlr authenticated encrypted - Version:4 位字段,它包括这个分组使用的 CAPWAP 版本。这个规范的版本编号为 0。
- Type:4 位字段,它规定跟在 UDP 首部后面的净荷类型。支持下述值:
- 0 - CAPWAP Header。CAPWAP Header(参阅第 4-3 节)紧跟在 UDP 首部后。如果分组是在 CAPWAP Data 通道上收到的, CAPWAP 栈必须将该分组看作明文 CAPWAP Data分组。如果分组是在 CAPWAP Control 通道上收到的,CAPWAP 栈必须将该分组看作明文 CAPWAP Control 分组。如果该控制分组既不是 Discovery Request 又不是Discovery Response 分组,必须丢弃该分组。
- 1 - CAPWAP DTLS Header。CAPWAP DTLS Header(和 DTLS 分组)紧跟在 UDP 首部后
- Message Type
Message Type 字段指出 CAPWAP Control 消息的功能。为了有可扩展性,Message Type 字段由 IANA Enterprise Number [RFC3232]和企业特定消息类型编码构成。前 3 个八位位组包含 IANA Enterprise Number,采用网络字节顺序,0 用于定义消息类型的 CAPWAP 基本 协议(这个规范)。最后的八位位组是企业特定消息类型编码,它的取值范围从 0 到 255。
Message Type 字段定义为: Message Type = IANA Enterprise Number*256 + Enterprise Specific Message Type Number
CAPWAP 协议可靠性机制要求成对定义消息,由 Request 和 Response 消息构成。 Response 消息必须确认 Request 消息。总是成对分配 CAPWAP Control Message Type Values。 所有 Request 消息有奇数编码的 Message Type Values,所有 Response 消息有偶数编码的 Message Type Values。必须先分配 Request 值。例如,为 Request 消息分配值为 3 的 Message Type Value, 为 Response 消息分配值为 4 的 Message Type Value 是合法的;而为 Response 消 息分配值为 4 的 Message Type Value,为 Request 消息分配值为 5 的 Message Type Value 是 不合法的。
当 WTP 或 AC 收到消息,该消息的 Message Type Value 字段不能识别并且是奇数,在 Message Type Value Field 中的数加 1,带有包含该增加值的 Message Type Value 字段和包含 带有该值(Unrecognized Request)的 Result Code 消息要素的 Response 消息被返回给所接收消 息的发送方。如果未知的消息类型是偶数,忽略该消息。
- Seq Num
Sequence Number 字段是标识符值,用于匹配 Request 和 Response 分组。当收到带有 Request Message Type Value 的 CAPWAP 分组时,Sequence Number 字段的值被复制到相应 的 Response 消息中。
当发送 CAPWAP Control 消息时,发送方的内部序列号计数器单调增加,确保不会出现 两个未定的 Request 消息有相同序列号。Sequence Number 字段环回到 0。
- Msg Element Length
此 Length 字段指出 Sequence Number 字段后的字节数。
- Flags
必须将 Flags 字段设置为 0。
- Message Element[0..N]
消息要素携带与每个控制消息类型有关的信息。在本规范中的每个控制消息规定哪些消 息要素是合法的。
当 WTP 或 AC 收到 CAPWAP 消息,而该消息不携带按规定它必须携带的消息要素, 那么,抛弃此 CAPWAP 消息。如果收到的消息是 Request 消息,与该消息相对应的 Response 消息携带消息要素,那么,将对应的 Response 消息(该消息带有指出“Failure - Missing Mandatory Message Element”的 Result Code 消息要素)返回给发送方。
当 WTP 或 AC 收到 CAPWAP 消息,该消息带有 WTP 或 AC 不能识别的消息要素,抛 弃该 CAPWAP 消息。如果收到的消息是 Request 消息,与该消息对应的 Response 消息携带 消息要素,那么,对应的 Response 消息(该消息带有指出“Failure - Unrecognized Message Element”的 Result Code 消息要素和一个或多个 Returned Message Element 消息要素)包括在 内,包含不能识别的消息要素。
1.2.1 CAPWAP Pramble
CAPWAP 前导对于所有 CAPWAP 传输首部是通用的,并且用于标识跟在其后的首部 类型。这个前导的作用是避免通过字节比较,来猜测是否这一帧是 DTLS 加密帧。它也提供 可用于支持补充传输类型的扩展架构。
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Version | Type |
1.2.2 CAPWAP Header
所有 CAPWAP 协议消息用共同的首部格式封装,与使用 CAPWAP Control 或 CAPWAP Data 传输方式携带消息无关。然而,某些标志不适用于给定的传输。为了确定哪些标志合 法,请参考介绍特定传输的节。
| 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 Pramble | HLEN | RID | WEBID | T | F | L | W | M | K | FLAG | |||||||||||||||||||||
| Fragment ID | Frag Offset | Rsvd | |||||||||||||||||||||||||||||
| (Option）Radio MAC Address | |||||||||||||||||||||||||||||||
| (Option）Wireless Specific Information | |||||||||||||||||||||||||||||||
| Paylaod… |
1.2.3 CAPWAP Control Message
| 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 |
| Meaage Type | |||||||||||||||||||||||||||||||
| Seq Num | Msg Element Length | Flags | |||||||||||||||||||||||||||||
| Msg Element [0..N]… |
1.2.4 CAPWAP Protocol Message Elements
这一节定义包含在 CAPWAP 协议控制消息中的 CAPWAP Protocol 消息要素。
消息要素用于携带控制消息中需要的信息。每个消息要素由 Type Value 字段标识,如 下面定义。在消息要素的长度字段指出消息要素的总长度。
本文档中所有消息要素定义使用类似于下面的格式图来描述消息要素的格式。注意,为 了简化本文档的介绍,这些格式图不包括首部字段(Type 和 Length)。在消息要素介绍中定 义首部字段值。
除非另有规定,控制消息(它列出一组支持的(或期盼的)消息要素),必须不指望这些消 息要素以任何规定的次序出现。发送方可以以任何次序包括消息要素。除非另有说明,在给 定的控制消息中每类消息要素只有一个。
除非另有规定,由 AC 发送给 WTP 的任何配置信息可以保存到非易失性存储器中(更多 信息参阅第 8-1 节)。
在独立的 IETF 文档中可以定义补充消息要素。
| 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… |
16 位 Type 字段标识 Value 字段携带的信息,Length(16 位)指出 Value 字段的字节数。0 值保留并且不能使用。字段值其余部分分配如下:
| 用途 | 类型值 |
| CAPWAP Protocol Message Elements | 1 - 1023 |
| IEEE 802.11Message Elements | 1024 – 2047 |
| 保留将来使用 | 2048 – 3071 |
| EPCGlobalMessage ElementsEPCGlobalMessage Elements | 3072 - 4095 |
| 保留将来使用 | 4096 - 65535 |
下表列出 CAPWAP 协议消息要素(Message Elements)和它们的 Type 值。
| CAPWAP Message Element | Type Value |
| AC Descriptor | 1 |
| AC IPv4 List | 2 |
| AC IPv6 List | 3 |
| AC Name | 4 |
| AC Name with Priority | 5 |
| AC Timestamp | 6 |
| Add MAC ACL Entry | 7 |
| Add Station | 8 |
| Reserved | 9 |
| CAPWAP Control IPV4 Address | 10 |
| CAPWAP Control IPV6 Address | 11 |
| CAPWAP Local IPV4 Address | 30 |
| CAPWAP Local IPV6 Address | 50 |
| CAPWAP Timers | 12 |
| CAPWAP Transport Protocol | 51 |
| Data Transfer Data | 13 |
| Data Transfer Mode | 14 |
| Decryption Error Report | 15 |
| Decryption Error Report Period | 16 |
| Delete MAC ACL Entry | 17 |
| Delete Station | 18 |
| Reserved | 19 |
| Discovery Type | 20 |
| Duplicate IPv4 Address | 21 |
| Duplicate IPv6 Address | 22 |
| ECN Support | 53 |
| Idle Timeout | 23 |
| Image Data | 24 |
| Image Identifier | 25 |
| Image Information | 26 |
| Initiate Download | 27 |
| Location Data | 28 |
| Maximum Message Length | 29 |
| MTU Discovery Padding | 52 |
| Radio Administrative State | 31 |
| Radio Operational State | 32 |
| Result Code | 33 |
| Returned Message Element | 34 |
| Session ID | 35 |
| Statistics Timer | 36 |
| Vendor Specific Payload | 37 |
| WTP Board Data | 38 |
| WTP Descriptor | 39 |
| WTP Fallback | 40 |
| WTP Frame Tunnel Mode | 41 |
| Reserved | 42 |
详细的Message Element请查看RFC section4.6