初識CAPWAP

初識CAPWAP

CAPWAP簡介

CAPWAP——Control And Provisioning of Wireless ＷＬＣ Acess Points Protocol Specification。
其協定由兩個部分組成：
1. CAPWAP協定和 2.無線BINDING協定。

前者是一個通用的隧道協議，完成AP發現WLC等基本協議功能，和具體的無
線接入技術無關。
後者是提供具體和某個無線接入技術相關的配置管理功能。

這麼說吧，前者規定了各個階段需要幹什麼事，後者就是具體到在各種接入方式下應該怎麼完成這些事。

    
CAPWAP協議在2009年4月的RFC5415中發佈，無線BINGDING協議目前只出臺了接入方式為802.11的RFC，也是2009年4月發佈的，RFC編號為5416。

PS：離開主題一下,順帶提一下802.11、802.15、802.16、802.20等無線接入方式的區別。

*********************************************************************

目前，IEEE802旗下的無線網路通訊協定一共有
802.11、
802.15、
802.16
802.20
等四大種類，這四大類協定中又包含各種不同性能的子協定，顯得很混亂的樣子……

 

IEEE802.11體系定義的是無線局域網標準（WLAN，Wireless Local Area Network），針對家庭和企業中的局域網而設計，應用範圍一般局限在一個建築物或一個小建築物群（如學校、社區等）。

IEEE802.15定義的其實是無線個人網路（WPAN，Wireless Personal Area Network），主要用於個人電子設備與PC的自動互聯，這類設備包括手機、MP3播放機、便攜媒體播放機、數碼相機、掌上型電腦等等。

IEEE802.16是一種寬頻無線接入技術（Broadband Wireless ＷＬＣcess，BWA），主要用於遠距離、高速度的通訊環境，定義的是都會區網路絡（MAN，Metropolitan Area Network），性能可媲美Cable電纜、DSL、T1專線等傳統的有線技術。IEEE802.16包含802.16和802.16a兩項子協議，前者的作用距離為2公里，傳輸速率在30Mbps至130Mbps之間，而802.16a的傳輸距離可達到50公里，速率也能達到75Mbps—看得出，在上述各種無線通訊技術中，還沒有哪項技術可以在有效範圍和性能標準上都蓋過IEEE802.16a。

 

IEEE802.20與802.16在特性上有些類似，都具有傳輸距離遠、速度快的特點。不過802.20是一項移動寬頻接入技術（Mobile Broadband Wireless ＷＬＣcess，MBWR），他更側重於設備的可移動性，例如在高速行駛的火車、汽車上都能實現資料通訊（802.16無法做到這一點）。

*********************************************************************

    

CAPWAP協議的主要功能：

AP自動發現ＷＬC，
ＷＬC對AP進行安全認證，
AP從ＷＬＣ獲取軟體映射，
　　AP從ＷＬＣ獲得初始和動態配置等。
　　此外，系統可以支援本地資料轉發和集中資料轉發。

Lightweight AP架構讓ＷＬＣ具有了對整個WLAN網路的完整視圖，為無線漫遊、無線資源管理等業務功能的實現提供了基礎。

 

2一些名詞

 無線控制器(ＷＬＣ／ＡＣ)：網路實體，在網路架構的資料層，控制層，管理層或者聯合起來提供ＡＰ到網路的訪問服務。


CAPWAP控制通道：一個雙向通道，由ＷＬＣ的IP位址，ＡＰ的IP位址，ＷＬＣ控制埠，ＡＰ控制埠，傳輸層協議（UDP或者UDP-Lite）定義，在這之上可以收發CAPWAP的控制資訊。

 CAPWAP資料通道：一個雙向通道，由ＷＬＣ的IP位址，ＡＰ的IP位址，ＷＬＣ資料埠，ＡＰ資料埠，傳輸層協定（UDP或者UDP-Lite）定義，在這之上可以收發CAPWAP的資料包文。



STATION(Client)：一個包含無線介面的設備



無線終端ＡＰ：物理或者網路實體，包含一個射頻天線和無線實體層可

傳輸和接收 STA在無線存取網路的資料。

 

3 CAPWAP的模式

　    CAPWAP協定支援兩種模式的操作：Split MAC和Local MAC。

    Split MAC：在split MAC模式下，所有二層的無線資料和管理訊框都會被
　　CAPWAP協定封裝，然後在ＷＬＣ和（ＡＰ／ＷＴＰ）之間交換。

如下圖中所示，從一個Station收到的無線訊框，會被直接封裝，然後轉發給
ＷＬＣ。

Local MAC：本地轉發模式允許資料訊框可以用本地橋或者使用802.3的訊框形式用隧道轉發。
在這種情況下，二層無線管理訊框在ＡＰ本地已經處理，然後轉發給ＷＬＣ。

下圖顯示了本地轉發模式，Station傳送的無線訊框被封裝成802.3資料訊框，然後轉發給ＷＬＣ。

2.4 CAPWAP的資料類型

CAPWAP協定傳輸層運輸兩種類型的資料：

資料消息

　封裝轉發無線訊框

控制消息

管理ＡＰ和ＷＬＣ之間交換的管理消息

CAPWAP資料和控制資訊基於不同的UDP埠發送，且允許被分割，因此資料和控制資訊可以超過MTU長度。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.5 CAPWAP會話創建過程

CAPWAP協議從發現階段開始。ＡＰs發送一個發現請求消息，任何接收到這個請求的ＷＬＣ將會回應一個發現回應資訊。接收到發現響應資訊，ＡＰ選擇一個ＷＬＣ來建立一個 基於DTLS的安全會話。為了建立DTLS安全連接，ＡＰ將需要一個預先提供的資料，將在後面說明。CAPWAP協定資訊將會被分段成網路支援的最大長度。

一旦ＡＰ和ＷＬＣ完成了DTLS會話建立，兩者之間會交換配置，來在版本資訊上達成一致。在這個交換過程之間，ＡＰ可能會接收到規定設置，然後會開啟這些設置。

當ＡＰ和ＷＬＣ之間完成版本和設置的交換，並且ＡＰ已經開啟，CAPWAP協議將被使用來封裝ＷＬＣ和ＡＰ之間發送的無線資料訊框。如果使用者資料或者協定控制資料長度超過 ＡＰ和ＷＬＣ之間的MTU會導致CAPWAP協定將L2層訊框分片。被分片的CAPWAP資訊將會被重新組成原來的封裝資訊。

 

 

 

2.5.1 ＷＬＣ發現機制

ＡＰ使用ＷＬＣ發現機制來得知哪些ＷＬＣ是可用的，決定最佳的ＷＬＣ來建立CAPWAP連接。

