LWAPP トラフィックについての考察
概要
Control and Provisioning of Wireless Access Points(CAPWAP)ワーキンググループに提出されたIETF-RFCドラフトでは、Lightweight Access Point Protocol(LWAPP)が、Wireless Termination Point（アクセスポイント）とAccess Controllers（ワイヤレスLANコントローラ）間の通信ガイドラインを定義するために開発されたプロトコルです。 すべての LWAPP 通信は、次の 2 つのメッセージ タイプのいずれかに分類されます。
-
LWAPP 制御チャネル
-
LWAPP カプセル化データ
LWAPP は、レイヤ 2 またはレイヤ 3 のトランスポート モードで機能します。レイヤ2 LWAPP通信はイーサネットフレームにカプセル化され、0x88BBのEtherType値で識別できます。イーサネットでの信頼性のため、レイヤ 2 LWAPP モードの動作はルーティングが不可能であり、WLC と AP との間はレイヤ 2 での直接の相互視認性が必要です。レイヤ 2 は非推奨と見なされており、このトラフィックについての考察で概略を説明するプロトコル統計情報は、レイヤ 3 LWAPP トランスポート モードに基づくものです。レイヤ 3 LWAPP トランスポート モードでは、UDP カプセル化パケット形式による IP ネットワーク上での LWAPP メッセージの交換が指定されています。LWAPP トンネルは、WLC（ap-manager）インターフェイスの IP アドレスと AP の IP アドレスで維持管理されます。このトラフィックについての考察では、LWAPP メッセージがネットワークに与える負荷の実際の量と、標準的な導入での LWAPP の動作の基準について明確に説明しています。
注：LWAPPの仕様については、『LWAPP-IETFドラフト』で詳しく説明しています。
セットアップ
このドキュメントでは、LWAPP の運用に関連する統計情報だけが記載されています。コントローラ間のローミングなど、プロトコル使用で定義されていない機能は、このドキュメントの対象ではありません。さらに、このトラフィックについての考察では LWAPP 動作のレイヤ 3 モードだけを対象としています。
図 1：LWAPP トラフィックについての考察で使用されている構成 
| インターフェイス/デバイス | iSCSIポータルの |
|---|---|
| WLC：管理インターフェイス | 192.168.10.102 |
| WLC：ap-manager インターフェイス | 192.168.10.103 |
| Light-Weight AP | 192.168.10.22 |
このトラフィックについての考察の目的のために、この設定は初期交換と構成の変更ベースラインを確立するアクセス ポイント 1 つだけで構成されています。他の AP は後ほど追加して、AP の数の拡張がワイヤ上のトラフィック量に及ぼす影響を測定できるようにします。
LWAPP 制御チャネル
AP は WLC と通信するときに一時的なポートを使用します。また、WLC で応答に使用するポート番号は、LWAPP データには UDP ポート 12222、LWAPP 制御トラフィックには 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 からはテスト要素による新たな加入要求が送信されます。この全体のペイロードは 1,500 バイトになります。2 回目の加入要求に対しても応答が得られなかった場合、AP からは大きなパケットと小さなパケットが繰り返し送信され続けますが、最終的にはタイム アウトになり、ディスカバリ フェーズが最初から繰り返されます。
加入要求メッセージと応答メッセージのパケット サイズは、記述によって異なりますが、このトラフィックについての考察の目的で AP と WLC（ap-manager インターフェイス）との間で取得されるパケット交換は 3,000 バイトです。
LWAPP の設定
図 4：LWAPP の設定状態と AP のプロビジョニングのパケット フロー 
LWAPP 設定要求と応答は、アクセス ポイントとコントローラとの間で、AP によるサービスを作成、変更（アップデート）、および削除するために交換されます。
一般的には、AP から現在の設定を WLC に送るために設定要求メッセージが送信されます。
設定要求は次の 2 つのシナリオで送信できます。
-
AP がコントローラに加入し、コントローラで設定されているすべての 802.11 設定でプロビジョニングする必要がある場合の初期フェーズ。
-
オンデマンドでの管理に関する変更。たとえば、WLAN パラメータに対する変更など。
LWAPP 設定応答メッセージのタイプは、WLC から AP に対して、AP からの LWAPP 設定要求が受信されたことの確認応答のために送られます。これは、WLC にとって AP から要求された設定を上書きする機会となります。このようなフレームには、特別なメッセージ要素は含まれていません。
AP と WLC（ap-manager インターフェイス）との間の初期交換は、およそ 6,000 バイトです。また、ワンタイムでの設定変更は平均 360 バイトで、AP と WLC の ap-manager インターフェイスそれぞれからの 2 パケットが含まれています。
Radio Resource Management（RRM）
図 5：初期 RRM パケットのフロー 
RRM に関連する情報の交換は、AP がプロビジョニングされる際に行われます。AP と WLC（ap-manager インターフェイス）間での一般的は交換は、およそ 1400 バイトです。RRM に関連する設定変更の際には、AP と WLC の ap-manager インターフェイスとの間で 4 つのパケットが交換されます。この交換の平均は 375 バイトです。
ディスカバリ、加入、設定、実行中のプロセスが含まれる 20 分間のサンプルを取得すると、100 Mbps のセグメントで次のトラフィック統計情報が得られます。
表 1：アクセス ポイントが 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 の交換には 2 つの種類があります。1 つは 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)
2 つ目のパケットはノイズ測定で、統計情報の要求と応答のシーケンスが含まれます。これは、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 の交換に含まれています。詳細は、『Unified Wireless Network における Radio Resource Management（RRM）』を参照してください。
20 分間のサンプルを取得すると、100 Mbps のセグメントでの実行中のパケット交換について、次の値が得られます。
表 2：アクセス ポイントが 1 つの場合の実行中の 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 フレームはフラグメント化されることがあるため、Fragment ID フィールドが含まれています。合計パケット サイズは、オリジナル フレームと IP Fragment を追加するかどうかで決まります。LWAPP ヘッダーでも IP Fragment がカプセル化されることはない点に注意してください。
結論
このトラフィックについての考察から明らかなように、LWAPP の動作によるインフラストラクチャへの大きな帯域幅要件はなく、また一般的な導入では、Cisco Unified Wireless Architecture に対応するためにインフラストラクチャに容量を追加する必要はありません。このトラフィックについての考察のまとめとして、次に示す LWAPP の動作についての要点を覚えておいてください。
-
遅延は重要な考慮事項ですが、このトラフィックについての考察で取り上げているのはスループット上の考慮事項だけです。一般的なガイドラインとして、AP と WLC 間のリンクでは 100 ミリ秒を超えるラウンドトリップ遅延は許容できません。
-
LWAPP の動作には次の 2 つのチャネルがあります。
-
LWAPP データ
-
LWAPP 制御トラフィック
-
-
LWAPP の動作は次の 2 つの大きなカテゴリに分けられます。
-
ワンタイム交換
-
実行中の交換
-
-
初期交換が含まれる 20 分間のサンプルでは、平均的な使用率の統計値は 0.001 % になります。
-
実行中の交換についての 20 分間のサンプルでは、最大使用率の統計値は 0.35 KB/秒になります。
-
LWAPP データ チャネルにより、各 802.11 データ パケットに 6 バイトのヘッダーが追加される。IP Fragment によるオーバーヘッドの付加はありません。
-
次に示す 1 時間のサンプルに、個々のプロトコルとそれぞれの比率を示します。
フィードバック