CAPWAP协议规范详解

下载需积分: 9 | PDF格式 | 206KB | 更新于2024-07-26 | 26 浏览量 | 举报

"CAPWAP协议规范 RFC5415" 控制与配置无线接入点（CAPWAP）协议是网络工作小组（Network Working Group）在RFC 4564中定义的目标，旨在实现对无线接入点的管理和配置。CAPWAP协议设计灵活，能够适应多种无线技术的需求。此文档主要描述了基础的CAPWAP协议，同时通过单独的绑定扩展，使其能够应用于其他额外的无线技术。 CAPWAP协议的核心目标是提供一种标准方法，使得无线接入点（WAP）能够与无线局域网控制器（WLC）进行通信，以便于集中管理、配置和监控无线网络。它允许WLC远程控制和配置接入点，包括固件更新、射频管理、安全策略实施以及用户接入控制等。 RFC5415是这个协议的标准化文档，由P. Calhoun、M. Montemurro和D. Stanley等人共同编写，于2009年3月发布，属于互联网标准轨道协议，适用于互联网社区，并鼓励讨论和改进建议。该文档的发布遵循了“互联网官方协议标准”（STD1）的当前版本，并且不受限于特定的分布范围。 CAPWAP协议由两个主要组件构成：控制通道和数据通道。控制通道用于WAP与WLC之间的管理和配置消息交换，而数据通道则负责用户数据的传输。这种分离的设计确保了管理流量与用户流量的独立性，提高了网络的效率和安全性。协议中定义的关键概念包括： 1. 控制报文：用于建立、维护和终止CAPWAP连接，以及执行配置和状态查询。 2. 数据报文：封装用户数据，如IP包，通过隧道在WAP和WLC之间传输。 3. 隧道机制：CAPWAP协议使用隧道技术将无线用户的流量从接入点转发到控制器，实现集中处理和策略应用。 CAPWAP协议还支持不同类型的无线技术，通过特定的扩展来适应802.11系列标准以及其他可能的无线技术。这些扩展可以涵盖无线介质访问控制（MAC）、射频管理、认证和加密等方面，确保了协议的兼容性和可扩展性。版权方面，CAPWAP协议的文档受到IETF信托及其指定作者的版权保护，并受BCP78及IETF文档的法律条款约束。阅读和使用此文档时，应仔细查看相关文档以了解权利和限制。 CAPWAP协议为无线网络的集中管理和高效运营提供了强大的工具，通过标准化的协议接口，促进了不同厂商设备之间的互操作性，简化了网络部署和维护的工作。

RFC 5415 CAPWAP Protocol Specification March 2009

/-------------------------------------\

| /-------------------------\|

| p| ||

| q+----------+ r +------------+ ||

| | Run |-->| Reset |-\||

| +----------+ +------------+ |||

n| o ^ ^ ^ s|||

+------------+--------/ | | |||

| Data Check | /-------/ | |||

+------------+<-------\ | | |||

| | | |||

/------------------+--------\ | |||

f| m| h| j v k| |||

+--------+ +-----------+ +--------------+|||

| Join |---->| Configure | | Image Data ||||

+--------+ n +-----------+ +--------------+|||

^ |g i| l| |||

| | \-------------------\ | |||

| \--------------------------------------\| | |||

\------------------------\ || | |||

/--------------<----------------+---------------\ || | |||

| /------------<----------------+-------------\ | || | |||

| | 4 |d t| | vv v vvv

| | +----------------+ +--------------+ +-----------+

/-|-|---+----------------+ +--------------+ e +-----------+

| | | |$ ^ ^ |5 ^6 ^ ^ |w

v v v | | | | \-------\ | | |

| | | | | | \---------\ | | /-----------/ |

| | | | | \--\ | | | | |

| | | | | | | | | | |

| | | v 3| 1 |% # v | |a |b v

| | \->+------+-->+------+ +-----------+ +--------+

| | +------+<--+------+ +-----------+ +--------+

| | ^ 0^ 2 |!

| | | | | +-------+

*| |u | \---------+---| Start |

| | |@ | +-------+

| \->+---------+<------/

\--->| Sulking |