ＡＰ的發現過程是可選的。如果在ＡＰ上靜態配置了ＷＬＣ，那麼ＡＰ並不需要完成ＷＬＣ的發現過程。

ＡＰ首先發送一個 Discovery Request message給受限的廣播位址，或者CAPWAP的多播地址(224.0.1.140)，或者是預配置的ＷＬＣ的單播地址。在IPV6網路中，由於廣播並不存在，因此使用"All ＷＬＣs multicast address" (FF0X:0:0:0:0: 0:0:18C)來代替。

當接收到Discovery Request message消息，ＷＬＣ發送一個單播Discovery Response message給ＡＰ。

ＡＰ可以通過Discovery Response message中所帶的ＷＬＣ優先順序，支持的CAPWAP binding來選擇與哪個ＷＬＣ建立會話。

除了上面的發現機制，ＡＰ還可以使用DNS或者DHCP來發現ＷＬＣ。

2.5.2 DTLS握手

ＡＰ首先發送一個ClientHello消息來發起握手，說明它支援的密碼演算法清單、壓縮方法及最高協定版本和其他一些需要的消息。

ＷＬＣ回復一個HelloVerifyReuqest 消息，client必須重傳添加了cookie的ClientHello。server然後驗證cookie，如果有效的話才開始進行握手。

ＷＬＣ回應一個ServerHello消息，包含伺服器選擇的連接參數，源自用戶端初期所提供的ClientHello，確定了這次通信所需要的演算法，然後發過去自己的證書（裡面包含了身份和自己的公開金鑰）。

Client在收到這個消息後會生成一個秘密消息，用SSL伺服器的公開金鑰加密後傳過去，SSL伺服器端用自己的私密金鑰解密後，工作階段金鑰協商成功，雙方可以用同一份工作階段金鑰來通信了。

2.5.3 DTLS認證和授權

DTLS支援終端認證方式為：證書（certificate）和預共用金鑰（pre-shared key）。

CAPWAP認證中使用證書支援的演算法是

 TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]（MUST SUPPORT）

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246](SHOULD SUPPORT)

 TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246](MAY SUPPORT)

 TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246] ](MAY SUPPORT)

在RFC4279中定義了多種預共用金鑰的認證方式，CAPWAP中主要關心下面兩種：

 Pre-Shared Key (PSK) key exchange algorithm

 DHE_PSK key exchange algorithm

同樣，CAPWAP定義了預共用金鑰支援的演算法

 TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246] （MUST SUPPORT）

 TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246] （MUST SUPPORT）

 TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246] ](MAY SUPPORT)

 TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246] ](MAY SUPPORT)

2.5.4 CAPWAP狀態機

CAPWAP狀態機，是被ＷＬＣ和ＡＰ同時使用的。對於每個定義的狀態，只有特定的消息才被允許收發。

因為ＡＰ只會和單個ＷＬＣ通訊，因此只會有一個CAPWAP的狀態機。而ＷＬＣ與ＡＰ有很大差別，因為ＷＬＣ同時和許多ＡＰ通訊。

DTLS和CAPWAP的狀態機由命令和通告的API介面聯繫起來。

DTLS狀態機的變遷由CAPWAP狀態機的命令觸發。

CAPWAP狀態機的變遷由DTLS狀態機的通告觸發

CAPWAP狀態機：

2.5.4.1 CAPWAP to DTLS Commands

 DTLSStart

開啟DTLS會話的建立

 DTLSListen

監聽DTLS會話請求

 DTLSＷＬＣcept

允許DTLS會話建立

 DTLSAbortSession

導致正在進行中的DTLS會話的中斷

 DTLSShutdown

關閉DTLS會話

 DTLSMtuUpdate

改變DTLS模組的MTU設定大小。預設大小為1468位元組

2.5.4.2 DTLS to CAPWAP Notifications

 DTLSPeerAuthorize

DTLS會話建立過程中，通知CAPWAP模組來認證會話。

 DTLSEstablished

通知CAPWAP模組DTLS會話已經成功建立

 DTLSEstablishFail

DTLS會話建立失敗

 DTLSAuthenticateFail

DTLS會話建立過程由於認證失敗而終止。

 DTLSAborted

通知CAPWAP模組它要求的DTLS會話建立過程已經終

 DTLSReassemblyFailure

通知CAPWAP模組DTLS分片組裝失敗

 DTLSDecapFailure

通知CAPWAP模組發生了一個解碼錯誤

 DTLSPeerDisconnect

通知CAPWAP模組DTLS會話已經關閉

2.5.5 ＷＬＣ執行緒

ＷＬＣ使用了三個"執行緒"（thread）的概念。

 監聽執行緒：

通過DTLSlisten命令，ＷＬＣ監聽執行緒DTLS會話建立請求。創建的時候,監聽執行緒開啟DTLS Setup狀態。當狀態機進入Authorize狀態，且DTLS會話生效之後，監聽執行緒創建一個指定的ＡＰ指定會話服務執行緒和狀態空間。

 發現執行緒：

ＷＬＣ的發現執行緒負責接收和回應發現請求消息。

 服務執行緒：

ＷＬＣ的服務進程處理每個ＡＰ的狀態和每個ＡＰ連接的執行緒。這個執行緒在認證後被監聽執行緒創建。一旦創建，服務執行緒會繼承監聽執行緒的一份狀態機空間的拷貝。當與ＡＰ之間的通訊完成後，服務執行緒關閉，所有的資源都會被釋放。

注意，在這裡使用了執行緒這個術語，但是並不代表實現者就必須使用執行緒。這只是一個實現ＷＬＣ狀態機的可用的方法

 

 

2.5.6 CAPWAP狀態機詳解

2.5.6.1 Start to Idle

這個狀態變遷發生在設備初始化完成。

 ＡＰ: 開啟CAPWAP狀態機。

 ＷＬＣ: 開啟CAPWAP狀態機。

2.5.6.2 Idle to Discovery

這個狀態變遷發生是為了支援CAPWAP發現進程。

 ＡＰ:

ＡＰ進入發現狀態是為了優先去傳輸第一個Discovery Request message。在進入這個狀態之前，ＡＰ設置發現DiscoveryInterval timer，將DiscoveryCount counter為0.同時清理以前的發現過程中可能會從ＷＬＣ收到的所有資訊。

 ＷＬＣ：

由發現執行緒執行，且發生在收到一個發現請求資訊的時候。此時，ＷＬＣ需要給這個資訊回應一個Discovery Response message 。

2.5.6.3 Discovery to Discovery

