【正文】 WAP 組件一個安全的通道已經(jīng)建立，可以在 DTLS 初始化的處理過程中使用已經(jīng)提供的參數(shù)。這種失敗可能時由于 本地的錯誤，也可能時通信的對方反對進行會話連接。接收到此消息后 FailedDTLSAuthFailCount 計數(shù)自增。當接收到通知消息的時候， WaitDTLS 定時器停止。此通知消息主要時為了提供多種信息，而不用于導致 CAPWAP 狀態(tài)機的遷移。雖然 DTLS 和 CAPWAP 名以上被稱為兩種實體，但是它們有著十分緊密的聯(lián)系 ，有時甚至在實現(xiàn)上都時相關的。 RFC4347沒有制動多長事件應該繼續(xù)進行重傳。因為數(shù)據(jù)通道需要不同的端口號，在 WTP 上的 DTLS 實現(xiàn)需要提供一個接口來允許 CAPWAP模塊通過不同的端口開重建會話連接。WTP用 DTLSStartde 的指令來請求和一個已經(jīng)選擇好的 AC 進行一個安全的連接。這個通知消息可以使 CAPWAP 模塊遷移到 Idle 狀態(tài)，一旦接收到一個 DTLSEstablished 通知消息，則WaitDTLS 定時器將被去激活。） 如果 WTP 或這 AC 在重傳后依然沒有收到 DTLS 的握手消息， WaitDTLS 定時器會最終超時，同時會話被終止。 AC 日志記錄下失敗，同時把這個消息 看成時一個沒有 cookie 的消息。 如果接收到了錯誤的消息，CAPWAP 組件應該記錄下日志。在重組幀的時候有些潛在的原因會導致錯誤，比方說幀疊加和丟幀。 假如一個 cookie 生效失敗，則可能出現(xiàn)一個 WTP 的錯誤，或者出現(xiàn)一個 DOS 攻擊。 在握手期間， WTP 和 AC 都期待一個握手消息，如果沒有收到握手消息，則重 新傳送消息。然后哦調(diào)用 DTLSStart 或者 DTLSListen 命令，然后 WTP 和 AC 分別設置 WaitDTLS 定時器。 一旦 CAPWAP 利用新的重新加密的幀進行重傳，任何原來的 DTLS 幀的副本都被認為是不可靠的，應該被默默的丟棄。 DTLS 應該支持會話重建。 DTLS 握手處理 DLTS 的握手處理在 RFC4347 中已經(jīng)做了說明。僅當整個會話已經(jīng)被建立后，才有可能收到此消息。 DTLSDecapFailure 可以用于發(fā)送到 CAPWAP 模塊表示解封裝失敗。此通知用于發(fā)送到 CAPWAP 組件表明整個會話 Aort 過程已經(jīng)完成了，當 DLTS 會話的整個會話的 abort過程被確認。 DTLSAuthenticateFail。 WaitDTLS 定時器被停止。這個消息可以用于在基于通信雙方互相信任的前提 下建立連接。 MTU 缺省的大小為 1468 字節(jié)。當 WaitDTLS定時器超時時，也會調(diào)用此接口來發(fā)送命令。在 DTLSStart命令發(fā)送后， WaitDTLS 被啟動。同時還有接收到的一些 DTLS 給 capwap協(xié)議棧發(fā)送的通知消息。數(shù)據(jù)面 DTLS 會話已經(jīng)消失，所有的資源被釋放。當在 Sulking狀態(tài)的時候，所有接收到的 capwap和 dtls 協(xié)議消息都 被忽略。 AC： AC 在此狀態(tài)無操作。 AC發(fā)送 DTLSShutdown 命令。 WTP： 當 WTP 發(fā)送一個 Reset Response 消息時，遷移到此狀態(tài)。重啟的原因可能 是一種正常操作現(xiàn)象，也有可能是由錯誤的條件引起的。 AC 接收到一個 Data Transfer Request 或者 Data Transfer Response 消息從 WTP。 清除配置響應： AC 發(fā)送一個 Clear Configuration Request 消息給 WTP 去清除它的配置。 配置升級： AC 發(fā)送配置升級請求消息給 WTP 去升級它的配置。當收到一個數(shù)據(jù)傳輸?shù)恼埱螅?WTP 傳 送一個數(shù)據(jù)傳輸響應給AC。 WTP 事件： WTP 發(fā)送 WTP Event Request 消息到 AC。 Echo Request： WTP 發(fā)送 Echo Request 消息或者從 AC 那接收到一個 相應的 Echo Response 消息。有許多事件能夠使狀態(tài)機遷移到此狀態(tài)。當 AC 的EchoInterval 定時器超時，也會引起狀態(tài)的遷移。 WTP啟動 DTLSSessionDelete 定時器。 Run to DTLS Teardown (p):當在 DTLS 協(xié)議棧處理中出現(xiàn)錯誤，并引起 DTLS會話中斷 時，將遷移到此狀態(tài)。 AC 去使能 DataCheckTimer 的定時器。 WTP 發(fā)起數(shù)據(jù)通道連接，可能需要建立 DTLS 會話，啟動DataChannelKeepAlive 定時器，在數(shù)據(jù)信道里面 數(shù)據(jù)通道?；钕?。同時 Ac 啟動 DTLSSessionDelete 定時器。 WTP：當 WTP 在定時器超時之前未收到 Change State Response 消息時，遷移 到此狀態(tài)。 AC：當 AC 接收到一個 Change State Event 消息時，遷移到此狀態(tài)。 AC 同時啟動DTLSSessionDelete 定時器。 WTP：當 WTP 接收到下面 DTLS 通知消息中的某一個時，遷移到此狀態(tài)： DTLSAborted、 DTLSReassemblyFailure、 DTLSPeerDisconnect。 WTP：當映像文件加載完成，或者 ImageDataStartTimer 定時器超時， WTP 進 入重啟階段。 當 WTP 從 AC 上接收到一個 Echo Response 的消息時候。 當 WTP 接收到一個并發(fā)的 Image Data Request 消息時。在此狀態(tài)下 WTP 開啟了 DTLSSessionDelete 定時器。當 AC 的 ChangeStatPendingTimer 定時器超 時，也會遷移到此狀態(tài)。 AC 之后發(fā)送 Configuration Status Response 消息，同時開啟 ChangeStatPendingTimer 定時器。 WTP：當成功接收到一個 Join Response 的消息，并且判斷消息里面的 Image Identifier 字段和當前運行的映像文件相同時，遷移到此狀態(tài)。 AC：當 AC 接收到 WTP 發(fā)送的映像數(shù)據(jù)請求消息，然后發(fā)送 join Response 的 消息給 WTP。 Join to Image Data (f):當 WTP 和 AC 下載 可執(zhí)行的 firmware 文件時，狀態(tài)機遷移到 此狀態(tài)。 AC： 當 WaitJoin定時器超時，或者 AC 回應的 Join Response 消息中 Result Code 字段中包含錯誤，狀態(tài)機遷移到此狀態(tài)。 WTP：當 WTP接收到的 Join Response消息里面的 Result Code結(jié)果字段是錯誤， 或者 AC 在 Join Response 消息里面提供的映像文件標志位和當前正在運行的固件 firmware 版本不一致，并且和 WTP 所請求的保存在非易失性寄存器中的映像文件不一致的時候，將發(fā)生狀態(tài)的遷移。 AC：當 WTP 接收到一個 DTLSEstablished 的通知，表示 DTLS 會話已經(jīng)被成功 建立起來之后。 DTLS Connect to Join (d):當 DLTS 的會話建立成功，狀態(tài)機遷移至此狀態(tài)。在這個過程中 WTP會啟動 DTLSSessionDelete的定時器。 WTP：當 WTP 接收到 DTLSAborted或者 DTLSAuthenticateFail 兩者之中的某個 通知消息的時候，表明會話連接建立失敗。在這種狀態(tài)時， DTLSSessionDelete定時器被 WTP 啟動。 Authorize to DTLS Teardown (b):DTLS 協(xié)議棧接到會話丟棄的通知消息時，狀態(tài)機發(fā) 生遷移。 WTP： 當 AC 被 WTP 成功鑒權后，狀態(tài)發(fā)生遷移。 WTP： WTP 在此狀態(tài)下無操作。在這種狀 態(tài)下， WTP 作為授權方對 AC 的證書進行認證。失敗的通知消息將導致安全的 DTLS 會話被中斷。 AC： AC 在此狀態(tài)下無操作。 DTLS Setup to Sulking (*): 當反復建立 DTLS 連接失敗時，遷移到此狀態(tài)。 AC： AC 在此階段無操作。 AC： 從初始狀態(tài)遷移到了 Idle 狀態(tài) ，新創(chuàng)建的監(jiān)聽線程自動跳轉(zhuǎn)到 DTLS 的 建立階段，同時調(diào)用 DTLSListen命令，并開啟了 WaitDTLS 的定時器。 Idle to DTLS Setup (3):在對等節(jié)點間建立了一個安全的 DTLS會話后，遷移到此狀態(tài)。 Sulking to Sulking (amp。 Sulking to Idle ():當 WTP 重新開始 Discovery 階段的時候，遷移到此狀態(tài)。 WTP： 當 WTP 上的 DiscoveryInterval 定時器超時，同時 DiscoveryCount 的變量 值超過了最大計數(shù)（計數(shù)最大值在 節(jié)中涉及）。 Discovery to Idle (2)：在 AC 的 Discovery 線程中，當 Discovery 處理完成之后，狀態(tài) 機發(fā)生遷移。每一次狀態(tài)遷移過后， WTP 的 DiscoveryCount 計數(shù)增加。 AC 應該相應一個 Discovery Response 消息。 WTP： WTP 首先進入了 Discovery 狀態(tài)發(fā)送了 第一個 Discovery Request 消息。 Start to Idle (0):此狀態(tài)遷移主要是當設備的初始化完成之后進行。狀態(tài)機的遷移在圖四中用字母順序和標點字符描述。 業(yè)務線程： AC 的業(yè)務線程處理每個 WTP 的連接。一旦 DTLS 會話成功，狀態(tài)機會轉(zhuǎn)換到“ Authorize”的狀態(tài)，監(jiān)聽線程生成了一個 WTP 會話特別業(yè)務線程和相關狀態(tài)的上下文。如 果涉及到多個 AC 和多個 WTP 之間的通信，那么狀態(tài)機將比較復雜。 DTLS 和 CAPWAP 的狀態(tài)機通過一個由命令和通知組成的 API 聯(lián)系在了一起。 CAPWAP 協(xié)議的狀態(tài)機在 節(jié)會被描述。 在 Station Configuration Request 消息中包含配置 station的相關信息。 CAPWAP 的原理是為每一種特殊需求的無線技術提供一種通用的標準。 MTU 的發(fā)現(xiàn)和分片機制將在第三部分種做出說明。然后， WPT被使能。為了建立 DTLS 連接， WTP 需要做相當一部分的準備工作，在 節(jié)將具體講述。 CAPWAP 的數(shù)據(jù)和控制消息包分別 發(fā)往單獨的 UDP 端口。 TLS 的一些和加密相關的協(xié)議機制已經(jīng)被成功應用了多年。 Wirless Termination Point（ WTP）：一種在無線接入網(wǎng)上提供射頻天線和無 線物理器件來和 station 進行通信的物理或網(wǎng)絡實體。 術語 接入控制（ AC）：在網(wǎng)絡架構的數(shù)據(jù)面、控制面和管理面中提供 WTP接入的一種網(wǎng) 絡實體。通過一類封裝和傳輸?shù)臓顟B(tài)機可擴展性得到了保證。將整個無線網(wǎng)絡看做是以個無線的局域網(wǎng)一樣進行管理。允許網(wǎng)絡的操作人員能夠更加緊密的控制和管理整個網(wǎng)絡 。第二種模式下，意味著 WTP 將會起到 的綜合作用。 CAPWAP 協(xié)議支持兩種模式：Split mac 和 Loacl mac。 WPT 需要一組動態(tài)的管理和控制的功能來滿足它們和無線媒介直接的初始連結(jié)。 介紹 協(xié)議預覽 CAPWAP 傳輸 CAPWAP 包格式 CAPwap的發(fā)現(xiàn)操作 CAPWAP 加入操作 控制信道管理 WTP 配置管理 設備管理操作 基站會話管理 1 NAT 協(xié)議描述 1 安全描述 1 操作描述 1 傳輸描述 1 IANA（ 國際因特網(wǎng)地址分配委員會 ）描述 一、 介紹 文檔描述了 CAPWAP 協(xié)議，一種標準，一種可操作的協(xié)議。摘要： 此協(xié)議是關于無線控制和保護協(xié)議（ capwap）協(xié)議的相關規(guī)范。此文檔用于描述基本 CAPWAP 協(xié)議，當分別綁定不同的擴展時，將可以用于多種無線技術。 在 WLAN 架構下， 規(guī)定的簡單 WTP 被一個 AC 控制的這種模式，被認為是一種標準的，操作性十分強的并能從根本上簡化無線網(wǎng)絡之間的管理和調(diào)度的工作 模式。 AC 將 WTP 被看做是一種射頻的接口。 +