1、 CAPWAP CAPWAP介紹介紹 -wendynie-wendynie CAPWAP概述為什么需要CAPWAPCAPWAP概述CAPWAP協議在IEEE 802.11的CAPWAP binding為什么需要CAPWAP傳統的網絡架構 FAT-AP新的網絡架構 FIT-APFAT-AP與FIT-AP的對比 返回傳統的WLAN網絡 FAT-AP 傳統的WLAN網絡都是為企業或家庭內少量移動用戶的接入而組建的。 組網方式：采用FAT AP+有線交換機的分布式WLAN組網模式，由AP來完成用戶的無線接入、用戶權限認證、用戶安全策略實施，對WLAN網絡設備的管理也是分布式的。 隨著WLAN技術的成熟

2、和應用的普及，大規模WLAN網絡部署越來越多，接入的用戶數和無線設備的規模都在成倍增長，這種傳統的WLAN組網方式在大規模網絡的建設和維護可能遇見下述問題： 大型網絡中FAT-AP的問題 WLAN建網時需要對成百上千的AP進行逐一配置：網管IP地址、SSID和加密認證方式等無線業務參數、信道和發射功率等射頻參數、ACL和QOS等服務策略，很容易因誤配置而造成配置不一致。為了管理AP，需要維護大量AP的IP地址和設備的映射關系，每新增加一批AP設備都需要進行地址關系維護。接入AP的邊緣網絡需要更改VLAN、ACL等配置以適應無線用戶的接入，為了能夠支持用戶的無縫漫游，需要在邊緣網絡上配置所有無線

3、用戶可能使用的VLAN和ACL。察看網絡運行狀況和用戶統計時需要逐一登錄到AP設備才能完成察看。在線更改服務策略和安全策略設定時也需要逐一登錄到AP設備才能完成設定。升級AP軟件無法自動完成，維護人員需要手動逐一對設備進行軟件升級，費時費力AP設備的丟失意味著網絡配置的丟失，在發現設備丟失前，網絡存在入侵隱患，在發現設備丟失后又需要全網重配置。 返回新的WLAN網絡架構 FIT-AP 隨著建網、組網問題的不斷出現，一種全新的WLAN網絡架構-無線控制器+FIT AP集中式WLAN管理模式應運而生。 AC+FIT AP控制架構對設備的功能進行了重新劃分。 其中無線控制器負責無線網絡的接入控制，轉

4、發和統計、AP的配置監控、漫游管理、AP的網管代理、安全控制； FIT AP負責802.11報文的加解密、802.11的PHY功能、接受無線控制器的管理、RF空口的統計等簡單功能。FIT-AP組網通過無線控制器（AC）來管理多個AP，AP和AC間采用隧道協議進行通訊，無線接入報文的處理在AP和AC間分擔實現。 FIT-AP的優點FIT AP的配置保存在無線控制器中，FIT AP啟動時會自動從無線控制器下載合適的設備配置信息FIT AP需要能夠自動獲取IP地址，同時FIT AP需要能夠自動發現可接入的無線控制器，并對無線控制器和FIT AP之間的網絡拓撲不敏感無線控制器支持FIT AP的配置代理

5、和查詢代理，能夠將用戶對FIT AP的配置順利傳達到指定的FIT AP設備，同時可以實時察看FIT AP的狀態和統計信息無線控制器保存FIT AP的最新軟件，并負責FIT AP軟件的自動更新 返回FAT-AP與FIT-AP對比FAT AP的主要特點： FAT AP是與FIT AP相對來講的，FAT AP將WLAN的物理層、用戶數據加密、用戶認證、QOS、網絡管理、漫游技術以及其他應用層的功能集于一身。 FAT AP無線網絡解決方案可由由FAT AP直接在有線網的基礎上構成。 FAT AP設備結構復雜，且難于集中管理。FIT AP的主要特點： FIT AP是相對FAT AP來講的，它是一個只有加

6、密、射頻功能的AP，功能單一，不能獨立工作。 整個FIT AP無線網絡解決方案由無線控制器和FIT AP在有線網的基礎上構成。 FIT AP上“零配置”，所有配置都集中到無線交換機上。這也促成了FIT AP解決方案更加便于集中管理，并由此具有三層漫游、基于用戶下發權限等FAT AP不具備的功能。 返回CAPWAP概述 CAPWAP協議，全稱為Control And Provisioning of Wireless Access Points Protocol Specification. IETF為了解決隧道協議不兼容問題造成的A廠家的AP和B廠家的AC無法進行互通，在2005年成立了CAPW