在這個發現狀態，ＡＰ決定連接哪個ＷＬＣ。

 ＡＰ：

這個狀態變遷發生在發現DiscoveryInterval timer觸發的時候。對於這個事件的每次變遷，DiscoveryCount counter會遞增。一旦ＡＰ發送了Discovery Request message，ＡＰ重啟DiscoveryInterval timer。

 ＷＬＣ:

對於ＷＬＣ來說，這個狀態變遷是無效的。

2.5.6.4 Discovery to Idle

當發現過程完畢的時候，ＷＬＣ的發現執行緒將會觸發這個變遷。

 ＡＰ:

對於ＡＰ來說，這個狀態變遷是無效的。

 ＷＬＣ:

這個狀態變遷由ＷＬＣ發現執行緒執行，當發現執行緒傳輸了一個給Discovery Request回送了一個Discovery Response的時候，就會觸發這個過程。

2.5.6.5 Discovery to Sulking

當ＡＰ發現ＷＬＣ失敗的時候會觸發這個狀態變遷。

 ＡＰ:

發生在DiscoveryInterval timer超時的時候。 且此時DiscoveryCount變數等於MaxDiscoveries 。在進入這個狀態之前，ＡＰ必須開啟SilentInterval timer 。當在Sulking狀態的時候，所有收到的CAPWAP協定資訊都會被忽略。

 ＷＬＣ:

對於ＷＬＣ來說，這個狀態變遷是無效的。

2.5.6.6 Sulking to Idle

這個狀態變遷發生在ＡＰ需要重新開機發現過程的時候。

 ＡＰ:

當SilentInterval timer觸發，ＡＰ進入到這個狀態。FailedDTLSSessionCount, DiscoveryCount和FailedDTLSAuthFailCount計數器被清零。

 ＷＬＣ:

對於ＷＬＣ來說，這是一個無效的狀態變遷。

2.5.6.7 Sulking to Sulking

sulking狀態提供安靜時段，最小化DOS攻擊的危險。

 ＡＰ:

在sulking狀態收到的所有來自ＷＬＣ得資訊都會被忽略。

 ＷＬＣ:

對於ＷＬＣ來說，這是一個無效的狀態變遷

2.5.6.8 Idle to DTLS Setup

這個狀態變遷發生在跟對端建立安全的DTLS會話的時候。

 ＡＰ:

ＡＰ通過調用DTLSStart命令來初始化這個狀態變遷，開始與選定ＷＬＣ進行DTLS會話，且開啟WaitDTLS timer。此時，忽略了發現過程，假設ＡＰ有本地配置的ＷＬＣ。

 ＷＬＣ:

從start狀態進入Idle狀態，監聽執行緒自動變遷至DTLS Setup狀態，調用DTLSListen命令，並且開啟WaitDTLS timer。

2.5.6.9 Discovery to DTLS Setup

 ＡＰ:

ＡＰ調用DTLSStart命令來初始化這個變遷，開始與指定ＷＬＣ建立DTLS會話。

 ＷＬＣ：

對於ＷＬＣ來說，這是一個無效的狀態變遷。

2.5.6.10 DTLS Setup to Idle

當DTLS連接失敗的時候發生這個狀態變遷。

 ＡＰ:

此時ＡＰ接收到DTLSEstablishFail通知，並且FailedDTLSSessionCount或者FailedDTLSAuthFailCount counter 沒有達到MaxFailedDTLSSessionRetry值。這個錯誤通知終止了DTLS會話的建立。當接收到這個通知，FailedDTLSSessionCount計時器會遞增。

這個狀態變遷也會發生在WaitDTLS timer超時的情況下。

 ＷＬＣ：

對於ＷＬＣ來說，這是一個無效的狀態變遷。

2.5.6.11 DTLS Setup to Sulking

當重複嘗試建立DTLS連接失敗的時候，會發生此狀態變遷。

 ＡＰ:

當FailedDTLSSessionCount或者FailedDTLSAuthFailCount到達最大值MaxFailedDTLSSessionRetry的時候，ＡＰ進入此狀態變遷。進入這個狀態，ＡＰ必須開啟SilentInterval計時器，且所有接收到的CAPWAP和DTLS協議資訊將會被忽略。

 ＷＬＣ：

對於ＷＬＣ來說，這是一個無效的狀態變遷。

2.5.6.12 DTLS Setup to DTLS Setup

當DTLS會話建立失敗的時候會發生這個狀態變遷。

 ＡＰ：

對於ＡＰ來說，這是一個無效的狀態變遷

 ＷＬＣ：

當接收到一個來自DTLS的DTLSEstablishFail通知，ＷＬＣ監聽執行緒初始化這個狀態變遷。當收到這個通告，FailedDTLSSession Count會遞增，監聽執行緒然後調用DTLSListen命令。

2.5.6.13 DTLS Setup to Authorize

這個狀態變遷發生在當一個正在建立DTLS會話需要認證才能繼續進行的時候。

 ＡＰ:

當ＡＰ接收到DTLSPeerAuthorize通告的時候，開始這個狀態變遷。在進入這個狀態之前，ＡＰ對ＷＬＣ的證書執行一個認證檢查。

 ＷＬＣ:

當DTLS模組初始化DTLSPeerAuthorize通告的時候，ＷＬＣ監聽執行緒這個狀態變遷。監聽執行緒fork一個服務執行緒和一個狀態機內容的拷貝，然後，服務執行緒會對ＡＰ證書執行認證。

2.5.6.14 Authorize to DTLS Setup

當監聽執行緒對新進入的會話開始監聽的時候，發生這個狀態變遷。

 ＡＰ:

對於ＡＰ來說，這是個無效的狀態變遷

 ＷＬＣ：

當ＷＬＣ監聽執行緒創建ＡＰ內容空間和服務執行緒後，發生這個狀態變遷。監聽執行緒然後調用DTLSListen命令。

2.5.6.15 Authorize to DTLS Connect

當通知DTLS棧會話將要建立的時候發生這個狀態變遷。

 ＡＰ：

當ＷＬＣ證書被ＡＰ認證成功的時候，會發生這個狀態變遷。調用DTLSＷＬＣcept命令來完成。

 ＷＬＣ:

當ＡＰ證書成功通過ＷＬＣ認證的時候發生這個狀態變遷。調用DTLSＷＬＣcept來完成。

2.5.6.16 DTLS Connect to DTLS Teardown

當DTLS會話建立失敗的時候發生。

 ＡＰ:

