【正文】 + wireless frames ++ | || | | | ++ | | | || || | | |wireless PHY/ | | CAPWAP | | | | MAC sublayer | | | | ++ ++ ++ STA WTP AC 圖 1: Split MAC 模式下的 CAPWAP 架構(gòu) Local MAC的模式下對(duì)于數(shù)據(jù)幀的操作既可以通過本地橋接的方式，同時(shí)也可以作為 幀格式的形式進(jìn)行操作。 ++wireless frames ++ frames ++ | || || | | | | | | | | || || | | |wireless PHY/ | | CAPWAP | | | | MAC sublayer | | | | ++ ++ ++ STA WTP AC 圖 2: Local MAC 模式下的 CAPWAP 架構(gòu) 為 WTP 提供安全認(rèn)證和管理對(duì)私有解決方案來說是一種傳統(tǒng) 。集中式的管理能夠降低成本，同時(shí)能夠高效的利用網(wǎng)絡(luò)資源。 提供了一種不需要指定某種無線技術(shù)的可擴(kuò)展協(xié)議。 InterAC 和 stationto ACmunication 這些接口都不在本文檔種設(shè)計(jì)。 STA：一種包含無線媒體接入接口的設(shè)備。 DTLS是一種基于 TLS 的協(xié)議。 CAPWAP 的控制包用于 AC 和 WTP之間的管理消息的交換。一旦接受到 Discovery Response 消息，那么 WTP 將選擇發(fā)出響應(yīng)的 AC 去建立起一個(gè)基于 DTLS 的會(huì)話連接。在這個(gè)交互過程種 WTP可能接受到一些預(yù)定義配置。分片后的數(shù)據(jù)包在另外的一端被重新組裝成了原來封裝好的負(fù)載單元。 無線資源綁定的定義 CAPWAP 協(xié)議與 WTP的射頻技術(shù)無關(guān)，而和無線鏈路層協(xié)議有關(guān)。對(duì)于綁定者來說至少應(yīng)該提供： 在 WTP 的 Request 消息中，含有綁定統(tǒng)計(jì)字段的定義。這注解過后的梯形圖將 AC 放在右邊，將 WTP 放在左邊，同時(shí)假定使用證書的方式來進(jìn)行 DTLS的 鑒權(quán)。在 CAPWAP 中使用 DTLS 導(dǎo)致這兩個(gè)原來各自獨(dú)立的兩個(gè)狀態(tài)機(jī)聯(lián)系在了一起。 圖 4: CAPWAP 完整的狀態(tài)機(jī) （此圖存在錯(cuò)誤，參考嵌入式的文件） c a p w a p _ i n t e g r a t e d _ s t a t e _ m a c h i n e _ 1 5 . v s d 如果 WTP 僅僅和單獨(dú)的一個(gè) AC 進(jìn)行通信，那么將構(gòu)成一個(gè)簡(jiǎn)單的 CAPWAP 狀態(tài)機(jī)模型。在執(zhí)行成功后，監(jiān)聽線程將開始 DTLS 的狀態(tài)建立。發(fā)現(xiàn)線程不保存每個(gè) WTP 的指定上下文信息，而只保存一個(gè)當(dāng)前存在狀態(tài)下的 WTP的上下文信息。當(dāng)與 WTP 的通信完成后，業(yè)務(wù)線程終止，同時(shí)所有相關(guān)的資源被釋放。這些交互在 中會(huì)被涉及到。 Idle to Discovery (1) ： 此狀態(tài)遷移主要為了支持 CAPWAP 發(fā)現(xiàn)處理。 AC：當(dāng) Discovery Request 被 AC 接收到， AC 上的 Discovery 線程將執(zhí)行狀態(tài)機(jī)的遷 移。假如 WTP 中配置的是 一個(gè) AC 的列表，則該 WTP 將發(fā)送一條 Discovery Requst 消息到每一個(gè) 未響應(yīng) Discovery Response 的 AC。 AC：這個(gè)狀態(tài)對(duì)于 AC 來說是無效的狀態(tài)， AC 在此狀態(tài)中并無動(dòng)作。 Discovery to Sulking (!)：這個(gè)遷移發(fā)生在 WTP 上，當(dāng) AC 的 Discovery 過程失敗。 AC： AC 在此階段無操作。 AC： AC 在此階段無操作。 AC： AC 在此階段無操作。當(dāng) discovery 階段被繞開，則可以認(rèn)為 WTP 已經(jīng)配置了相關(guān)的 AC。判定與哪個(gè) AC 進(jìn)行連 接成為了 discovery 階段的結(jié)果。 AC： AC 在此狀態(tài)下無操作。當(dāng)處于 Sulking 狀態(tài)的時(shí) 候，所有接收的的 CAPWAP 和 DTLS 協(xié)議的消息包將會(huì)被舍棄。 AC： 當(dāng)接收到一個(gè) DTLSEstablishFail 的通知消息， AC 的 Listener將發(fā)起狀態(tài)的 遷移。 WTP：當(dāng) WTP 接收到 DTLSPeerAuthorize 的通知時(shí)，狀態(tài)發(fā)生遷移。 Authorize to DTLS Setup (6):當(dāng)監(jiān)聽線程被用來監(jiān)聽新的會(huì)話線程的時(shí)候，狀態(tài) 機(jī)發(fā)生遷移。（ 中會(huì)涉及 到） Authorize to DTLS Connect (a): 當(dāng) DTLS 協(xié)議棧接收到會(huì)話建立的通知時(shí)，狀態(tài)機(jī)發(fā) 生遷移。當(dāng)調(diào)用 DTLSAccept 的 DTLS 命令時(shí)候完成。當(dāng) WaitDTLS 定時(shí)器超時(shí)的時(shí)候，也會(huì)發(fā)生此狀態(tài)遷移。 DTLS Connect to DTLS Teardown (c):當(dāng) DTLS 會(huì)話建立失敗時(shí)，狀態(tài)機(jī)遷移到此狀態(tài)。假如 WaitDTLS 定時(shí)器超時(shí)，也會(huì)發(fā)生狀態(tài)的遷移。在這個(gè)過程中 AC 會(huì)啟動(dòng) DTLSSessionDelete 的定時(shí)器。WTP 此時(shí)發(fā)出 Join Request 消息來進(jìn)入 Join 的狀態(tài)，同時(shí) WTP 停止了WailDTLS 的定時(shí)器。 Join to DTLS Teardown (e):當(dāng)加入的處理失敗時(shí)，狀態(tài)機(jī)遷移到此狀態(tài)。同時(shí) WTP 啟動(dòng)了 DTLSSessionDelete 定時(shí)器。同時(shí) AC 啟動(dòng)了 DTLSSessionDelete 定時(shí)器。 WTP 初始化 EchoInterval 定時(shí)器，然后發(fā)送映像文件的數(shù)據(jù)請(qǐng)求消息，來請(qǐng)求啟動(dòng)固件下載。 Join to Configure (g):此狀態(tài)用于 WTP 和 AC 之間交換配置信息。 AC 同時(shí)停止 WaitJoin定時(shí)器。 AC： 當(dāng) AC 收到一個(gè) WTP 發(fā)送的 Change StateEvent 消息包，包中含一個(gè)錯(cuò)誤（ AC 不允許 WTP 提供服務(wù)）。 當(dāng) 頻 繁 的 接 收 到DTLSDecapFailure 通知的時(shí)候， DTLS 會(huì)話可能被終止。 WTP： 當(dāng) WTP 接收到 Image Data Response 消息，消息中指定 AC 還有更多數(shù)據(jù) 要進(jìn)行發(fā)送時(shí)。此時(shí) WTP 發(fā)送 了 Echo Request 消息，同時(shí)重置了 EchoInterval 定時(shí)器。 Image Data to Reset (k):在映像文件被加 載完成后， WTP 重啟，在 DTLS 連接建立之 前，遷移到此狀態(tài)。 Image Data to DTLS Teardown (l)：當(dāng)一個(gè) DTLS 錯(cuò)誤引起固件加載失敗的時(shí)候，遷移 到此狀態(tài)。當(dāng) AC 頻繁收 到 DTLSDecapFailure 通知時(shí)，可能中斷 DTLS 的會(huì)話。 WTP 發(fā)送 Change state Event Request 消息。 Data Check to DTLS Teardown (n):當(dāng) WTP 未完成數(shù)據(jù)交換檢查時(shí)，遷移到此狀態(tài)。 AC：當(dāng) AC 的 DataCheckTimer 定時(shí)器超時(shí)時(shí)，遷移到此狀態(tài)。 WTP：當(dāng) WTP 接收到一個(gè)成功的 Change State Event響應(yīng)消息的時(shí)候 ，遷移到 此狀態(tài)。 這個(gè)消息包里面包含一個(gè)會(huì)話 ID，此 ID和 WTP 在 Join Request消息中的ID 時(shí)匹配的。接收到數(shù)據(jù)保活消息包后， AC 會(huì)發(fā)送自己的數(shù)據(jù)保活消息包。當(dāng)重傳次數(shù)超過 MaxRetransmit 變量的值時(shí)，將遷移到此狀態(tài)。當(dāng)重傳次數(shù)超過 MaxRetransmit 變量的值時(shí)，將遷移到此狀態(tài)。 WTP：這時(shí)一種正常的操作狀態(tài)， WTP 重啟 EchoInterval定時(shí)器每當(dāng) WTP 發(fā)送請(qǐng)求到 AC。 狀態(tài)改變：當(dāng) WTP 接收到一個(gè) Change State Event Response消息時(shí)， 或者主動(dòng)發(fā)起一個(gè) Change State Event Request 消息時(shí)，遷 移到此狀態(tài)。WTP 同時(shí)清除它的配置，恢復(fù)到手動(dòng)缺省的配置狀態(tài)。 WTP 會(huì)收到數(shù)據(jù)傳輸 Request 或者數(shù)據(jù)傳輸響應(yīng)從 AC 那里。接收到任何 WTP 的請(qǐng)求將引起 AC 重啟它 的 EchoInterval 定時(shí)器。 Echo Request： AC 接收得到一個(gè) Echo Request 消息后需要返回一個(gè) Echo Response 消息。 數(shù)據(jù)傳輸： AC 發(fā)送一個(gè) Data Transfer Request 或者一個(gè) Data Transfer Response 消息給 WTP。 Run to Reset (r):當(dāng) AC 和 WTP斷開連接的時(shí)候遷移到此狀態(tài)。 Reset to DTLS Teardown (s):當(dāng) CAPWAP的重啟完成，判決產(chǎn)生 DTLS會(huì)話連接時(shí)， 遷移到此狀態(tài)。 AC：當(dāng) AC 接收到一個(gè) Reset Response 消息時(shí)，遷移到此狀態(tài)。 WTP：當(dāng) WTP成功清除了所有資源和控制面 DTLS 會(huì)話之間的聯(lián)系， 或者 DTLSSessionDelete 定時(shí)器超時(shí)，狀態(tài)機(jī)遷移到此狀態(tài)。在進(jìn)入這種狀態(tài)后， WTP 需要啟動(dòng) SilentInterval 定時(shí)器。 AC：當(dāng) AC 成功清除了所有資源和控制面 DTLS 會(huì)話之間的聯(lián)系， 或者 DTLSSessionDelete 定時(shí)器超時(shí)的 時(shí)候，狀態(tài)機(jī)遷移到此狀態(tài)。 CAPWAP/DTLS 之間的接口 這部分描述了被 capwap中使用的 DTLS 命令。 下面是最小命令 API 的列表： DTLSStart用于發(fā)起 DTLS 會(huì)話。 DTLSAbortSession 用于發(fā)送消息以一個(gè)放棄正在進(jìn)行的會(huì)話。 DTLSMtuUpdate 用來修改 MTU 的大小。當(dāng) DTLS 的會(huì)話建立成功，一旦對(duì)等方的身份被確認(rèn) 后，就會(huì)發(fā)送此消息。當(dāng)接收到這個(gè)通知時(shí)，F(xiàn)ailedDTLSSessionCount 的計(jì)數(shù)被清零。當(dāng)接收到通知后FailedDTLSSessionCount 自增。 DTLSAborted。 DTLSReassemblyFailure 用于發(fā)送到 CAPWAP 組件表明 DTLS 的幀組裝失敗。 DTLSPeerDisconnect發(fā)送到 CAPWAP組件用于表示整個(gè) DTLS會(huì)話已經(jīng)被撤銷。 這部分對(duì) DTLS 模塊和 CAPWAP 模塊之間的交互做了一個(gè)粗略的介紹，基本上它們通過命令（ CAPWAP DTLS）和通知（ DTLSCAPWAP）來進(jìn)行操作交互。因此，超時(shí) DTLS 的握手沒有完成就完全時(shí) CAPWAP 模塊的責(zé)任。（ TLS 的重建連接往往只能建立在相同 IP 地址和端口之間）。在 DTLS握手開始之前， WTP 設(shè)置 WaitDTLS 定時(shí)器。 DTLS 握手錯(cuò)誤 假如 AC 或者 WTP沒有響應(yīng) DTLS 的握手消息，則按照規(guī)定 DTLS 需要重傳。假如雙方通信完全失敗，或者某一方發(fā)送了一個(gè)丟包的 DTLS告警消息，前面所說的情況就會(huì)發(fā)生 （ DTLS 不會(huì)重傳告警消息） 。 如果 DTLS 握手消息超過了最大長(zhǎng)度， DTLS 支持將握手消息分成若