7、AP工作組以標準化AP和AC間的隧道協議。 CAPWAP協議組成部分 作為隧道協議的一個重要設計目標，它希望能夠承載多種無線接入技術，如802.11和802.16。所以工作組協議包括了兩部分：CAPWAP協議和無線BINDING協議。 CAPWAP協議（RFC5415，2009年4月發布）作為通用隧道協議，完成了AP發現AC等基本協議功能，和具體的無線接入技術無關。 目前工作組只提供了802.11的BINDING協議（RFC5416，2009年4月發布），以支持802.11網絡的配置管理功能。協議的主要功能概述 該協議主要功能包括了：AP自動發現AC，AC對AP進行安全認證，AP從AC獲取軟件

8、映像，AP從AC獲得初始和動態配置等。此外，系統可以支持本地數據轉發和集中數據轉發。 瘦AP架構讓AC具有了對整個WLAN網絡的完整視圖，為無線漫游、無線資源管理等業務功能的實現提供了基礎。 返回CAPWAP協議（RFC 5415）術語Split MAC和Local MAC傳輸層負載分類CAPWAP會話建立過程AC發現機制DTLS握手CAPWAP傳輸機制CAPWAP報文的簡單介紹CAPWAP狀態機 返回術語介紹無線控制器(AC)：網絡實體，在網絡架構的數據層，控制層，管理層或者聯合起來提供WTP到網絡的訪問服務。CAPWAP控制信道：一個雙向信道，由AC的IP地址，WTP的IP地址，AC控制端

9、口，WTP控制端口，傳輸層協議（UDP或者UDP-LITE）定義，在這之上可以收發CAPWAP的控制報文。CAPWAP數據信道：一個雙向信道，由AC的IP地址，WTP的IP地址，AC數據端口，WTP數據端口，傳輸層協議（UDP或者UDP-LITE）定義，在這之上可以收發CAPWAP的數據報文。STATION：一個包含無線接口的設備無線終端WTP：物理或者網絡實體，包含一個射頻天線和無線物理層可以傳輸和接收 STA在無線存取網絡的數據。 返回 RFC5415 RFC5415描述了CAPWAP協議。 CAPWAP協議被定義獨立于第二層，使得AC可以管理WTPs。 傳統的用于管理WTPs的協議一般是

10、通過HTTP或者二層私有規定進行靜態手動配置。 IEEE 802.11 WLAN網絡中，RFC5416中定義的IEEE 802.11 binding就支持CAPWAP協議。 CAPWAP假定網絡是由多個WTPs組成的，通過IP協議和AC進行通信。WTPs可以被看做是AC控制的遠程RF接口。 CAPWAP協議支持兩種模式的操作：Split MAC和Local MAC。Split MAC 在split MAC模式下，所有二層的無線數據和管理幀都會被CAPWAP協議封裝，然后在AC和WTP之間交換。 如下圖中所示，從一個Station收到的無線幀，會被直接封裝，然后轉發給AC。 返回Local MA

11、C 本地轉發模式允許數據幀可以用本地橋或者使用802.3的幀形式用隧道轉發。在這種情況下，二層無線管理幀在WTP本地已經 處理，然后轉發給AC。 下圖顯示了本地轉發模式，Station傳送的無線幀被封裝成802.3數據幀，然后轉發給AC。 返回 返回CAPWAP的負載類型CAPWAP協議傳輸層運輸兩種類型的負載：數據消息 封裝轉發無線幀控制消息 管理WTP和AC之間交換的管理消息CAPWAP數據和控制報文基于不同的UDP端口發送，且可以被分段，因此數據和控制報文可以超過MTU長度 返回CAPWAP會話創建過程CAPWAP會話創建過程 返回AC發現機制 WTP使用AC發現機制來得知哪些AC是可用

12、的，決定最佳的AC來建立CAPWAP連接。 WTP的發現過程是可選的。如果在WTP上靜態配置了AC，那么WTP并不需要完成AC的發現過程。 WTP首先發送一個 Discovery Request message給受限的廣播地址，或者CAPWAP的多播地址(40)，或者是預配置的AC的單播地址。在IPV6網絡中，由于廣播并不存在，因此使用All ACs multicast address (FF0X:0:0:0:0: 0:0:18C)來代替。 當接收到Discovery Request message消息，AC發送一個單播Discovery Response message給W