當ＡＰ接收到一個DTLSAborted或者DTLSAuthenticateFail通告，告知這個DTLS會話建立不成功的時候，發生這個狀態變遷。當因為DTLSAuthenticateFail通告發生的狀態變遷，FailedDTLSAuthFailCount會增加，否則，FailedDTLSSessionCount計數器增加。這個狀態變遷也在WaitDTLS 計時器超時的時候發生，此時ＡＰ開啟DTLSSessionDelete計時器。

 ＷＬＣ：

當ＡＰ接收到一個DTLSAborted或者DTLSAuthenticateFail通告，告知這個DTLS會話建立不成功，此時FailedDTLSAuthFailCount和FailedDTLSSessionCount 不等於MaxFailedDTLSSessionRetry的時候，發生這個狀態變遷。 這個狀態變遷也在WaitDTLS計時器超時的時候發生。

2.5.6.17 DTLS Connect to Join

當會話成功建立的時候發生。

 ＡＰ:

當ＡＰ接收到一個DTLSEstablished通告，表明這個DTLS會話成功建立的時候，發生這個狀態變遷。當接收到這個通告FailedDTLSSessionCount計時器被設置為0.ＡＰ進入join狀態，傳輸Join Request給ＷＬＣ。ＡＰ停止WaitDTLS計時器。

 ＷＬＣ：

當ＷＬＣ接收到DTLSEstablished通告，表明這個DTLS會話成功建立的時候，發生這個狀態變遷。當接收到這個通告，FailedDTLSSessionCount計時器被設置為0.ＷＬＣ停止WaitDTLS計時器，開啟WaitJoin計時器。

2.5.6.18 Join to DTLS Teardown

當Join過程失敗的時候發生。

 ＡＰ：

當ＡＰ接收到一個帶有錯誤代碼消息單元的Join回應訊息，或者在Join回應中由ＷＬＣ提供的Image與ＡＰ現在運行的版本不一樣，且ＡＰ的non-volatile memory中有這個請求的版本號.這個導致ＡＰ初始化DTLSShutdown命令。當ＡＰ接收到下面任何一個通告的時候，也會發生這個過程：DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect.ＡＰ開啟DTLSSessionDelete 計時器。

 ＷＬＣ：

發生在WaitJoin超時或者ＷＬＣ傳送了一個帶有錯誤碼的Join Response的時候。ＷＬＣ初始化DTLSShutdown命令。當ＷＬＣ收到下面任何一個DTLS通告的時候，也會發生這個過程：DTLSAborted, DTLSReassemblyFailure, DTLSPeerDisconnect。 此時，ＷＬＣ開啟DTLSSessionDelete計時器。

2.5.6.19 Join to Image Data

ＡＰ和ＷＬＣ下載可執行的firmware時使用這個狀態變遷。

 ＡＰ：

當ＡＰ收到了一個成功的Join Response message，告知它當前運行的版本與要求的不一樣的時候，發生這個狀態變遷。且此時，ＡＰ的non-volatile storage中也沒有要求的image版本。ＡＰ初始化EchoInterval計時器。

 ＷＬＣ：

當ＷＬＣ發送一個Join Response給ＡＰ之後，從ＡＰ接受到一個Image Data Request資訊，發生這個狀態變遷。ＷＬＣ停止WaitJoin計時器，發送一個Image Data Response message給ＡＰ。

2.5.6.20 Join to Configure

ＡＰ和ＷＬＣ使用這個狀態變遷來交換配置資訊。

 ＡＰ：

當ＡＰ收到了一個successful Join Response message，且此時當前運行的版本與要求的一致。ＡＰ發送一個Configuration Status Request message給ＷＬＣ，消息中包含了當前配置資訊。

 ＷＬＣ：

當從ＡＰ接收到Configuration Status Request message，且消息中包含指定消息元素需要覆蓋ＡＰ的配置。ＷＬＣ停止WaitJoin計時器，發送Configuration Status Response message，並且開啟ChangeStatePendingTimer計時器。

2.5.6.21 Configure to Reset

這個狀態變遷被用來重啟連接。這個可能被配置階段發生的錯誤導致，或者是ＡＰ決定它有需要來重啟讓新的配置生效。CAPWAP Reset命令用來告訴對端它將會初始化一個DTLSteardown。

 ＡＰ：

ＡＰ接收到Configuration Status Response message告訴它有錯誤發生或者覺得有需要重新讓新配置生效的時候，ＡＰ進入reset 狀態。

 ＷＬＣ：

ＷＬＣ接收到一個來自ＡＰ的Change State Event message，當這個消息包含了因為ＷＬＣ的策略而不允許ＡＰ提供服務的錯誤的時候，ＷＬＣ變遷到reset狀態。這個狀態變遷也會在ChangeStatePendingTimer計時器超時的時候發生。

2.5.6.22 Authorize to DTLS Teardown

這個狀態變遷為了通知DTLS會話將要終止。

 ＡＰ:

當ＡＰ認證失敗的時候，發生這個狀態變遷。ＡＰ然後調用DTLSAbortSession命令終止這個DTLS會話。這個狀態變遷也會發生在WaitDTLS計時器超時的情況下。ＡＰ開啟DTLSSessionDelete計時器。

 ＷＬＣ:

這個狀態變遷發生在ＷＬＣ認證失敗的時候。ＷＬＣ調用DTLSAbortSession命令終止DTLS會話。這個狀態變遷也會發生在WaitDTLS計時器超時的時候。ＷＬＣ開啟DTLSSessionDelete計時器。

2.5.6.23 Configure to DTLS Teardown

這個變遷發生在因為DTLS錯誤導致的配置過程終止的時候。

 ＡＰ：

當接收到下列任一DTLS通告：DTLSAborted,DTLSReassemblyFailure, 或者 DTLSPeerDisconnect，ＡＰ進入這個狀態。如果它接收到頻繁的DTLSDecapFailure通告，ＡＰ也有可能會終止DTLS會話。此時，ＡＰ開啟DTLSSessionDelete計時器。

 ＷＬＣ：

當接收到下列任一DTLS通告：DTLSAborted,DTLSReassemblyFailure，或者DTLSPeerDisconnect，ＷＬＣ進入這個狀態。如果它接收到頻繁的DTLSDecapFailure通告，ＡＰ也有可能會終止DTLS會話。ＷＬＣ開啟DTLSSessionDelete計時器。

2.5.6.24 Image Data to Image Data

