【導(dǎo)讀】此協(xié)議是關(guān)于無線控制和保護(hù)協(xié)議協(xié)議的相關(guān)規(guī)范。作組在RFC4564文檔里規(guī)定的相關(guān)細(xì)節(jié)。CAPWAP協(xié)議被制定成一種靈活的，允許應(yīng)用在多。此文檔用于描述基本CAPWAP協(xié)議，當(dāng)分別綁定不同的擴(kuò)。展時，將可以用于多種無線技術(shù)。此協(xié)議規(guī)定了某個AC. WPT需要一組動態(tài)的管理和控制的功能來滿足它們和無線媒介直接的初始連結(jié)。以往對于WTP的管理是通過HTTP、層2私有配置來手動靜態(tài)配置的。IP協(xié)議進(jìn)行通信。AC將WTP被看做是一種射頻的接口。在splitmac模式下層二的無線數(shù)據(jù)和管理幀被CAPWAP的協(xié)議。封裝，在AC和WTP之間進(jìn)行數(shù)據(jù)交換。線幀到WTP，這種無線的幀直接在WTP封裝完后發(fā)送到AC。為幀格式的形式進(jìn)行操作。為WTP提供安全認(rèn)證和管理對私有解決方案來說是一種傳統(tǒng)。同時，這種可擴(kuò)展的特性使CAPWAP協(xié)議能夠在未來。CAPWAP協(xié)議傳輸層支持兩種類型的負(fù)載，CAPWAP數(shù)據(jù)包和控制消息包。一旦接受到DiscoveryResponse消息，那么WTP將選擇。發(fā)出響應(yīng)的AC去建立起一個基于DTLS的會話連接。MTU的發(fā)現(xiàn)和分片機(jī)制將在第三部分種做出說明。

　　