13、TP。 WTP可以通過Discovery Response message中所帶的AC優先級，支持的CAPWAP binding來選擇與哪個AC建立會話。 除了上面的發現機制，WTP還可以使用DNS或者DHCP來發現AC. 返回DTLS握手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(SHOUL

14、D SUPPORT) TLS_RSA_WITH_AES_256_CBC_SHA RFC5246(MAY SUPPORT) TLS_DHE_RSA_WITH_AES_256_CBC_SHA RFC5246 (MAY SUPPORT) DTLS認證和授權 在RFC4279中定義了多種預共享密鑰的認證方式，CAPWAP中主要關心下面兩種：Pre-Shared Key (PSK) key exchange algorithmDHE_PSK key exchange algorithm 同樣，CAPWAP定義了預共享密鑰支持的算法TLS_PSK_WITH_AES_128_CBC_SHA RFC5246

15、（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) CAPWAP Pre-Provisioning 由此可以看出，WTP和AC之間要建立安全的連接，必須預先配置一些數據。 當使用預共享密鑰，那么就需要在AC與WTP上面配置下面的數據：標識符（Identity）:對端AC或者WTP的標識符。標識符可能就是

16、一個IP地址或者主機名（DNS）。密鑰（Key）:建立DTLS會話所需要的預共享密鑰PSK標識符（PSK Identity）: 與密鑰相關的身份標識（Identity hint）。 當使用證書的時候，需要配置：設備證書（Device Certificate）: 本地設備的證書信任錨（Trust Anchor）: 被信任的根證書鏈（root certificate chain），用于驗證從CAPWAP對端收到的證書。CAPWAP Pre-Provisioning 除了為認證而需要預先提供的數據，CAPWAP還需要配置控制訪問列表（Access Control List）: 控制訪問列表包括了一個

17、或者多個CAPWAP對端的標識符，并提供其相關的規則。這些規則用于決定與那些對端建立連接。 返回 TLS（Transport Layer Security）協議的局限性 TLS是最為廣泛部署的協議，它用來保障網絡安全通信。TLS用來保護Web 通信和email協議（諸如IMAP，POP）。 TLS的主要優勢是它通過向應用層和網絡層之間（即OSI模型中的會話層）插入TLS來保證應用的安全。然而，TLS要求一個可靠的傳輸信道典型的是TCP因此不能用來保證數據報通信的安全。 當部署TLS的時候，大家還沒有充分認識到這個局限性的嚴重程度，因為當時大多數應用運行在TCP之上。即使今天也是這樣。然而情況正

18、在改變。 DTLS協議的出現 在過去幾年中，不斷增長的應用層協議，比如SIP (session initial protocol)，RTP (real time protocol), MGCP (the Media Gateway Control Protocol)，還有許多游戲協議都基于UDP傳輸而設計。 這些應用的設計者面對著許多用來保證安全性的選擇，但卻無法令人滿意。 首先，他們可以使用IPsec。然而，IPsec不適合于Client-Server應用模型，且難以同應用程序結合，因為IPsec運行在系統內核。有很多文獻詳細討論了為什么IPsec為什么不是一個令人滿意的選擇。 其次，他們自

19、己設計一個特有的應用層安全協議。例如，SIP使用了S/MIME的一個變體來保證安全通信。將S/MIME嫁接到SIP中比使用TLS上的TCP版本的SIP變體更費盡。 第三，可以把應用移植到TCP之上，然后使用TLS。不幸的是，許多這樣的應用依賴于UDP語義，當運行在諸如TCP之類的流協議上性能將無法令人接受。 DTLS協議的出現 最為明顯的選擇是設計一個通用的信道安全協議，它可以使用數據報傳輸，就像TCP上的TLS。這樣一個協議可以在用戶空間中實現，這樣便于安裝，但是要足夠靈活和通用，能夠許多面向數據報的應用程序提供安全。盡管認為這個方案將是一個巨大和困難的規劃項目。但是構造一個可以工作的協議相

20、當直接，尤其是有了TLS的起點和IPsec的參考。 因此設計出了這個新的協議，我們稱為 “Datagram TLS “, DTLS是TLS的一個修改版本， 這樣函數能夠運行在數據報通信上。相對于上面的方案，該方法有兩個主要優勢： 首先，既然DTLS非常類似于TLS，可以重用以前的協議架構和實現方法。 其次，既然DTLS向通用安全層提供了相似的接口，就易于調整協議來使用它。TLS的經驗顯示，這種易于調整性是擴大部署的關鍵。DTLS的特點可靠會話建立可靠會話建立 DTLS必須提供一個機制來認證對端，進行可靠密鑰建立、算法協商合參數傳遞。既然DTLS完全運行在不可靠的數據報通信之上，必須實現重傳機制