image資料狀態在ＡＰ和ＷＬＣ在firmware下載階段的時候使用。

 ＡＰ：

 當ＡＰ接收到一個表明ＷＬＣ有更多資料要發送的Image Data Response message的時候，ＡＰ進入Image Data state。

 ＡＰ 接收到頻繁的Image Data Requests，此時，它將會重新設置ImageDataStartTimer的時間來保證它接收到下一個來自ＷＬＣ的Image Data Request。

 ＡＰ的EchoInterval 超時的時候，這會導致ＡＰ傳輸一個Echo Request message，並且重新設置它的EchoInterval計時器。

 ＡＰ接收到一個來自ＷＬＣ的Echo Response。

 ＷＬＣ：

 當ＷＬＣ在Image資料狀態下接收到來自ＡＰ的Image Data Response message。

 當ＷＬＣ接收到一個來自ＡＰ的Echo Request。這個會導致ＷＬＣ用一個Echo Response來進行回應，然後重新設置EchoInterval計時器。

2.5.6.25 Image Data to Reset

ＡＰ下載image後重啟，重新設置DTLS連接

 ＡＰ:

 當image的下載完成，或者ImageDataStartTimer計時器超時,ＡＰ進入reset狀態。

 接收到一個來自ＷＬＣ的Image Data Response message消息的時候轉入這個狀態。

 ＷＬＣ：

當image傳輸成功完成，或者在傳輸過程中發生了一個錯誤的時候，ＷＬＣ進入reset狀態。

2.5.6.26 Image Data to DTLS Teardown

當firmware下載過程由於DTLS錯誤而終止時發生

 ＡＰ：

 接收到下麵任一DTLS通告：DTLSAborted,DTLSReassemblyFailure,或者DTLSPeerDisconnect的時候

 收到頻繁的DTLSDecapFailure通告的時候關閉DTLS會話。

此時ＡＰ開啟DTLSSessionDelete計時器。

 ＷＬＣ：

 當ＷＬＣ接收到下麵任一DTLS通告：DTLSAborted,DTLSReassemblyFailure,或者DTLSPeerDisconnect的時候

 收到頻繁的DTLSDecapFailure通告的時候關閉DTLS會話。

此時ＷＬＣ開啟DTLSSessionDelete計時器。

2.5.6.27 Configure to Data Check

當ＡＰ與ＷＬＣ確認配置資訊的時候

 ＡＰ:

從ＷＬＣ接收到一個成功的Configuration Status Response message的時候，ＡＰ轉入Data Check狀態。此時ＡＰ發送一個Change State Event Request message。

 ＷＬＣ：

當ＷＬＣ接收到來自ＡＰ的Change State Event Request message時發生。然後，ＷＬＣ回應一個Change State Event Response message。此時， ＷＬＣ必須開啟DatＷＬＣheckTimer計時器，關閉ChangeStatePendingTimer計時器。

2.5.6.28 Data Check to DTLS Teardown

當ＡＰ沒有完成Data Check 交互的時候。

 ＡＰ：

 當CAPWAP重傳計時器超時，ＡＰ仍沒有接收到Change State Event Response message。

 當RetransmitCount達到MaxRetransmit的時候。

此時，ＡＰ開啟DTLSSessionDelete計時器。

 ＷＬＣ：

當DatＷＬＣheckTimer計時器超時的時候進入這個狀態。

此時，ＷＬＣ開啟DTLSSessionDelete計時器。

2.5.6.29 Data Check to Run

當控制和資料通道建立的時候

 ＡＰ：

條件：當接收到來自ＷＬＣ的成功Change State Event Response message。

動作：ＡＰ初始化一個資料通道，這個資料通道可選擇是否由DTLS加密。開啟DatＷＬＣhannelKeepAlive計時器，發送一個Data Channel Keep-Alive資訊。然後，ＡＰ開啟EchoInterval計時器和DatＷＬＣhannelDeadInterval計時器。

 ＷＬＣ：

條件：當ＷＬＣ接收到Data Channel Keep-Alive資訊，資訊中的session Id與ＡＰ在Join Request中設定的一致。

動作：ＷＬＣ關閉DatＷＬＣheckTimer計時器。注意，如果ＷＬＣ要求資料通道要加密，那麼將會建立一個資料通道的DTLS會話。在接收到Data Channel Keep-Alive資訊之前，ＷＬＣ就會發送一個自己的Data Channel Keep-Alive資訊。

2.5.6.30 Run to DTLS Teardown

當DTLS發生錯誤的時候

 ＡＰ：

條件：

 接收到下面任何一個DTLS通告：DTLSAborted,DTLSReassemblyFailure, 或者DTLSPeerDisconnect。

 接收到頻繁的DTLSDecapFailure通告。

 RetransmitCount達到MaxRetransmit值。

動作：

    開啟DTLSSessionDelete計時器。

ＷＬＣ：

條件：

 接收到下面任何一個DTLS通告：DTLSAborted,DTLSReassemblyFailure, 或者DTLSPeerDisconnect。

 接收到頻繁的DTLSDecapFailure通告。

 RetransmitCount達到MaxRetransmit值。

 EchoInterval計時器觸發。

動作：

開啟DTLSSessionDelete計時器。

2.5.6.31 Run to Run

CAPWAP的常態。

 ＡＰ：

這是ＡＰ常態。在這個狀態中，ＡＰ每次發送一個請求給ＷＬＣ的時候，都會設置EchoInterval計時器。

在這個狀態中可以發生下面的事件：

 Configuration Update：ＡＰ接收到一個Configuration Update Request message。此時，ＡＰ必須回應一個Configuration Update Response。

 Change State Event：ＡＰ接收到一個Change State Event Response，或者ＡＰ需要初始化一個Change State Event Request。

 Echo Request：ＡＰ發送一個Echo Request或者接受到對應的Echo Response。 Clear Config Request：ＡＰ接收到一個Configuration Request，必須產生一個對應的Clear Configuration Response。

 ＡＰ Event：ＡＰ發送一個ＡＰ Event Request，用於發送一些消息給ＷＬＣ。然後，ＡＰ接收到來自ＷＬＣ的ＡＰ Event Response。

 Data Transfer：ＡＰ發送一個Data Transfer Request或者Data Transfer Response給ＷＬＣ。

 Station Configuration Request：ＡＰ接收到一個Station Configuration Request，需要回應一個Station Configuration Response

 ＷＬＣ：

這是ＷＬＣ常態。在這個狀態中，ＷＬＣ每次發送一個請求給ＡＰ的時候，都會設置EchoInterval計時器。

 Configuration Update：ＷＬＣ發送一個Configuration Update Request message給ＡＰ用以更新ＡＰ的配置。然後接收到來自ＡＰ的Configuration Update Response。

 Change State Event：ＷＬＣ接收到一個Change State Event Request，需要回應一個Change State Event Response。

 Echo Request：ＷＬＣ接收到一個Echo Response需要回應一個對應的Echo Request。

 Clear Config Request：ＷＬＣ發送一個Configuration Request給ＡＰ來清理ＡＰ的配置，然後接收到來自ＡＰ的Clear Configuration Response。

 ＡＰ Event：ＷＬＣ接收到一個來自ＡＰ的ＡＰ Event Request，需要回應一個對應的ＡＰ Event Response。

 Data Transfer：ＷＬＣ發送Data Transfer Request或者Data Transfer Response。ＷＬＣ接收到Data Transfer Request或者Data Transfer Response。

 Station Configuration Request：ＷＬＣ發送Station Configuration Request或者接收到Station Configuration Response