【正文】 從 WTP 接收到一個 WTP Event Request 消息后，產(chǎn) 生了一個響應(yīng)的 WTP Event Response 消息。 數(shù)據(jù)傳輸： AC 發(fā)送一個 Data Transfer Request 或者一個 Data Transfer Response 消息給 WTP。 AC 接收到一個 Data Transfer Request 或者 Data Transfer Response 消息從 WTP。只要接 收到一個數(shù)據(jù)傳輸?shù)恼埱?，那?AC 就要發(fā)送一個數(shù)據(jù)傳 輸?shù)捻憫?yīng)消息。 基站配置請求： AC 發(fā)送基站配置請求消息或者接收到一個響應(yīng)的基 站配置請求消息從 WTP那里。 Run to Reset (r):當(dāng) AC 和 WTP斷開連接的時候遷移到此狀態(tài)。重啟的原因可能 是一種正常操作現(xiàn)象，也有可能是由錯誤的條件引起的。 WTP：當(dāng)接收到一個 Reset Request 消息的時候， WTP 進(jìn)入了重啟的 流程。 AC：當(dāng) AC 發(fā)送一個 Reset Request 消息的時候， AC 進(jìn)入了重啟狀態(tài)。 Reset to DTLS Teardown (s):當(dāng) CAPWAP的重啟完成，判決產(chǎn)生 DTLS會話連接時， 遷移到此狀態(tài)。 WTP： 當(dāng) WTP 發(fā)送一個 Reset Response 消息時，遷移到此狀態(tài)。 WTP 沒有調(diào)用 DTLSShutdown 命令。 WTP 啟動了 DTLSSessionDelete 定時器。 AC：當(dāng) AC 接收到一個 Reset Response 消息時，遷移到此狀態(tài)。 AC發(fā)送 DTLSShutdown 命令。 AC 啟動了 DTLSSessionDelete定時器。 DTLS Teardown to Idle (t):當(dāng) DTLS 會話被切斷時，遷移到此狀態(tài)。 WTP：當(dāng) WTP成功清除了所有資源和控制面 DTLS 會話之間的聯(lián)系， 或者 DTLSSessionDelete 定時器超時，狀態(tài)機(jī)遷移到此狀態(tài)。 AC： AC 在此狀態(tài)無操作。 DTLS Teardown to Sulking (u):當(dāng)重復(fù)嘗試建立 DTLS 連接失敗后，遷移到此狀態(tài)。 WTP： 當(dāng) FailedDTLSSessionCount 或者 FailedDTLSAuthFailCount 的計數(shù) 超過 MaxFailedDTLSSessionRetry 變量的值的時候， WTP進(jìn)入此狀態(tài)。在進(jìn)入這種狀態(tài)后， WTP 需要啟動 SilentInterval 定時器。當(dāng)在 Sulking狀態(tài)的時候，所有接收到的 capwap和 dtls 協(xié)議消息都 被忽略。 DTLS Teardown to Dead (w):當(dāng) DTLS 會話被關(guān)閉的時候，遷移到此狀態(tài)。 WTP：對于 WTP 來說，此狀態(tài)無操作。 AC：當(dāng) AC 成功清除了所有資源和控制面 DTLS 會話之間的聯(lián)系， 或者 DTLSSessionDelete 定時器超時的 時候，狀態(tài)機(jī)遷移到此狀態(tài)。數(shù)據(jù)面 DTLS 會話已經(jīng)消失，所有的資源被釋放。當(dāng)前狀態(tài)機(jī)中的所有定時器都被清除。 AC 的業(yè)務(wù)線程也被終結(jié)。 CAPWAP/DTLS 之間的接口 這部分描述了被 capwap中使用的 DTLS 命令。同時還有接收到的一些 DTLS 給 capwap協(xié)議棧發(fā)送的通知消息。 對 DTLS 的命令 給 CAPWAP 使用的六個命令被 DTLS API 定義。這些命令時抽象的，當(dāng)一個或者多個被調(diào)用時實現(xiàn)。 下面是最小命令 API 的列表： DTLSStart用于發(fā)起 DTLS 會話。在 DTLSStart命令發(fā)送后， WaitDTLS 被啟動。 WTP 發(fā)起 DTLS 會話連接， AC 不發(fā)起。 DTLSListen 用于允許 DTLS 組建接收 DTLS 會話請求。 DTLSAbortSession 用于發(fā)送消息以一個放棄正在進(jìn)行的會話。當(dāng) WaitDTLS定時器超時時，也會調(diào)用此接口來發(fā)送命令。當(dāng)命令被執(zhí)行時，F(xiàn)ailDTLSSessionCount 計數(shù)自增。 DTLSShutdown 用于會話中斷時發(fā)送。 DTLSMtuUpdate 用來修改 MTU 的大小。 MTU 缺省的大小為 1468 字節(jié)。 DTLS 給 CAPWAP 的通知 給 CAPWAP 的 API 在 DTLS 的通知消息中也有定義。 下面時通知的 API 列表： DTLSPeerAuthorize 。當(dāng) DTLS 的會話建立成功，一旦對等方的身份被確認(rèn) 后，就會發(fā)送此消息。這個消息可以用于在基于通信雙方互相信任的前提 下建立連接。一旦認(rèn)證開始 CAPWAP 組件將發(fā)送 DTLSAccept 或者 DTLSAbortSession 命令。 DTLSEstablished用于告訴 CAPWAP 組件一個安全的通道已經(jīng)建立，可以在 DTLS 初始化的處理過程中使用已經(jīng)提供的參數(shù)。當(dāng)接收到這個通知時，F(xiàn)ailedDTLSSessionCount 的計數(shù)被清零。 WaitDTLS 定時器被停止。 DTLSEstablishFail 用于當(dāng) DTLS 會話建立失敗時使用。這種失敗可能時由于 本地的錯誤，也可能時通信的對方反對進(jìn)行會話連接。當(dāng)接收到通知后FailedDTLSSessionCount 自增。 DTLSAuthenticateFail。當(dāng)由于鑒權(quán)失敗導(dǎo)致 DTLS 會話建立失敗時，發(fā)送此 通知消息。接收到此消息后 FailedDTLSAuthFailCount 計數(shù)自增。 DTLSAborted。此通知用于發(fā)送到 CAPWAP 組件表明整個會話 Aort 過程已經(jīng)完成了，當(dāng) DLTS 會話的整個會話的 abort過程被確認(rèn)?；蛘弋?dāng) WaitDTLS定時器超時的時候。當(dāng)接收到通知消息的時候， WaitDTLS 定時器停止。 DTLSReassemblyFailure 用于發(fā)送到 CAPWAP 組件表明 DTLS 的幀組裝失敗。 DTLSDecapFailure 可以用于發(fā)送到 CAPWAP 模塊表示解封裝失敗。DTLSDecapFailure 可以用于發(fā)送到 CAPWAP模塊表示一個加密 /鑒權(quán)過程失敗。此通知消息主要時為了提供多種信息，而不用于導(dǎo)致 CAPWAP 狀態(tài)機(jī)的遷移。 DTLSPeerDisconnect發(fā)送到 CAPWAP組件用于表示整個 DTLS會話已經(jīng)被撤銷。僅當(dāng)整個會話已經(jīng)被建立后，才有可能收到此消息。 CAPWAP 協(xié)議中 DTLS 的使用 DTLS 對 CAPWAP 協(xié)議進(jìn)行了緊密安全的封裝。雖然 DTLS 和 CAPWAP 名以上被稱為兩種實體，但是它們有著十分緊密的聯(lián)系 ，有時甚至在實現(xiàn)上都時相關(guān)的。 這部分對 DTLS 模塊和 CAPWAP 模塊之間的交互做了一個粗略的介紹，基本上它們通過命令（ CAPWAP DTLS）和通知（ DTLSCAPWAP）來進(jìn)行操作交互。 DTLS 握手處理 DLTS 的握手處理在 RFC4347 中已經(jīng)做了說明。 ============ ============ WTP AC ============ ============ ClientHello HelloVerifyRequest (with cookie) ClientHello (with cookie) ServerHello Certificate ServerHelloDone (WTP callout for AC authorization occurs in CAPWAP Auth state) Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished (AC callout for WTP authorization occurs in CAPWAP Auth state) ChangeCipherSpec Finished Figure 5: DTLS 握手 DTLS 按照規(guī)定，自己定義一個經(jīng)驗值來確定重傳次數(shù)。 RFC4347沒有制動多長事件應(yīng)該繼續(xù)進(jìn)行重傳。因此，超時 DTLS 的握手沒有完成就完全時 CAPWAP 模塊的責(zé)任。 DTLS 應(yīng)該支持會話重建。會話重建主要用于 DTLS 會話中的數(shù)據(jù)通道建立。因為數(shù)據(jù)通道需要不同的端口號，在 WTP 上的 DTLS 實現(xiàn)需要提供一個接口來允許 CAPWAP模塊通過不同的端口開重建會話連接。（ TLS 的重建連接往往只能建立在相同 IP 地址和端口之間）。 一旦 CAPWAP 利用新的重新加密的幀進(jìn)行重傳，任何原來的 DTLS 幀的副本都被認(rèn)為是不可靠的，應(yīng)該被默默的丟棄。 DTLS 會話建立 WTP 不是通過 Discovery 處理，就是通過重配置來決定哪個 AC 去進(jìn)行連接建立。WTP用 DTLSStartde 的指令來請求和一個已經(jīng)選擇好的 AC 進(jìn)行一個安全的連接。在 DTLS握手開始之前， WTP 設(shè)置 WaitDTLS 定時器。然后哦調(diào)用 DTLSStart 或者 DTLSListen 命令，然后 WTP 和 AC 分別設(shè)置 WaitDTLS 定時器。如果在超時之前還未收到 DTLSEstablished的通知消息， DTLS 會話將被放棄通過 DTLSAbortSession 的 DTLS 命令。這個通知消息可以使 CAPWAP 模塊遷移到 Idle 狀態(tài)，一旦接收到一個 DTLSEstablished 通知消息，則WaitDTLS 定時器將被去激活。 DTLS 握手錯誤 假如 AC 或者 WTP沒有響應(yīng) DTLS 的握手消息，則按照規(guī)定 DTLS 需要重傳。 在握手期間， WTP 和 AC 都期待一個握手消息，如果沒有收到握手消息，則重 新傳送消息。（所有的 CAPWAP 控制消息都是以 request 和 response 來定義的，同時發(fā)送請求的那一方保證重傳。） 如果 WTP 或這 AC 在重傳后依然沒有收到 DTLS 的握手消息， WaitDTLS 定時器會最終超時，同時會話被終止。假如雙方通信完全失敗，或者某一方發(fā)送了一個丟包的 DTLS告警消息，前面所說的情況就會發(fā)生 （ DTLS 不會重傳告警消息） 。 假如一個 cookie 生效失敗，則可能出現(xiàn)一個 WTP 的錯誤，或者出現(xiàn)一個 DOS 攻擊。因此， AC 資源利用率將被降到最低。 AC 日志記錄下失敗，同時把這個消息 看成時一個沒有 cookie 的消息。 如果 DTLS 握手消息超過了最大長度， DTLS 支持將握手消息分成若干個消息。在重組幀的時候有些潛在的原因會導(dǎo)致錯誤，比方說幀疊加和丟幀。此時 DTLS 組件應(yīng)該發(fā)送一個 DTLSReassemblyFailure 的通知消息給 capwap組件。 如果接收到了錯誤的消息，CAPWAP 組件應(yīng)該記