21、來保證握手信息的可靠傳遞。然而，重傳機制必須簡單和輕量，能夠盡量使得DTLS的可移植。注意，要求創建一個會話意思是DTLS是適合于長期的“面向連接的“協議，而不是類似于DNS的完全無連接。無連接協議最好應用層的對象安全協議提供。 安全服務安全服務 DTLS必須保證數據傳輸的機密性和完整性，能夠檢測出被替代的數據包。 易于部署易于部署 在用戶空間中實現，不依賴于操作系統。 語義語義 借鑒TLS的優點，DTLS的語義應該模仿UDP語義，其借口模仿UDP API。 最小的改動最小的改動 由于TLS已經非常成熟，最小化改動能夠減少引入未知脆弱性的可能性。 返回CAPWAP狀態機 CAPWAP狀態機，是

22、被AC和WTP同時使用的。對于每個定義的狀態，只有特定的消息才被允許收發。 因為WTP只會和單個AC通訊，因此只會有一個CAPWAP的狀態機。而AC與WTP有很大差別，因為AC同時和許多WTP通訊。 DTLS和CAPWAP的狀態機由命令和通告的API接口聯系起來。DTLS狀態機的變遷由CAPWAP狀態機的命令觸發 CAPWAP狀態機的變遷由DTLS狀態機的通告觸發 Sulking StartIdlediscoveryAuthorizeDeadDTLS SetupDTLS ConnectDTLS TDJoinConfigureImage DataData CheckRunReset返回 Star

23、tIdleDTLS SetupdiscoveryAuthorizeSulkingDTLS ConnectDTLS TDDeadJoinConfigureImage DataData CheckRunResetAC線程 AC使用了三個“線程”（thread）的概念。監聽線程： 通過DTLSlisten命令，AC監聽線程處理DTLS會話建立請求。 創建的時候,監聽線程開啟DTLS Setup狀態。當狀態機進入Authorize狀態，且DTLS會話生效之后，監聽線程創建一個指定的WTP指定會話服務線程和狀態空間。發現線程： AC的發現線程負責接收和響應發現請求消息。服務線程： AC的服務進程處理每個

24、WTP的狀態和每個WTP連接的線程。這個線程在認證后被監聽線程創建。一旦創建，服務線程會繼承監聽線程的一份狀態機空間的拷貝。當與WTP之間的通訊完成后，服務線程關閉，所有的資源都會被釋放。 注意，在這里使用了線程這個術語，但是并不代表實現者就必須使用線程。這只是一個實現AC狀態機的可用的方法。Start to Idle 這個狀態變遷發生在設備初始化完成。WTP: 開啟CAPWAP狀態機。 AC: 開啟CAPWAP狀態機。 返回Idle to Discovery 這個狀態變遷發生是為了支持CAPWAP發現進程。 WTP: WTP進入發現狀態是為了優先去傳輸第一個Discovery Request

25、 message。在進入這個狀態之前，WTP設置發現DiscoveryInterval timer，將DiscoveryCount counter為0.同時清理以前的發現過程中可能會從AC收到的所有信息。 AC： 由發現線程執行，且發生在收到一個發現請求報文的時候。此時，AC需要給這個報文響應一個Discovery Response message 。 返回Discovery to Discovery 在這個發現狀態，WTP決定連接哪個AC。 WTP： 這個狀態變遷發生在發現DiscoveryInterval timer觸發的時候。對于這個事件的每次變遷，DiscoveryCount coun

26、ter會遞增。一旦WTP發送了Discovery Request message，WTP重啟DiscoveryInterval timer。 AC: 對于AC來說，這個狀態變遷是無效的。 返回Discovery to Idle 當發現過程完畢的時候，AC的發現線程將會觸發這個變遷。WTP: 對于WTP來說，這個狀態變遷是無效的。AC: 這個狀態變遷由AC發現線程執行，當發現線程傳輸了一個給Discovery Request回送了一個Discovery Response的時候，就會觸發這個過程。 返回Discovery to Sulking 當WTP發現AC失敗的時候會觸發這個狀態變遷。WTP:

27、 發生在DiscoveryInterval timer超時的時候。 且此時DiscoveryCount變量等于MaxDiscoveries 。在進入這個狀態之前，WTP必須開啟SilentInterval timer 。當在Sulking狀態的時候，所有收到的CAPWAP協議報文都會被忽略。 AC: 對于AC來說，這個狀態變遷是無效的。 返回Sulking to Idle 這個狀態變遷發生在WTP需要重新啟動發現過程的時候。WTP: 當SilentInterval timer觸發，WTP進入到這個狀態。FailedDTLSSessionCount, DiscoveryCount和FailedD