2.5.6.32 Run to Reset

當ＷＬＣ或者ＡＰ關閉連接的時候發生。可以有正常操作導致，也可能由錯誤導致。

 ＡＰ:

ＡＰ接收到來自ＷＬＣ的Reset Request

 ＷＬＣ：

ＷＬＣ發送一個Reset Request給ＡＰ。

2.5.6.33 Reset to DTLS Teardown

CAPWAP reset關閉DTLS會話。

 ＡＰ：

條件：ＡＰ發送Reset Response。

動作：ＡＰ不調用DTLSShutdown命令，開啟DTLSSessionDelete計時器。

 ＷＬＣ：

條件：當ＷＬＣ接收到Reset Response。

動作:初始化DTLSShutdown命令，開啟DTLSSessionDelete計時器。

2.5.6.34 DTLS Teardown to Idle

DTLS會話關閉

 ＡＰ：

ＡＰ成功清理控制層DTLS會話所關聯的所有資源，或者DTLSSessionDelete計時器超時。如果存在資料層DTLS會話，那麼也需要關閉，被釋放所有資源。為這個狀態機設置的所有計時器都要被重置。

 ＷＬＣ：

對ＷＬＣ來說是無效狀態。

2.5.6.35 DTLS Teardown to Sulking

重複嘗試建立DTLS連接失敗

 ＡＰ:

條件：當FailedDTLSSessionCount或者FailedDTLSAuthFailCount計時器達到MaxFailedDTLSSessionRetry值

動作：開啟SilentInterval計時器，在Sulking狀態，所有接收到的CAPWAP和DTLS協議資訊都必須忽略

 ＷＬＣ：

對ＷＬＣ來說是無效狀態。

2.5.6.36 DTLS Teardown to Dead

DTLS會話被關閉

 ＡＰ：

對ＡＰ來說是無效狀態

 ＷＬＣ：

ＷＬＣ成功清理控制層DTLS會話所關聯的所有資源，或者DTLSSessionDelete計時器超時。如果存在資料層DTLS會話，那麼也需要關閉，被釋放所有資源。為這個狀態機設置的所有計時器都要被重置。

2.5.7 CAPWAP傳輸機制

ＡＰ和ＷＬＣ之間使用標準的UDP用戶端/伺服器模式來建立通訊。

CAPWAP協定支援UDP和UDP-Lite [RFC3828]。

¢ 在IPv4上，CAPWAP控制和資料通道使用UDP。此時CAPWAP資訊中的UDP校驗和必須設置為0。ＷＬＣ上的CAPWAP控制資訊埠為UDP眾所周知埠5246，資料包文埠為UDP眾所周知埠5247 ，ＡＰ可以隨意選擇CAPWAP控制和資料埠。

¢ 在IPv6上，CAPWAP控制通道一般使用UDP，而資料通道可以使用UDP或者UDP-Lite。UDP-Lite為預設的資料通道傳輸協定。當使用UDP-Lite協定的時候，校驗和必須為8. UDP-Lite使用的埠與UDP一致。

2.5.8 分片、重組、MTU發現

CAPWAP協定在應用層上提供IP資訊的分配和重組服務，由於使用隧道機制，資訊分片中間的傳輸媒介來說是透明的。因此可以在任何網路架構（防火牆，NAT等）上使用CAPWAP協定。

CAPWAP實現的分片機制也有局限和不足，協議RFC4963中詳細描述。

CAPWAP執行MTU發現來避免分片。

一旦ＡＰ發現ＷＬＣ，且想要與這個ＷＬＣ建立一個CAPWAP會話，它必須執行一個Path MTU (PMTU)發現。IPv4的PMTU發現過程在RFC1191中詳細描述。IPv6使用RFC4821。

2.5.9 資訊格式

CAPWAP協定可靠機制要求消息必須成對，由請求和回應組成。所有的請求消息的消息類型值都為奇數，所有的回應訊息類型值都為偶數。

如果ＡＰ或者ＷＬＣ接收到了一個不認識的消息，消息類型是奇數，那麼會將消息類型值加一，然後回應給發送者，並且在回應中帶有"不認識的消息類型"元素。如果不認識的消息類型為偶數，那麼這個消息將會被忽略。

2.5.9.1 UDP-Lite協議的簡單介紹

UDP-Lite協定更加適應於網路的差錯率比較大，但是應用對輕微差錯不敏感的情況，例如即時視頻的播放等。

那麼它與傳統的UDP協議有什麼不同呢？

傳統的UDP協議是對其載荷（Payload）進行完整的校驗的，如果其中的一些位（哪怕只有一位）發生了變化，那麼整個資料包都有可能被丟棄，在某些情況下，丟掉這個包的代價是非常大的，尤其當包比較大的時候。

在UDP-Lite協定中，一個資料包到底需不需要對其載荷進行校驗，或者是校驗多少位都是由用戶控制的，並且UDP-Lite協定就是用UDP協定的Length欄位來表示其Checksum Coverage的，所以當UDP-Lite協議的Checksum Coverage欄位等於整個UDP資料包（包括UDP頭和載荷）的長度時，UDP-Lite產生的包也將和傳統的UDP包一模一樣。事實上，Linux對UDP-Lite協議的支援也是通過在原來的UDP協議的基礎上添加了一個setsockopt選項來實現控制發送和接受的checksum coverage的。

2.5.9.2 CAPWAP資訊的簡單介紹

CAPWAP控制協議包括兩個永遠不會被DTLS保護的消息：Discovery Request和Discovery Response。

資訊格式如下：

其餘的CAPWAP控制協定資訊必須被DTLS協議加密，因此包括一個CAPWAP DTLS Header。

CAPWAP協議對資料包文的DTLS加密是可選的。

CAPWAP頭部格式：

¢ UDP頭：所有的CAPWAP資訊都被封裝在UDP或者UDP-Lite（ipv6）中。

¢ CAPWAP DTLS頭：所有的被DTLS加密的CAPWAP資訊都有該頭部首碼。

¢ DTLS頭：DTLS頭部為CAPWAP的載荷提供認證和加密服務。DTLS在RFC4347中定義。

