LWAPP流量研究
簡介
IETF-RFC草案提交給無線接入點的控制和調配(CAPWAP)工作組，其中描述了輕量接入點協定(LWAPP)，該協定旨在定義無線終端點（接入點）和接入控制器（無線LAN控制器）之間的通訊准則。 所有LWAPP通訊可分為以下兩種消息型別之一：
-
LWAPP控制通道
-
LWAPP封裝的資料
LWAPP可以在第2層或第3層傳輸模式下工作。第2層LWAPP通訊封裝在乙太網幀中，可以使用EtherType值0x88BB標識。由於乙太網上的可靠性，第2層LWAPP操作模式不可路由，因此需要在WLC和AP之間實現第2層可見性。第2層被視為已棄用，本流量研究概述的協定統計資訊基於第3層LWAPP傳輸模式。第3層LWAPP傳輸模式指定在IP網路上以UDP封裝資料包的形式交換LWAPP消息。使用WLC(ap-manager)介面的IP地址和AP的IP地址維護LWAPP隧道。此流量研究揭示了LWAPP消息在網路上存在的實際開銷量以及在標準安裝中的LWAPP操作的基準。
注意：LWAPP規範在LWAPP-IETF草案中進行了詳細的討論。
設定
本文檔提供僅與LWAPP操作相關的統計資訊，並且協定規範未定義的任何功能（如控制器間漫遊）均不屬於本文檔的範圍。此外，流量研究僅涵蓋LWAPP操作的第3層模式。
圖1:LWAPP流量研究設定 
| 介面/裝置 | IP 位址 |
|---|---|
| WLC — 管理介面 | 192.168.10.102 |
| WLC - ap-manager介面 | 192.168.10.103 |
| 輕量AP | 192.168.10.22 |
出於本流量研究的目的，建立設定時只採用一個接入點，以建立初始交換和配置更改基準。後來新增了更多AP，以確定擴展AP數量對線路上生成的流量產生的影響。
LWAPP控制通道
AP在與WLC通話時使用臨時埠。而WLC使用的連線埠號碼則分別是用於LWAPP資料流量和LWAPP控制流量的UDP連線埠12222和UDP連線埠12223。LWAPP控制幀通過LWAPP的報頭標誌欄位中的「C」位與LWAPP資料幀區分。如果設定為1，則它是控制幀。
初始/一次性交換
LWAPP發現（請求和響應）
圖2:LWAPP發現請求和響應資料包流 
接入點傳送的LWAPP發現請求用於確定網路中存在哪些WLC。
發現請求資料包為97位元組，其中包括4位元組的FCS。發現響應資料包為106位元組，其中包括4位元組的FCS。
LWAPP加入（請求和響應）
圖3:LWAPP加入請求和響應資料包流 
存取點使用LWAPP加入請求封包，以通知WLC其希望透過控制器為使用者端提供服務。加入請求階段也用於發現傳輸支援的MTU。接入點傳送的初始加入請求始終以1596位元組的測試元素填充。根據AP和控制器之間的傳輸設定，這些加入請求幀也可以分段。如果接收到初始請求的加入響應，則AP轉發幀而不進行任何分段。加入響應還啟動心跳計時器（30秒值），當心跳計時器過期時，將刪除WLC-AP會話。收到回應請求或確認後，計時器將刷新。
如果初始加入請求沒有產生任何響應，則AP會發出另一個包含測試元素的加入請求，這會使總負載達到1500位元組。如果第二個加入請求也沒有得到響應，則AP將繼續在大小資料包之間循環，並最終超時以從發現階段重新開始。
加入請求和響應消息的資料包大小根據說明而異，但出於本流量研究的目的，在AP和WLC（ap-manager介面）之間捕獲的資料包交換為3,000位元組。
LWAPP配置
圖4:LWAPP配置狀態和AP調配資料包流 
LWAPP配置請求和響應在接入點和控制器之間交換，以便建立、更改（更新）或刪除AP提供的服務。
一般來說，AP會傳送設定要求訊息，以將其目前的組態傳送至其WLC。
可在兩種情況下傳送配置請求：
-
在AP加入控制器的初始階段，需要配置控制器上配置的所有802.11設定。
-
在按需進行管理更改（例如更改WLAN引數）的情況下
WLC將LWAPP配置響應消息型別傳送到AP，以確認從AP收到LWAPP配置請求。這為WLC提供覆寫AP請求的配置的機會。此類幀不包含任何特殊消息元素。
AP和WLC（ap-manager介面）之間的初始交換大約為6,000位元組，一次性配置更改平均為360位元組，其中每個涉及來自AP和WLC的ap-manager介面的2個資料包。
無線電資源管理(RRM)
圖5:初始RRM資料包流 
一旦AP調配，就會發生與RRM相關的資訊交換。AP和WLC（ap-manager介面）之間的典型交換大約為1400位元組。在與RRM相關的配置發生更改的情況下，AP與WLC的ap-manager介面之間會進行四資料包交換。此交換平均為375位元組。
一個20分鐘的示例捕獲（包括發現、加入、配置和正在進行的進程）在100 Mbps網段上產生了以下流量統計資訊：
表 1：單個接入點的初始LWAPP流量統計資訊| 統計 | 價值 |
|---|---|
| 總位元組數 | 84,869 |
| 平均利用率（百分比） | 0.001 |
| 平均利用率（千位元/秒） | 0.425 |
| 最大利用率（百分比） | 0.004 |
| 最大利用率（千位元/秒） | 5.384 |
圖6是整個過程的圖形表示。
圖6:在AP發現、加入和調配階段進行協定比較 
持續交流
心跳
LWAPP架構提供心跳計時器，該心跳計時器由一系列回應請求和回應響應完成。AP定期傳送回應要求以確定AP和WLC之間的連線狀態。作為回應，WLC傳送回應回應，以確認收到回應請求。然後，AP將心跳計時器重置為EchoInterval。LWAPP協定規範草案包含這些計時器的詳細說明。系統心跳與回退機制相結合，每30秒產生4個資料包，由以下資料包組成：
LWAPP ECHO_REQUEST from AP (78 bytes) LWAPP Echo-Response to AP (64 bytes) LWAPP PRIMARY_DISCOVERY_REQ from AP (93 bytes) LWAPP Primary Discovery-Response to AP (97 bytes)
此交換每30秒生成33位元組的流量。
RRM測量
存在兩個正在進行的RRM交換。第一個資料包（每60秒一次）是負載和訊號測量，由4個資料包組成。此交換總共有396位元組：
LWAPP RRM_DATA_REQ from AP (107 bytes) LWAPP Airewave-Director-Data Response to AP (64 bytes) LWAPP RRM_DATA_REQ from AP (161 bytes) LWAPP Airewave-Director-Data Response to AP (64 bytes)
第二個資料包序列是雜訊測量，包括統計資訊請求和響應序列。每180秒完成一次。此封包交換平均大約為2,660位元組，通常持續0.01秒。包含以下封包：
LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP STATISTICS_INFO from AP LWAPP Statistics-Info Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP 00:14:1b:59:41:80 LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP STATISTICS_INFO from AP LWAPP Statistics-Info Response to AP
非法測量
作為掃描機制的一部分執行惡意測量，並且每180秒包括在RRM交換中。有關詳細資訊，請參閱統一無線網路下的無線電資源管理。
20分鐘的捕獲示例產生以下值，用於100 Mbps網段上的持續資料包交換：
表 2：單個接入點的持續LWAPP流量統計資訊| 統計 | 價值 |
|---|---|
| 總位元組數 | 45,805 |
| 平均利用率（百分比） | < 0.001 |
| 平均利用率（千位元/秒） | 0.35 |
| 最大利用率（百分比） | < 0.001 |
| 最大利用率（千位元/秒） | 0.002 |
表2中的統計資料和交換資訊如下圖所示：
圖7:當AP正常工作時，20分鐘的協定比較示例 
LWAPP資料
框架填充
LWAPP資料幀頭為現有的802.11資料包增加了6個位元組。此報頭在封裝的802.11幀之前新增，包括以下內容：
Light Weight Access Point Protocol [0-40]
Flags: %00000000 [42-48]
00.. .... Version: 0
..00 0... Radio ID: 0
.... .0.. C Bit - Data message [0-29]
.... ..0. F Bit - Fragmented packet [0-34]
.... ...0 L Bit - Last fragment [0-30]
Fragment ID: 0x00 [43-55]
Length: 74 [44-52]
Rec Sig Strngth Indic:183 dBm [46-77]
Signal to Noise Ratio:25 dB [47-76]
分段
由於可以對LWAPP幀進行分段，因此包括一個「分段ID」欄位。如果新增原始幀和IP分段，可以確定資料包的總大小。必須注意的是，IP片段並未封裝在任何LWAPP標頭中。
結論
如本流量研究的發現所示，LWAPP的運行不會給基礎設施帶來繁重的頻寬要求，在大多數典型部署中，無需為基礎設施新增額外的容量來適應思科統一無線架構。作為流量研究的摘要，您可以記住以下有關LWAPP操作的簡略事實：
-
雖然延遲是一個重要的考慮因素，但此流量研究僅演示吞吐量考慮因素。一般來說，AP到WLC鏈路的往返延遲不得超過100ms。
-
LWAPP的運作有兩個獨立的管道：
-
LWAPP資料
-
LWAPP控制流量
-
-
LWAPP操作分為兩大類：
-
一次性交換
-
進行中的交換
-
-
包含初始交換的20分鐘樣本平均利用率統計為0.001%。
-
對正在進行的交換進行20分鐘的取樣，得到的最大利用率統計值為0.35千位元/秒。
-
LWAPP資料通道為每個802.11資料包新增一個6位元組的報頭。IP片段沒有額外負荷。
-
一個小時長的示例顯示了協定的細分及其各自百分比：
意見