28、TLSAuthFailCount計數器被清零。 AC: 對于AC來說，這是一個無效的狀態變遷。 返回Sulking to Sulking sulking狀態提供安靜時段，最小化DOS攻擊的危險。WTP: 在sulking狀態收到的所有來自AC得報文都會被忽略。 AC: 對于AC來說，這是一個無效的狀態變遷 返回Idle to DTLS Setup 這個狀態變遷發生在跟對端建立安全的DTLS會話的時候。WTP: WTP通過調用DTLSStart命令來初始化這個狀態變遷，開始 與選定AC進行DTLS會話，且開啟WaitDTLS timer。此時，旁路了發現過程，假設WTP有本地配置的AC。AC:

29、從start狀態進入Idle狀態，監聽線程自動變遷至DTLS Setup狀態，調用DTLSListen命令，并且開啟WaitDTLS timer。 返回Discovery to DTLS SetupWTP: WTP調用DTLSStart命令來初始化這個變遷，開始與指定AC建立DTLS會話。 AC： 對于AC來說，這是一個無效的狀態變遷。 返回DTLS Setup to Idle 當DTLS連接失敗的時候發生這個狀態變遷。WTP: 此時WTP接收到DTLSEstablishFail通知，并且FailedDTLSSessionCount或者FailedDTLSAuthFailCount count

30、er 沒有達到MaxFailedDTLSSessionRetry值。這個錯誤通知終止了DTLS會話的建立。當接收到這個通知，FailedDTLSSessionCount計時器會遞增。 這個狀態變遷也會發生在WaitDTLS timer超時的情況下。 AC： 對于AC來說，這是一個無效的狀態變遷。 返回DTLS Setup to Sulking 當重復嘗試建立DTLS連接失敗的時候，會發生此狀態變遷。WTP: 當FailedDTLSSessionCount或者FailedDTLSAuthFailCount到達最大值MaxFailedDTLSSessionRetry的時候，WTP進入此狀態變遷。進

31、入這個狀態，WTP必須開啟SilentInterval定時器，且所有接收到的CAPWAP和DTLS協議報文將會被忽略。 AC： 對于AC來說，這是一個無效的狀態變遷。 返回DTLS Setup to DTLS Setup 當DTLS會話建立失敗的時候會發生這個狀態變遷。 WTP： 對于WTP來說，這是一個無效的狀態變遷AC： 當接收到一個來自DTLS的DTLSEstablishFail通知，AC監聽線程初始化這個狀態變遷。當收到這個通告，FailedDTLSSession Count會遞增，監聽線程然后調用DTLSListen命令。 返回DTLS Setup to Authorize 這個狀態

32、變遷發生在當一個正在建立DTLS會話需要認證才能繼續進行的時候。 WTP: 當WTP接收到DTLSPeerAuthorize通告的時候，開始這個狀態變遷。在進入這個狀態之前，WTP對AC的證書執行一個認證檢查。 AC: 當DTLS模塊初始化DTLSPeerAuthorize通告的時候，AC監聽線程處理這個狀態變遷。監聽線程fork一個服務線程和一個狀態機內容的拷貝，然后，服務線程會對WTP證書執行認證。 返回Authorize to DTLS Setup 當監聽線程對新進入的會話開始監聽的時候，發生這個狀態變遷。 WTP: 對于WTP來說，這是個無效的狀態變遷 AC： 當AC監聽線程創建WTP

33、內容空間和服務線程后，發生這個狀態變遷。監聽線程然后調用DTLSListen命令。 返回Authorize to DTLS Connect 當通知DTLS棧會話將要建立的時候發生這個狀態變遷。 WTP： 當AC證書被WTP認證成功的時候，會發生這個狀態變遷。調用DTLSAccept 命令來完成。 AC: 當WTP證書成功通過AC認證的時候發生這個狀態變遷。調用DTLSAccept來完成。 返回DTLS Connect to DTLS Teardown 當DTLS會話建立失敗的時候發生。WTP: 當WTP接收到一個DTLSAborted或者DTLSAuthenticateFail通告，告知這個D

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

35、SSessionRetry的時候，發生這個狀態變遷。 這個狀態變遷也在WaitDTLS定時器超時的時候發生。 返回DTLS Connect to Join 當會話成功建立的時候發生。 WTP: 當WTP接收到一個DTLSEstablished通告，表明這個DTLS會話成功建立的時候，發生這個狀態變遷。當接收到這個通告FailedDTLSSessionCount計時器被設置為0.WTP進入join狀態，傳輸Join Request給AC。WTP停止WaitDTLS定時器。 AC： 當AC接收到DTLSEstablished通告，表明這個DTLS會話成功建立的時候，發生這個狀態變遷。當接收到這個通