+---------+&

Figure 4: CAPWAP Integrated State Machine

The CAPWAP protocol state machine, depicted above, is used by both

the AC and the WTP. In cases where states are not shared (i.e., not

implemented in one or the other of the AC or WTP), this is explicitly

Calhoun, et al. Standards Track [Page 16]

RFC 5415 CAPWAP Protocol Specification March 2009

called out in the transition descriptions below. For every state

defined, only certain messages are permitted to be sent and received.

The CAPWAP Control message definitions specify the state(s) in which

each message is valid.

Since the WTP only communicates with a single AC, it only has a

single instance of the CAPWAP state machine. The state machine works

differently on the AC since it communicates with many WTPs. The AC

uses the concept of three threads. Note that the term thread used

here does not necessarily imply that implementers must use threads,

but it is one possible way of implementing the AC’s state machine.

Listener Thread: The AC’s Listener thread handles inbound DTLS

session establishment requests, through the DTLSListen command.

Upon creation, the Listener thread starts in the DTLS Setup state.

Once a DTLS session has been validated, which occurs when the

state machine enters the "Authorize" state, the Listener thread

creates a WTP session-specific Service thread and state context.

The state machine transitions in Figure 4 are represented by

numerals. It is necessary for the AC to protect itself against

various attacks that exist with non-authenticated frames. See

Section 12 for more information.

Discovery Thread: The AC’s Discovery thread is responsible for

receiving, and responding to, Discovery Request messages. The

state machine transitions in Figure 4 are represented by numerals.

Note that the Discovery thread does not maintain any per-WTP-

specific context information, and a single state context exists.

It is necessary for the AC to protect itself against various

attacks that exist with non-authenticated frames. See Section 12

for more information.

Service Thread: The AC’s Service thread handles the per-WTP states,

and one such thread exists per-WTP connection. This thread is

created by the Listener thread when the Authorize state is

reached. When created, the Service thread inherits a copy of the

state machine context from the Listener thread. When

communication with the WTP is complete, the Service thread is

terminated and all associated resources are released. The state

machine transitions in Figure 4 are represented by alphabetic and

punctuation characters.

2.3.1. CAPWAP Protocol State Transitions

This section describes the various state transitions, and the events

that cause them. This section does not discuss interactions between

DTLS- and CAPWAP-specific states. Those interactions, and DTLS-

specific states and transitions, are discussed in Section 2.3.2.

Calhoun, et al. Standards Track [Page 17]

RFC 5415 CAPWAP Protocol Specification March 2009

Start to Idle (0): This transition occurs once device initialization

is complete.

WTP: This state transition is used to start the WTP’s CAPWAP

state machine.

AC: The AC creates the Discovery and Listener threads and starts

the CAPWAP state machine.

Idle to Discovery (1): This transition occurs to support the CAPWAP

discovery process.

WTP: The WTP enters the Discovery state prior to transmitting the

first Discovery Request message (see Section 5.1). Upon

entering this state, the WTP sets the DiscoveryInterval

timer (see Section 4.7). The WTP resets the DiscoveryCount

counter to zero (0) (see Section 4.8). The WTP also clears

all information from ACs it may have received during a

previous Discovery phase.

AC: This state transition is executed by the AC’s Discovery

thread, and occurs when a Discovery Request message is

received. The AC SHOULD respond with a Discovery Response

message (see Section 5.2).

