CAPWAP协议详解与无线局域网标准

5星 · 超过95%的资源需积分: 9 12 浏览量更新于2024-07-29 收藏 206KB PDF 举报

本资料集合主要围绕WLAN的两个关键标准——RFC5415和RFC5416进行，详细介绍了Control And Provisioning of Wireless Access Points (CAPWAP)协议。CAPWAP是一种用于管理与配置无线接入点(WAP)的标准协议，旨在简化WLAN网络的部署和维护。此外，还提供了一个开源项目capwap-0.93.3的实现，以及相关的技术文档和介绍，帮助读者深入理解CAPWAP的工作原理和实际应用。 RFC5415是CAPWAP协议的正式标准，由P. Calhoun等人编写，定义了互联网标准轨道协议，适用于互联网社区。该文档详细阐述了CAPWAP协议的规范，旨在促进讨论和改进建议。CAPWAP协议允许网络控制器与无线接入点之间进行通信，实现对WAP的控制、配置、状态报告和固件更新等功能。 RFC5416则着重于CAPWAP如何与IEEE 802.11标准协同工作，确保在无线局域网环境中的无缝集成。802.11标准定义了无线局域网的物理层和媒体访问控制层，而CAPWAP则是其管理和控制层面的重要补充。 capwap-0.93.3.tar.gz是一个开源项目，实现了CAPWAP协议，为开发者和研究人员提供了实际操作CAPWAP的机会，有助于更好地理解和测试CAPWAP的功能。 Opencapwap+An+Open+Source+Capwap+Implementation+For+The+Management+And+Configuration+Of+Wifi+Hot-spots.pdf是开源CAPWAP实现Opencapwap的介绍，由项目作者撰写，详细描述了如何利用这个工具来管理和配置Wi-Fi热点。 CAPWAP Overview.ppt、Current Status and Overview of the CAPWAP Protocol.pdf、基于CAPWAP协议的集中式无线局域网架构.pdf以及CAPWAP介绍.ppt等文件提供了CAPWAP协议的概述、当前状态、集中式架构的应用以及更多深入的讲解，帮助读者全面了解CAPWAP的各个方面。通过这些资源，读者可以系统地学习CAPWAP协议的基本概念、工作流程、优点和挑战，并能掌握如何在实际环境中应用CAPWAP来优化WLAN的管理和配置。后续的个人学习总结将进一步巩固和深化这些知识。

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页未读，继续阅读

suifeng

粉丝: 8
资源: 27

CAPWAP协议详解与无线局域网标准

RFC5415(中文)无线AP控制和配置CAPWAP协议标准-书签整齐版

capwap协议(rfc5415&rfc5416)

capwap 协议rfc5415

RFC3501.rar_RFC3501_rfc 3501_rfc35_rfc3501 pdf_rfc3501.pdf

rfc1905.pdf

rfc2630.pdf

rfc2045.pdf

rfc1902.pdf

rfc2616.pdf

rfc5053.pdf

最新资源