¢ CAPWAP頭：所有的CAPWAP協議資訊都用同一個頭部，該頭部位於CAPWAP預判碼或者DTLS頭之後。

¢ 無線載荷：包含無線載荷的CAPWAP協議資訊稱為CAPWAP資料包文。CAPWAP協議並沒有對無線載荷的格式做強制要求，而是由無線協議標準決定。

¢ 控制頭：CAPWAP協定包含一個信號元件，稱為CAPWAP控制協議。所有的CAPWAP控制資訊都包含一個控制頭，CAPWAP資料包文則不包含該頭部。

¢ 消息元素：CAPWAP控制資訊包含一個或者多個消息元素，這些跟在元素在控制頭之後。這些消息元素以TLV格式出現（類型/長度/值）

2.5.9.2.1 預判碼

2 種 CAPWAP 首部的前 8 位為預判碼，用於快速判斷此資訊是否經過 DTLS 加密。前 4 位指明 CAPWAP 版本，目前的版本號為 0；後 4 位值為 1 時是 CAPWAP DTLS 首部，值為 0 時是 CAPWAP 首部。

0

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|Version| Type |

2.5.9.2.2 CAPWAP DTLS 首部

標識此資訊經過 DTLS 加密。長度為 32 位，包括 8 位預判碼和 24 位預留碼。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|CAPWAP Preamble| Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.5.9.2.3 CAPWAP 首部

CAPWAP 協議的所有資訊都包含 CAPWAP 首部，在控制通道收到則是控制資訊，在資料通道收到則是資料包文，

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Fragment ID | Frag Offset |Rsvd |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (optional) Radio MAC Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (optional) Wireless Specific Information |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Payload …. |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

資訊各部分組成如下：

(1)CAPWAP Preamble：8 位預判碼。

(2)HLEN：5 位首部長度，指明 CAPWAP 首部的長度。

(3)RID：5 位射頻識別字，指明此資訊的來源射頻。

(4)WBID：5 位無線訊框識別字， 指明無線框架類型， 有 IEEE802.11, IEEE802.16 和 EPCGlobal 3 種。

(5)T：1 位元資料訊框識別字，值為 1 時資料訊框是由 WBID指明的類型，值為 0 時是 IEEE802.3 數據訊框。

(6)F：1 位元分組標誌，值為 1 時此資訊是一個 CAPWAP資訊分組，需要和其他分組重組成完成的資訊。