Discovery to Discovery (#): In the Discovery state, the WTP

determines to which AC to connect.

WTP: This transition occurs when the DiscoveryInterval timer

expires. If the WTP is configured with a list of ACs, it

transmits a Discovery Request message to every AC from which

it has not received a Discovery Response message. For every

transition to this event, the WTP increments the

DiscoveryCount counter. See Section 5.1 for more

information on how the WTP knows the ACs to which it should

transmit the Discovery Request messages. The WTP restarts

the DiscoveryInterval timer whenever it transmits Discovery

Request messages.

AC: This is an invalid state transition for the AC.

Discovery to Idle (2): This transition occurs on the AC’s Discovery

thread when the Discovery processing is complete.

WTP: This is an invalid state transition for the WTP.

Calhoun, et al. Standards Track [Page 18]

RFC 5415 CAPWAP Protocol Specification March 2009

AC: This state transition is executed by the AC’s Discovery

thread when it has transmitted the Discovery Response, in

response to a Discovery Request.

Discovery to Sulking (!): This transition occurs on a WTP when AC

Discovery fails.

WTP: The WTP enters this state when the DiscoveryInterval timer

expires and the DiscoveryCount variable is equal to the

MaxDiscoveries variable (see Section 4.8). Upon entering

this state, the WTP MUST start the SilentInterval timer.

While in the Sulking state, all received CAPWAP protocol

messages MUST be ignored.

AC: This is an invalid state transition for the AC.

Sulking to Idle (@): This transition occurs on a WTP when it must

restart the Discovery phase.

WTP: The WTP enters this state when the SilentInterval timer (see

Section 4.7) expires. The FailedDTLSSessionCount,

DiscoveryCount, and FailedDTLSAuthFailCount counters are

reset to zero.

AC: This is an invalid state transition for the AC.

Sulking to Sulking (&): The Sulking state provides the silent

period, minimizing the possibility for Denial-of-Service (DoS)

attacks.

WTP: All packets received from the AC while in the sulking state

are ignored.

AC: This is an invalid state transition for the AC.

Idle to DTLS Setup (3): This transition occurs to establish a secure

DTLS session with the peer.

WTP: The WTP initiates this transition by invoking the DTLSStart

command (see Section 2.3.2.1), which starts the DTLS session

establishment with the chosen AC and the WaitDTLS timer is

started (see Section 4.7). When the Discovery phase is

bypassed, it is assumed the WTP has locally configured ACs.

Calhoun, et al. Standards Track [Page 19]

RFC 5415 CAPWAP Protocol Specification March 2009

AC: Upon entering the Idle state from the Start state, the newly

created Listener thread automatically transitions to the

DTLS Setup and invokes the DTLSListen command (see

Section 2.3.2.1), and the WaitDTLS timer is started (see

Section 4.7).

Discovery to DTLS Setup (%): This transition occurs to establish a

secure DTLS session with the peer.

WTP: The WTP initiates this transition by invoking the DTLSStart

command (see Section 2.3.2.1), which starts the DTLS session

establishment with the chosen AC. The decision of to which

AC to connect is the result of the Discovery phase, which is

described in Section 3.3.

AC: This is an invalid state transition for the AC.

DTLS Setup to Idle ($): This transition occurs when the DTLS

connection setup fails.

WTP: The WTP initiates this state transition when it receives a

DTLSEstablishFail notification from DTLS (see

Section 2.3.2.2), and the FailedDTLSSessionCount or the

FailedDTLSAuthFailCount counter have not reached the value

of the MaxFailedDTLSSessionRetry variable (see Section 4.8).

This error notification aborts the secure DTLS session

establishment. When this notification is received, the

FailedDTLSSessionCount counter is incremented. This state

transition also occurs if the WaitDTLS timer has expired.

AC: This is an invalid state transition for the AC.

DTLS Setup to Sulking (*): This transition occurs when repeated

attempts to set up the DTLS connection have failed.

WTP: The WTP enters this state when the FailedDTLSSessionCount or

the FailedDTLSAuthFailCount counter reaches the value of the

MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon

entering this state, the WTP MUST start the SilentInterval

timer. While in the Sulking state, all received CAPWAP and

DTLS protocol messages received MUST be ignored.

AC: This is an invalid state transition for the AC.

DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS

Session failed to be established.

WTP: This is an invalid state transition for the WTP.

Calhoun, et al. Standards Track [Page 20]

剩余155页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

gloomuu

粉丝: 5

CAPWAP协议规范详解

Current Status and Overview of the CAPWAP Protocol.pdf

CAPWAP Overview.ppt

v4007-2566-0314-0953-pb44.tar.gz_capwap_capwap-protocol

capwap.rar_capwap_capwap source code_capwap linux_capwap-proto

capwap隧道

capwap协议

CAPWAP协议

capwap介绍

capwap source code

CAPWAP学习小记

最新资源