36、告，FailedDTLSSessionCount計時器被設置為0.AC停止WaitDTLS定時器，開啟WaitJoin定時器。 返回Join to DTLS Teardown當Join過程失敗的時候發生。WTP： 當WTP接收到一個帶有錯誤代碼消息單元的Join響應消息，或者在Join響應中由AC提供的Image與WTP現在運行的版本不一樣，且WTP的non-volatile memory中有這個請求的版本號.這個導致WTP初始化DTLSShutdown命令。當WTP接收到下面任何一個通告的時候，也會發生這個過程：DTLSAborted, DTLSReassemblyFailure, or D

37、TLSPeerDisconnect.WTP開啟DTLSSessionDelete 定時器。AC： 發生在WaitJoin超時或者AC傳送了一個帶有錯誤碼的Join Response的時候。AC初始化DTLSShutdown命令。當AC收到下面任何一個DTLS通告的時候，也會發生這個過程：DTLSAborted, DTLSReassemblyFailure, DTLSPeerDisconnect。 此時，AC開啟DTLSSessionDelete定時器。 返回 Join to Image Data WTP和AC下載可執行的firmware時使用這個狀態變遷。WTP： 當WTP收到了一個成功的Jo

38、in Response message，告知它當前運行的版本與要求的不一樣的時候，發生這個狀態變遷。且此時，WTP的non-volatile storage中也沒有要求的image版本。WTP初始化EchoInterval計時器。AC： 當AC發送一個Join Response給WTP之后，從WTP接受到一個Image Data Request報文，發生這個狀態變遷。AC停止WaitJoin定時器，發送一個Image Data Response message給WTP。 返回Join to ConfigureWTP和AC使用這個狀態變遷來交換配置信息。WTP： 當WTP收到了一個success

39、ful Join Response message，且此時當前運行的版本與要求的一致。WTP發送一個Configuration Status Request message給AC，消息中包含了當前配置信息。AC： 當從WTP接收到Configuration Status Request message，且消息中包含指定消息元素需要覆蓋WTP的配置。AC停止WaitJoin定時器，發送Configuration Status Response message，并且開啟ChangeStatePendingTimer定時器。 返回Configure to Reset 這個狀態變遷被用來重啟連接。這個

40、可能被配置階段發生的錯誤導致，或者是WTP決定它有需要來重啟讓新的配置生效。CAPWAP Reset命令用來告訴對端它將會初始化一個DTLSteardown。WTP：WTP接收到Configuration Status Response message告訴它有錯誤發生或者覺得有需要重新讓新配置生效的時候，WTP進入reset 狀態。AC： AC接收到一個來自WTP的Change State Event message，當這個消息包含了因為AC的策略而不允許WTP提供服務的錯誤的時候，AC變遷到reset狀態。這個狀態變遷也會在ChangeStatePendingTimer定時器超時的時候發生。

41、 返回Authorize to DTLS Teardown 這個狀態變遷為了通知DTLS會話將要終止。 WTP: 當WTP認證失敗的時候，發生這個狀態變遷。WTP然后調用DTLSAbortSession命令終止這個DTLS會話。這個狀態變遷也會發生在WaitDTLS定時器超時的情況下。WTP開啟DTLSSessionDelete定時器。 AC: 這個狀態變遷發生在AC認證失敗的時候。AC調用DTLSAbortSession命令終止DTLS會話。這個狀態變遷也會發生在WaitDTLS定時器超時的時候。AC開啟DTLSSessionDelete定時器。 返回Configure to DTLS Te

42、ardown 這個變遷發生在因為DTLS錯誤導致的配置過程終止的時候。WTP： 當接收到下列任一DTLS通告：DTLSAborted,DTLSReassemblyFailure, 或者 DTLSPeerDisconnect，WTP進入這個狀態。如果它接收到 頻繁的DTLSDecapFailure通告，WTP也有可能會終止DTLS會話。此時，WTP開啟DTLSSessionDelete定時器。AC： 當接收到下列任一DTLS通告：DTLSAborted,DTLSReassemblyFailure，或者DTLSPeerDisconnect，AC進入這個狀態。如果它接收到 頻繁的DTLSDecapF

43、ailure通告，WTP也有可能會終止DTLS會話。AC開啟DTLSSessionDelete定時器。 返回Image Data to Image Data image數據狀態在WTP和AC在firmware下載階段的時候使用。WTP：當WTP接收到一個表明AC有更多數據要發送的Image Data Response message的時候，WTP進入Image Data state。WTP 接收到頻繁的Image Data Requests，此時，它將會重新設置ImageDataStartTimer的時間來保證它接收到下一個來自AC的Image Data Request。WTP的EchoInt