(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：資料包文是使用者資料，控制資訊則是控制消息，詳細的控制消息定義參見文獻[1]。

2.5.9.3CAPWAP資料包文

CAPWAP資料包文有兩種類型：CAPWAP Data channel Keep-Alive 資訊和Data Payload資訊。CAPWAP Data hannel Keep-Alive資訊用於同步控制和資料通道，維持資料通道的連接。Data Payload資訊用於在ＷＬＣ和ＡＰ之間傳輸使用者資料。

2.5.9.3.1 CAPWAP Data Channel Keep-Alive

該資訊的目的在於保持通道的可用性。當DatＷＬＣhannelKeepAlive計時器到期，ＡＰ發送該資訊，同時設置DatＷＬＣhannelDeadInterval計時器。

在資訊中，除了HELN欄位和K標誌位元，其餘欄位和標誌位元均被置為0。當收到KEEPALIVE資訊，ＷＬＣ將回應一個KEEPALIVE資訊給ＡＰ。

ＡＰ在收到ＷＬＣ回應的KEEPALIVE資訊後，取消DatＷＬＣhannelDeadInterval計時器並且重設DatＷＬＣhannelKeepAlive計時器。然後ＡＰ將KEEPALIVE資訊當做控制消息進行重發。如果在DatＷＬＣhannelDeadInterval計時器到期時仍然沒有收到ＷＬＣ的回應資訊，ＡＰ將刪除DTLS的控制SESSION，如果存在資料SESSION也同時刪除。

KEEPALIVE資訊格式如下所示：

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Message Element Length | Message Element [0..N] …

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

資訊被封裝在CAPWAP資訊的payload欄位中。

Message Element Length: 16bit的長度欄位，最大為65535。

Message Element[0..N]: 攜帶的KEPPALIVE資訊資料，SEESION ID是必須攜帶的。

2.5.9.3.2 Data Payload

CAPWAP Data Payload資訊封裝了需要轉發的使用者資料，裡面可能是802.3訊框也有可能是無線資料訊框，參見3.2章節。

2.5.9.3.3 DTLS資料通道的建立

如果ＷＬＣ和ＡＰ被配置為DTLS隧道傳輸模式，那麼就必須初始化DTLS SESSION。為了避免重新鑒定、認證ＷＬＣ和ＡＰ，DTLS資料通道應該利用TLS SESSION的特徵。

ＷＬＣ DTLS實現不應該在沒有控制通道的情況下初始化資料通道SESSION。

2.5.9.4 CAPWAP控制資訊

CAPWAP控制資訊分為以下幾種類型：

Discovery：發現網路中的ＷＬＣ，ＷＬＣ位置和能力

Join：ＡＰ用於向ＷＬＣ請求服務，ＷＬＣ用於回應ＡＰ

Control Channel Management：維持控制通道

ＡＰ Configuration Management：ＷＬＣ給ＡＰ發送設定檔。

Station Session Management：ＷＬＣ發送station策略給ＡＰ

Device Management Operations:請求和發送firmware給ＡＰ

Binding-Specific CAPWAP Management Messages: ＷＬＣ和ＡＰ用於切換式通訊協定指定的CAPWAP管理資訊。可能交換一個station的連接狀態資訊。

2.5.9.3.1 CAPWAP Discovery Operations

¢ Discovery Request Message

ＡＰ用Discovery Request來自動發現網路中可用的ＷＬＣ，提供自己的基本性能給ＷＬＣ。

¢ Discovery Response Message

ＷＬＣ使用Discovery Response，將自己支援的服務告訴給請求服務的ＡＰ。

¢ Primary Discovery Request Message

ＡＰ發送Primary Discovery Request用於：判斷它首選（或者配置的）的ＷＬＣ是否可用或者執行一個Path MTU Discovery

¢ Primary Discovery Response

ＷＬＣ使用Primary Discovery Response告訴ＡＰ自己當前可用，與支援服務。

當ＡＰ被配置了一個首選的ＷＬＣ，但是現在卻連接在另外一個ＷＬＣ上，此時會發送Primary Discovery Request。因為ＡＰ只有一個CAPWAP狀態機，ＡＰ在run狀態發送Primary Discovery Request，ＷＬＣ不傳輸這個消息

2.5.9.3.2 CAPWAP Join Operations

¢ Join Request

在與ＷＬＣ建立DTLS連接之後，ＡＰ使用Join Request來向一個ＷＬＣ請求服務

¢ Join Response

ＷＬＣ使用Join Response告知ＡＰ是否會向其提供服務

2.5.9.3.3 Control Channel Management

¢ Echo Request

¢ Echo Response

Echo Request和Echo Response用於在控制資訊沒有發送的時候，來顯式的維持控制通道的連接

2.5.9.3.4 ＡＰ Configuration Management

¢ Configuration Status Request

ＡＰ用於發送自己當前的配置給ＷＬＣ

¢ Configuration Status Response

ＷＬＣ提供自己的配置資料給ＡＰ，覆蓋ＡＰ所請求的配置

¢ Configuration Update Request

run狀態的時候，ＷＬＣ發送給ＡＰ用於修改ＡＰ上的配置。

¢ Configuration Update Response

回應Configuration Update Request

¢ Change State Event Request

1：當ＡＰ收到來自ＷＬＣ的Configuration Status Response，ＡＰ使用Change State Event Request來提供ＡＰ radio的當前狀態，確認ＷＬＣ提供的配置已經成功應用

2：在run狀態下，ＡＰ發送Change State Event Request來告訴ＷＬＣ，ＡＰ radio發生了意料之外的改變。

¢ Change State Event Response：

回應Change State Event Request

¢ Clear Configuration Request：

ＷＬＣ用於請求ＡＰ將自己的配置恢復至出廠預設值

¢ Clear Configuration Response

ＡＰ恢復出廠預設值後，發送給ＷＬＣ的確認。

CAPWAP協定提供彈性的ＡＰ配置管理機制,有兩種方法：

1：ＡＰ沒有任何配置，接受ＷＬＣ提供的任何配置

2：ＡＰ保存ＷＬＣ提供的靜態記憶體中的不是預設值的配置資料，然後重啟初始化配置。

2.5.9.3.5 Device Management Operations（可選）

¢ Image Data Request

在ＡＰ和ＷＬＣ之間交換，用於ＡＰ下載一個新的firmware

¢ Image Data Response

回應Image Data Response

¢ Reset Request

要求ＡＰ進行重啟。

¢ Reset Response

回應Reset Request

¢ ＡＰ Event Request

ＡＰ用來發送資訊給ＷＬＣ。ＡＰ Event Request可能是階段性發送，或者是作為一個ＡＰ同步事件的響應。

¢ ＡＰ Event Response

回應ＡＰ Event Request

¢ Data Transfer Request

將ＡＰ上的調試資訊發送給ＷＬＣ

¢ Data Transfer Response

回應 Data Transfer Request

ＡＰ Event Request是ＡＰ發送一些定義好的狀態資訊，如Decryption Error Report，Duplicate IPv4 Address等等，也能用於發送Vendor Specific Payload

Data Transfer Request可以由ＷＬＣ發送，也可以由ＡＰ發送。

2.5.9.3.6 CAPWAP定義的firmware下載過程:

firmware的下載可以發生在image data狀態或者run狀態。CAPWAP協議並沒有提供讓ＷＬＣ來識別是否ＡＰ提供的firmware資訊是否正確，或者ＡＰ是否正確存儲了firmware。

2.5.9.3.7 Station Session Management

¢ Station Configuration Request

ＷＬＣ用於創建，修改，刪除ＡＰ上的staion 會話狀態

¢ Station Configuration Response

回應Station Configuration Request

 

 

 

 

 

 

 

 

 

 

 

 

L3 CAPWAP(Support after 5.2 fireware)

 

UDP src port 1024——ENCRYPTED Control —— UDP dst port 5247

 

UDP src port 1024——ENCAPSULATED DATA—— UDP dst port 5247

 

 

Phase 1 Discovery Phase

 

1. AP　啟動時進行搜尋及探測的程式（Zero-touch 部署）
   LAP 通過不同方式建立關於所有 management interfＷＬＣe ip 位址 的資料庫
   　1.1 本地廣播方式
   1.2 本身所存放的上次成功的WLC IP位址
   (AP Priming 當AP和 WLC　結合時 AP 可乎學到 WLC 的IP 位址及
   在mobility 中WLC 成員的IP位址)
   　1.3 利用DHCP及option 43 提供的位址
   (DHCP　vendor option AP 送出帶有 VENDOR Option的要求,而如DHCP
   Server 有設定回應這些 Option 則在回ＷＬＣK 時會送回Controller的IP
   清單)
   　1.4 DNS 中記錄的CISCO-CAPWAP-CONTROLLER
   (AP可由DHCP Option 獲得 DNS的訊息,並且由訊息內得到Controllers
   的IP 位址,AP將利用這些訊息來進行DNS 查訪
   CISCO-CAPWAP-CONTROLLLER 所對應到的 mgmt. interfＷＬＣe 位址)
   

1. AP 找到 WLC 加入
   2.1 加入 首要控制器,如果它曾經是蓄勢待發的WLC
   2.2 首要Controller 失敗則嘗試 第二而及第三順位蓄勢待發的WLC
   2.3 如沒蓄勢待發的WLC在AP中,則AP將查找 Master Contreoller (主控
   器)
   2.4 如沒有蓄勢待發的WLC及 MASTER CONTRLLER AP 將從所有回應控制
   器中選擇具有最小負載的AP Management 介面
   
2. WLC 送出 WLC 版本程式,及相關參數
   
3. 完成後 AP 開始支援 Wireless Client
   

 

 

 

AP CAPWAP JOIN Message

 

AP get WLC discovery reply

AP & eＷＬＣh Discovered Controller handshake to Create IETF DTLS Tunnel

AP then Determine Which one Controller to Join and send Join message
via created DTLS session

The CAPWAP Join Message request from AP to WLC include
1. Type of Controller (like to Associate)
2. MAC-address of Controller (like to Associate)
3. AP self Hardware and software version
4. AP name
5. The Number & type of radio present on AP

 

The CAPWAP Join response from WLC to AP

1. Request successful (Code 0 )
   
2. Request Failure (Code 1) & may Provide Status Message
   

 

Note CAPWAP using Dynamic PMTU , if error CAPWAP use 576 to Send
Message.

CPWAAP Configuration Phase

 

AP —CAPWAP Configuration Request ——à WLC
list configuration parameter and value of AP

ß——–Configuration Response——–

Configuration setting base on controller
(can over write configuration request &
return configured Command PＷＬＣket,AP received
then evaluated eＷＬＣh configuration element and
implementation those element)