44、erval 超時的時候，這會導致WTP傳輸一個Echo Request message，并且重新設置它的EchoInterval定時器。WTP接收到一個來自AC的Echo Response。AC：當AC在Image數據狀態下接收到來自WTP的Image Data Response message。當AC接收到一個來自WTP的Echo Request。這個會導致AC用一個Echo Response來進行響應，然后重新設置EchoInterval定時器。 返回Image Data to ResetWTP下載image后重啟，重新設置DTLS連接WTP: 當image的下載完成，或者ImageDat

45、aStartTimer定時器超時,WTP進入reset狀態。 接收到一個來自AC的Image Data Response message消息的時候轉入這個狀態。AC： 當image傳輸成功完成，或者在傳輸過程中發生了一個錯誤的時候，AC進入reset狀態。 返回Image Data to DTLS Teardown 當firmware下載過程由于DTLS錯誤而終止時發生WTP： 接收到下面任一DTLS通告：DTLSAborted,DTLSReassemblyFailure,或者DTLSPeerDisconnect的時候 收到頻繁的DTLSDecapFailure通告的時候關閉DTLS會話。 此

46、時WTP開啟DTLSSessionDelete計時器。AC：當AC接收到下面任一DTLS通告：DTLSAborted,DTLSReassemblyFailure,或者DTLSPeerDisconnect的時候收到頻繁的DTLSDecapFailure通告的時候關閉DTLS會話。 此時AC開啟DTLSSessionDelete計時器。 返回 Configure to Data Check 當WTP與AC確認配置信息的時候WTP: 從AC接收到一個成功的Configuration Status Response message的時候，WTP轉入Data Check狀態。此時WTP發送一個Chang

47、e State Event Request message。AC： 當AC接收到來自WTP的Change State Event Request message時發生。然后，AC回應一個Change State Event Response message。此時， AC必須開啟DataCheckTimer定時器，關閉ChangeStatePendingTimer定時器。 返回Data Check to DTLS Teardown 當WTP沒有完成Data Check 交互的時候。WTP： 當CAPWAP重傳定時器超時，WTP仍沒有接收到Change State Event Response m

48、essage。 當RetransmitCount達到MaxRetransmit的時候。 此時，WTP開啟DTLSSessionDelete定時器。AC： 當DataCheckTimer定時器超時的時候進入這個狀態。 此時，AC開啟DTLSSessionDelete定時器。 返回Data Check to Run 當控制和數據通道建立的時候WTP： 條件條件：當接收到來自AC的成功Change State Event Response message。 動作動作：WTP初始化一個數據通道，這個數據通道可選擇是否由DTLS加密。開啟DataChannelKeepAlive定時器，發送一個Data

49、Channel Keep-Alive報文。然后，WTP開啟EchoInterval定時器和DataChannelDeadInterval定時器。AC： 條件：條件：當AC接收到Data Channel Keep-Alive報文，報文中的session Id與WTP在Join Request中設定的一致。 動作：動作：AC關閉DataCheckTimer定時器。注意，如果AC要求數據通道要加密，那么將會建立一個數據通道的DTLS會話。在接收到Data Channel Keep-Alive報文之前，AC就會發送一個自己的Data Channel Keep-Alive報文。 返回Run to DTL

50、S Teardown 當DTLS發生錯誤的時候WTP：條件條件： 接收到下面任何一個DTLS通告：DTLSAborted,DTLSReassemblyFailure, 或者DTLSPeerDisconnect。 接收到頻繁的DTLSDecapFailure通告。 RetransmitCount達到MaxRetransmit值。 動作動作： 開啟DTLSSessionDelete定時器。AC：條件條件：接收到下面任何一個DTLS通告：DTLSAborted,DTLSReassemblyFailure, 或者DTLSPeerDisconnect。 接收到頻繁的DTLSDecapFailure通告。

51、 RetransmitCount達到MaxRetransmit值。 EchoInterval定時器觸發。 動作動作： 開啟DTLSSessionDelete定時器。 返回Run to RunCAPWAP的常態。WTP： 這是WTP常態。在這個狀態中，WTP每次發送一個請求給AC的時候，都會設置EchoInterval定時器。 在這個狀態中可以發生下面的事件： Configuration Update：WTP接收到一個Configuration Update Request message。此時，WTP必須回應一個Configuration Update Response。 Change Sta

52、te Event：WTP接收到一個Change State Event Response，或者WTP需要初始化一個Change State Event Request。 Echo Request：WTP發送一個Echo Request或者接受到對應的Echo Response。 Clear Config Request：WTP接收到一個Configuration Request，必須產生一個對應的Clear Configuration Response。 WTP Event：WTP發送一個WTP Event Request，用于發送一些消息給AC。然后，WTP接收到來自AC的WTP Event

53、 Response。 Data Transfer：WTP發送一個Data Transfer Request或者Data Transfer Response給AC。 Station Configuration Request：WTP接收到一個Station Configuration Request，需要回應一個Station Configuration ResponseRun to RunAC： 這是AC常態。在這個狀態中，AC每次發送一個請求給WTP的時候，都會設置EchoInterval定時器。 Configuration Update：AC發送一個Configuration Update

54、 Request message給WTP用以更新WTP的配置。然后接收到來自WTP的Configuration Update Response。 Change State Event：AC接收到一個Change State Event Request，需要回應一個Change State Event Response。 Echo Request：AC接收到一個Echo Response需要回應一個對應的Echo Request。 Clear Config Request：AC發送一個Configuration Request給WTP來清理WTP的配置，然后接收到來自WTP的Clear Conf

55、iguration Response。 WTP Event：AC接收到一個來自WTP的WTP Event Request，需要回應一個對應的WTP Event Response。 Data Transfer：AC發送Data Transfer Request或者Data Transfer Response。AC接收到Data Transfer Request或者Data Transfer Response。 Station Configuration Request：AC發送Station Configuration Request或者接收到Station Configuration Resp

56、onse 返回Run to Reset 當AC或者WTP關閉連接的時候發生?？梢杂姓２僮鲗е?，也可能由錯誤導致。WTP: WTP接收到來自AC的Reset RequestAC： AC發送一個Reset Request給WTP。 返回Reset to DTLS Teardown CAPWAP reset關閉DTLS會話。WTP： 條件：WTP發送Reset Response。 動作：WTP不調用DTLSShutdown命令，開啟DTLSSessionDelete定時器。AC： 條件：當AC接收到Reset Response。 動作:初始化DTLSShutdown命令，開啟DTLSSession

57、Delete定時器。 返回DTLS Teardown to Idle DTLS會話關閉WTP： WTP成功清理控制層DTLS會話所關聯的所有資源，或者DTLSSessionDelete定時器超時。如果存在數據層DTLS會話，那么也需要關閉，被釋放所有資源。為這個狀態機設置的所有定時器都要被重置。AC： 對AC來說是無效狀態。 返回 DTLS Teardown to Sulking 重復嘗試建立DTLS連接失敗WTP: 條件：當FailedDTLSSessionCount或者FailedDTLSAuthFailCount計時器達到MaxFailedDTLSSessionRetry值 動作：開啟S

58、ilentInterval定時器，在Sulking狀態，所有接收到的CAPWAP和DTLS協議報文都必須忽略AC： 對AC來說是無效狀態。 返回DTLS Teardown to DeadDTLS會話被關閉WTP： 對WTP來說是無效狀態AC： AC成功清理控制層DTLS會話所關聯的所有資源，或者DTLSSessionDelete定時器超時。如果存在數據層DTLS會話，那么也需要關閉，被釋放所有資源。為這個狀態機設置的所有定時器都要被重置。 返回CAPWAP to DTLS CommandsDTLSStart開啟DTLS會話的建立DTLSListen監聽DTLS會話請求DTLSAccept允許D

59、TLS會話建立DTLSAbortSession導致正在進行中的DTLS會話的中斷DTLSShutdown關閉DTLS會話DTLSMtuUpdate改變DTLS模塊的MTU設定大小。默認大小為1468字節 返回DTLS to CAPWAP NotificationsDTLSPeerAuthorizeDTLS會話建立過程中，通知CAPWAP模塊來認證會話。DTLSEstablished通知CAPWAP模塊DTLS會話已經成功建立DTLSEstablishFailDTLS會話建立失敗DTLSAuthenticateFailDTLS會話建立過程由于認證失敗而終止。DTLSAborted通知CAPWAP

60、模塊它要求的DTLS會話建立過程已經終DTLSReassemblyFailure通知CAPWAP模塊DTLS分片組裝失敗DTLSDecapFailure通知CAPWAP模塊發生了一個解碼錯誤DTLSPeerDisconnect通知CAPWAP模塊DTLS會話已經關閉 返回CAPWAP傳輸機制 WTP和AC之間使用標準的UDP客戶端/服務器模式來建立通訊。 CAPWAP協議支持UDP和UDP-Lite RFC3828。在IPv4上，CAPWAP控制和數據通道使用UDP。此時CAPWAP報文中的UDP校驗和必須設置為0。AC上的CAPWAP控制報文端口為UDP眾所周知端口5246，數據報文端口為U