[要約] RFC 4118は、無線アクセスポイントの制御とプロビジョニングのためのアーキテクチャタクソノミーを提供しています。このRFCの目的は、異なるベンダーのCAPWAP実装を統一的に分類し、相互運用性を向上させることです。
Network Working Group L. Yang
Request for Comments: 4118 Intel Corp.
Category: Informational P. Zerfos
UCLA
E. Sadot
Avaya
June 2005
Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)
ワイヤレスアクセスポイントの制御とプロビジョニングのためのアーキテクチャ分類法（CAPWAP）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.
このドキュメントは、ワイヤレスLAN（WLAN）機能とサービスを分析し、建築エンティティ間でこれらの機能とサービスを配布する際のさまざまなバリアントを説明することにより、市場の既存のIEEE 802.11製品で採用されているアーキテクチャの分類法を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . 3
1.2. CAPWAP Functions . . . . . . . . . . . . . . . . . . . 5
1.3. WLAN Architecture Proliferation . . . . . . . . . . . 6
1.4. Taxonomy Methodology and Document Organization . . . . 8
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. IEEE 802.11 Definitions . . . . . . . . . . . . . . . 9
3.2. Terminology Used in This Document . . . . . . . . . . 11
3.3. Terminology Used Historically but Not Recommended . . 13
4. Autonomous Architecture . . . . . . . . . . . . . . . . . . 13
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Security . . . . . . . . . . . . . . . . . . . . . . . 14
5. Centralized WLAN Architecture . . . . . . . . . . . . . . . 15
5.1. Interconnection between WTPs and ACs . . . . . . . . . 16
5.2. Overview of Three Centralized WLAN Architecture
Variants . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Local MAC . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Split MAC . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Remote MAC . . . . . . . . . . . . . . . . . . . . . . 27
5.6. Comparisons of Local MAC, Split MAC, and Remote MAC. . 27
5.7. Communication Interface between WTPs and ACs . . . . . 29
5.8. Security . . . . . . . . . . . . . . . . . . . . . . . 29
5.8.1. Client Data Security . . . . . . . . . . . . . 30
5.8.2. Security of Control Channel between
the WTP and AC . . . . . . . . . . . . . . . . 30
5.8.3. Physical Security of WTPs and ACs . . . . . . 31
6. Distributed Mesh Architecture . . . . . . . . . . . . . . . 32
6.1. Common Characteristics . . . . . . . . . . . . . . . . 32
6.2. Security . . . . . . . . . . . . . . . . . . . . . . . 33
7. Summary and Conclusions . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. Normative References . . . . . . . . . . . . . . . . . . . . 39
As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale deployment of WLAN networks is highlighting certain technical challenges. As outlined in [2], management, monitoring, and control of large number of Access Points (APs) in the network may prove to be a significant burden for network administration. Distributing and maintaining a consistent configuration throughout the entire set of APs in the WLAN is a difficult task. The shared and dynamic nature of the wireless medium also demands effective coordination among the APs to minimize radio interference and maximize network performance. Network security issues, which have always been a concern in WLANs, present even more challenges in large deployments and new architectures.
IEEE 802.11ワイヤレスLAN（WLAN）テクノロジーが成熟するにつれて、WLANネットワークの大規模な展開は、特定の技術的課題を強調しています。[2]で概説されているように、ネットワーク内の多数のアクセスポイント（AP）の管理、監視、および制御は、ネットワーク管理の重大な負担であることが証明される可能性があります。WLAN内のAPのセット全体に一貫した構成を配布および維持することは、難しい作業です。ワイヤレスメディアの共有と動的な性質は、無線干渉を最小限に抑え、ネットワークパフォーマンスを最大化するために、APS間の効果的な調整を必要とします。WLANで常に懸念事項となっているネットワークセキュリティの問題は、大規模な展開と新しいアーキテクチャでさらに多くの課題を提示しています。
Recently many vendors have begun offering partially proprietary solutions to address some or all of the above mentioned problems. Since interoperable systems allow for a broader choice of solutions, a standardized interoperable solution addressing the aforementioned problems is desirable. As the first step toward establishing interoperability in the market place, this document provides a taxonomy of the architectures employed in existing WLAN products. We hope to provide a cohesive understanding of the market practices for the standard bodies involved (including the IETF and IEEE 802.11). This document may be reviewed and utilized by the IEEE 802.11 Working Group as input in defining the functional architecture of an AP.
最近、多くのベンダーが、上記の問題の一部またはすべてに対処するために、部分的に独自のソリューションを提供し始めました。相互運用可能なシステムはより広範なソリューションを選択できるため、前述の問題に対処する標準化された相互運用可能なソリューションが望ましいです。市場で相互運用性を確立するための最初のステップとして、このドキュメントは、既存のWLAN製品で採用されているアーキテクチャの分類法を提供します。関係する標準機関（IETFおよびIEEE 802.11を含む）の市場慣行についてのまとまりのある理解を提供したいと考えています。このドキュメントは、IEEE 802.11ワーキンググループによって、APの機能アーキテクチャを定義する際の入力としてレビューおよび利用することができます。
The IEEE 802.11 specifications are wireless standards that specify an "over-the-air" interface between a wireless client Station (STA) and an Access Point (AP), and also among wireless clients. 802.11 also describes how mobile devices can associate into a basic service set (BSS). A BSS is identified by a basic service set identifier (BSSID) or name. The WLAN architecture can be considered as a type of 'cell' architecture, in which each cell is the Basic Service Set (BSS), and each BSS is controlled by the AP. When two or more APs are connected via a broadcast layer 2 network and all are using the same SSID, an extended service set (ESS) is created.
IEEE 802.11仕様は、ワイヤレスクライアントステーション（STA）とアクセスポイント（AP）との間の「オーバーエア」インターフェイスを指定するワイヤレス標準、およびワイヤレスクライアントの間でも、ワイヤレスクライアントの間でも、ワイヤレス標準です。802.11は、モバイルデバイスが基本サービスセット（BSS）にどのように関連付けられるかについても説明しています。BSSは、基本的なサービスセット識別子（BSSID）または名前によって識別されます。WLANアーキテクチャは、各セルが基本サービスセット（BSS）であり、各BSSがAPによって制御される「セル」アーキテクチャの一種と見なすことができます。2つ以上のAPがブロードキャストレイヤー2ネットワークを介して接続され、すべてが同じSSIDを使用している場合、拡張サービスセット（ESS）が作成されます。
The architectural component used to interconnect BSSs is the distribution system (DS). An AP is an STA that provides access to the DS by providing DS services, as well as acting as an STA. Another logical architectural component, portal, is introduced to integrate the IEEE 802.11 architecture with a traditional wired LAN. It is possible for one device to offer both the functions of an AP and a portal.
BSSSを相互接続するために使用されるアーキテクチャコンポーネントは、配電システム（DS）です。APは、DSサービスを提供し、STAとして機能することにより、DSへのアクセスを提供するSTAです。別の論理アーキテクチャコンポーネントであるポータルが、IEEE 802.11アーキテクチャを従来の有線LANと統合するために導入されています。1つのデバイスがAPの機能とポータルの両方を提供することができます。
IEEE 802.11 does not specify the details of DS implementations explicitly. Instead, the 802.11 standard defines services that provide functions that the LLC layer requires for sending MAC Service Data Units (MSDUs) between two entities on the network. These services can be classified into two categories: the station service (SS) and the distribution system service (DSS). Both categories of service are used by the IEEE 802.11 MAC sublayer. Station services consist of the following four services:
IEEE 802.11は、DS実装の詳細を明示的に指定していません。代わりに、802.11標準は、LLCレイヤーがネットワーク上の2つのエンティティ間でMacサービスデータユニット（MSDU）を送信するために必要な機能を提供するサービスを定義します。これらのサービスは、ステーションサービス（SS）と流通システムサービス（DSS）の2つのカテゴリに分類できます。両方のサービスのカテゴリは、IEEE 802.11 Mac Sublayerによって使用されます。ステーションサービスは、次の4つのサービスで構成されています。
o Authentication: Establishes the identity of one station as a member of the set of stations that are authorized to associate with one another.
o 認証：互いに関連することが許可されている一連のステーションのメンバーとしての1つのステーションの身元を確立します。
o De-authentication: Voids an existing authentication relationship.
o 免除免除：既存の認証関係を無効にします。
o Confidentiality: Prevents the content of messages from being read by others than the intended recipients.
o 機密性：意図した受信者よりも、メッセージのコンテンツが他の人が読み取らないようにします。
o MSDU Delivery: Delivers the MAC service data unit (MSDU) for the stations.
o MSDU配信：ステーションにMac Service Data Unit（MSDU）を配信します。
Distribution system services consist of the following five services:
流通システムサービスは、次の5つのサービスで構成されています。
o Association: Establishes Access Point/Station (AP/STA) mapping and enables STA invocation of the distribution system services.
o 協会：アクセスポイント/ステーション（AP/STA）マッピングを確立し、配信システムサービスのSTA呼び出しを有効にします。
o Disassociation: Removes an existing association.
o 分離：既存の関連付けを削除します。
o Reassociation: Enables an established association (between AP and STA) to be transferred from one AP to another or the same AP.
o 再配分：確立された関連性（APとSTAの間）を、あるAPから別のAPまたは同じAPに転送できるようにします。
o Distribution: Provides MSDU forwarding by APs for the STAs associated with them. MSDUs can be either forwarded to the wireless destination or to the wired (Ethernet) destination (or both) using the "Distribution System" concept of 802.11.
o 配布：APSに関連するSTAにMSDU転送を提供します。MSDUSは、ワイヤレス宛先または有線（イーサネット）宛先（またはその両方）に802.11の「配布システム」概念を使用して転送できます。
o Integration: Translates the MSDU received from the Distribution System to a non-802.11 format and vice versa. Any MSDU that is received from the DS invokes the 'Integration' services of the DSS before the 'Distribution' services are invoked. The point of connection of the DS to the wired LAN is termed as 'portal'.
o 統合：流通システムから受信したMSDUを802.11以外の形式に変換し、その逆も同様です。DSから受信したMSDUは、「配布」サービスが呼び出される前にDSSの「統合」サービスを呼び出します。DSと有線LANへの接続のポイントは、「ポータル」と呼ばれます。
Apart from these services, the IEEE 802.11 also defines additional MAC services that must be implemented by the APs in the WLAN. For example:
これらのサービスとは別に、IEEE 802.11は、WLANのAPSが実装する必要がある追加のMacサービスも定義しています。例えば：
o Beacon Generation
o ビーコン生成
o Probe Response/Transmission
o プローブ応答/伝送
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o コントロールフレームの処理：RTS/CTS/ACK/PS-POLL/CF-END/CF-ack
o Synchronization
o 同期
o Retransmissions
o 再送信
o Transmission Rate Adaptation
o 伝送速度の適応
o Privacy: 802.11 Encryption/Decryption
o プライバシー：802.11暗号化/復号化
In addition to the services offered by the 802.11, the IEEE 802.11 WG is also developing technologies to support Quality of Service (802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or 802.11F -- recommended practice) to update APs when a STA roams from one BSS to another, Radio Resource Measurement Enhancements (802.11k), etc.
802.11が提供するサービスに加えて、IEEE 802.11 WGは、サービス品質（802.11e）、セキュリティアルゴリズム（802.11i）、Inter-APプロトコル（IAPP、または802.11F-推奨練習）をサポートするための技術を開発しています。STAがあるBSSから別のBSSにローミングするときにAPを更新するには、無線リソース測定の強化（802.11K）など。
IEEE 802.11 does not specify exactly how these functions are implemented, nor does it specify that they be implemented in one physical device. It only requires that the APs and the rest of the DS together implement all these services. Typically, vendors implement not only the services defined in the IEEE 802.11 standard, but also a variety of value-added services or functions, such as load balancing support, QoS, station mobility support, and rogue AP detection. What becomes clear from this document is that vendors take advantage of the flexibility in the 802.11 architecture, and have come up with many different flavors of architectures and implementations of the WLAN services.
IEEE 802.11は、これらの関数がどのように実装されているかを正確に指定しておらず、1つの物理デバイスに実装されることも指定しません。APSと残りのDSが一緒になってこれらすべてのサービスを実装する必要があります。通常、ベンダーは、IEEE 802.11標準で定義されているサービスだけでなく、負荷分散サポート、QoS、ステーションモビリティサポート、Rogue AP検出など、さまざまな付加価値サービスまたは機能も実装します。このドキュメントから明らかになるのは、ベンダーが802.11アーキテクチャの柔軟性を活用し、アーキテクチャのさまざまなフレーバーとWLANサービスの実装を考え出したことです。
Because many vendors choose to implement these WLAN services across multiple network elements, we want to make a clear distinction between the logical WLAN access network functions and the individual physical devices by adopting different terminology. We use "AP" to refer to the logical entity that provides access to the distribution services, and "WTP" (Wireless Termination Point) to the physical device that allows the RF antenna and 802.11 PHY to transmit and receive station traffic in the BSS network. In the Centralized Architecture (see section 5), the combination of WTPs with Access Controller (AC) implements all the logical functions. Each of these physical devices (WTP or AC) may implement only part of the logical functions. But the DS, including all the physical devices as a whole, implements all or most of the functions.
多くのベンダーは、複数のネットワーク要素にこれらのWLANサービスを実装することを選択しているため、異なる用語を採用することにより、論理WLANアクセスネットワーク機能と個々の物理デバイスを明確に区別したいと考えています。「AP」を使用して、流通サービスへのアクセスを提供する論理エンティティを指し、RFアンテナと802.11 PHYがBSSネットワークでステーショントラフィックを送信および受信できるようにする物理デバイスに「WTP」（ワイヤレス終端ポイント）を指す。集中アーキテクチャ（セクション5を参照）では、WTPとアクセスコントローラー（AC）の組み合わせにより、すべての論理関数が実装されています。これらの物理デバイス（WTPまたはAC）のそれぞれは、論理関数の一部のみを実装できます。しかし、すべての物理デバイス全体を含むDSは、機能のすべてまたはほとんどを実装しています。
To address the four problems identified in [2] (management, consistent configuration, RF control, security) additional functions, especially in the control and management plane, are typically offered by vendors to assist in better coordination and control across the entire ESS network. Such functions are especially important when the IEEE 802.11 WLAN functions are implemented over multiple entities in a large scale network, instead of within a single entity. Such functions include:
[2]（管理、一貫した構成、RF制御、セキュリティ）で特定された4つの問題に対処するために、特に制御および管理面での追加機能は、通常、ESSネットワーク全体でより良い調整と制御を支援するためにベンダーによって提供されます。このような関数は、IEEE 802.11 WLAN関数が、単一のエンティティ内ではなく、大規模ネットワーク内の複数のエンティティを介して実装されている場合に特に重要です。このような関数には以下が含まれます。
o RF monitoring, such as Radar detection, noise and interference detection, and measurement.
o レーダー検出、ノイズおよび干渉検出、測定などのRFモニタリング。
o RF configuration, e.g., for retransmission, channel selection, transmission power adjustment.
o たとえば、再送信、チャネル選択、伝送電源調整用のRF構成。
o WTP configuration, e.g., for SSID.
o ssid用のWTP構成。
o WTP firmware loading, e.g., automatic loading and upgrading of WTP firmware for network wide consistency.
o WTPファームウェアの読み込み、たとえば、ネットワーク全体の一貫性のためのWTPファームウェアの自動読み込みとアップグレード。
o Network-wide STA state information database, including the information needed to support value-added services, such as mobility and load balancing.
o モビリティや負荷分散などの付加価値サービスをサポートするために必要な情報を含む、ネットワーク全体のSTA状態情報データベース。
o Mutual authentication between network entities, e.g., for AC and WTP authentication in a Centralized WLAN Architecture.
o 集中型WLANアーキテクチャにおけるACおよびWTP認証などのネットワークエンティティ間の相互認証。
The services listed are concerned with the configuration and control of the radio resource ('RF Monitoring' and 'RF Configuration'), management and configuration of the WTP device ('WTP Configuration', 'WTP Firmware upgrade'), and also security regarding the registration of the WTP to an AC ('AC/WTP mutual authentication'). Moreover, the device from which other services, such as mobility management across subnets and load balancing, can obtain state information regarding the STA(s) associated with the wireless network, is also reported as a service ('STA state info database').
リストされているサービスは、無線リソースの構成と制御（「RF監視」および「RF構成」）、WTPデバイスの管理と構成（「WTP構成」、「WTPファームウェアアップグレード」）、およびセキュリティに関係しています。AC（「AC/WTP相互認証」）へのWTPの登録。さらに、サブネット間のモビリティ管理やロードバランスなどの他のサービスが、ワイヤレスネットワークに関連付けられたSTAに関する状態情報を取得できるデバイスも、サービスとして報告されています（「STA State Infoデータベース」）。
The above list of CAPWAP functions is not an exhaustive enumeration of all additional services offered by vendors. We included only those functions that are commonly represented in the survey data, and are pertinent to understanding the central problem of interoperability.
上記のCapWap関数のリストは、ベンダーが提供するすべての追加サービスの徹底的な列挙ではありません。調査データに一般的に表され、相互運用性の中心的な問題を理解することに関連する機能のみを含めました。
Most of these functions are not explicitly specified by IEEE 802.11, but some of the functions are. For example, the control and management of the radio-related functions of an AP are described implicitly in the MIB, such as:
これらの関数のほとんどは、IEEE 802.11で明示的に指定されていませんが、関数の一部は明示的に指定されていません。たとえば、APの無線関連機能の制御と管理は、次のようなMIBで暗黙的に説明されています。
o Channel Assignment
o チャネル割り当て
o Transmit Power Control
o 電力制御を送信します
o Radio Resource Measurement (work is currently under way in IEEE 802.11k)
o 無線リソース測定（現在、IEEE 802.11kで作業が進行中です）
The 802.11h [5] amendment to the base 802.11 standard specifies the operation of a MAC management protocol to accomplish the requirements of some regulatory bodies (principally in Europe, but expanding to others) in the following areas:
802.11H [5]ベース802.11の標準の修正は、MAC管理プロトコルの運用を指定して、次の領域でいくつかの規制機関（主にヨーロッパでは他のヨーロッパでも拡大）の要件を達成します。
o RADAR detection
o レーダー検出
o Transmit Power Control
o 電力制御を送信します
o Dynamic Channel Selection
o 動的チャネル選択
This document provides a taxonomy of the WLAN network architectures developed by the vendor community in an attempt to address some or all of the problems outlined in [2]. As the IEEE 802.11 standard purposely avoids specifying the details of DS implementations, different architectures have proliferated in the market. While all these different architectures conform to the IEEE 802.11 standard as a whole, their individual functional components are not standardized.
このドキュメントは、[2]で概説されている問題の一部またはすべてに対処するために、ベンダーコミュニティによって開発されたWLANネットワークアーキテクチャの分類法を提供します。IEEE 802.11は、DS実装の詳細の指定を意図的に回避するため、市場でさまざまなアーキテクチャが急増しています。これらすべての異なるアーキテクチャは、IEEE 802.11標準全体に準拠していますが、個々の機能コンポーネントは標準化されていません。
Interfaces between the network architecture components are mostly proprietary, and there is no guarantee of cross-vendor interoperability of products, even within the same family of architectures.
ネットワークアーキテクチャコンポーネント間のインターフェイスはほとんど独自のものであり、同じアーキテクチャファミリー内であっても、製品のクロスベンダーの相互運用性の保証はありません。
To achieve interoperability in the market place, the IETF CAPWAP working group is first documenting both the functions and the network architectures currently offered by the existing WLAN vendors. The end result is this taxonomy document.
市場での相互運用性を実現するために、IETF CapWapワーキンググループは、最初に既存のWLANベンダーが現在提供している機能とネットワークアーキテクチャの両方を文書化しています。最終結果は、この分類文書です。
After analyzing more than a dozen different vendors' architectures, we believe that the existing 802.11 WLAN access network architectures can be broadly categorized into three distinct families, based on the characteristics of the Distribution Systems that are employed to provide the 802.11 functions.
12を超える異なるベンダーのアーキテクチャを分析した後、既存の802.11 WLANアクセスネットワークアーキテクチャは、802.11機能を提供するために使用される配布システムの特性に基づいて、3つの異なるファミリに広く分類できると考えています。
o Autonomous WLAN Architecture: The first architecture family is the traditional autonomous WLAN architecture, in which each WTP is a single physical device that implements all the 802.11 services, including both the distribution and integration services, and the portal function. Such an AP architecture is called Autonomous WLAN Architecture because each WTP is autonomous in its functionality, and no explicit 802.11 support is needed from devices other than the WTP. In such architecture, the WTP is typically configured and controlled individually, and can be monitored and managed via typical network management protocols like SNMP. The WTPs are the traditional APs with which most people are familiar. Such WTPs are sometimes referred to as "Fat APs" or "Standalone APs".
o 自律的なWLANアーキテクチャ：最初のアーキテクチャファミリーは、伝統的な自律WLANアーキテクチャであり、各WTPは、配布と統合サービスの両方、ポータル機能を含むすべての802.11サービスを実装する単一の物理デバイスです。このようなAPアーキテクチャは、各WTPがその機能において自律的であり、WTP以外のデバイスから明示的な802.11サポートは必要ないため、自律WLANアーキテクチャと呼ばれます。このようなアーキテクチャでは、WTPは通常、個別に構成および制御され、SNMPなどの典型的なネットワーク管理プロトコルを介して監視および管理できます。WTPは、ほとんどの人が馴染みのある従来のAPです。このようなWTPは、「脂肪AP」または「スタンドアロンAP」と呼ばれることがあります。
o Centralized WLAN Architecture: The second WLAN architecture family is an emerging hierarchical architecture utilizing one or more centralized controllers for managing a large number of WTP devices. The centralized controller is commonly referred to as an Access Controller (AC), whose main function is to manage, control, and configure the WTP devices that are present in the network. In addition to being a centralized entity for the control and management plane, it may also become a natural aggregation point for the data plane since it is typically situated in a centralized location in the wireless access network. The AC is often co-located with an L2 bridge, a switch, or an L3 router, and may be referred to as Access Bridge or Access Router in those particular cases. Therefore, an Access Controller could be either an L3 or L2 device, and is the generic term we use throughout this document. It is also possible that multiple ACs are present in a network for purposes of redundancy, load balancing, etc. This architecture family has several distinct characteristics that are worth noting. First, the hierarchical architecture and the centralized AC affords much better manageability for large scale networks. Second, since the IEEE 802.11 functions and the CAPWAP control functions are provided by the WTP devices and the AC together, the WTP devices themselves may no longer fully implement the 802.11 functions as defined in the standards. Therefore, it can be said that the full 802.11 functions are implemented across multiple physical network devices, namely, the WTPs and ACs. Since the WTP devices only implement a portion of the functions that standalone APs implement, WTP devices in this architecture are sometimes referred to as light weight or thin APs.
o 集中型WLANアーキテクチャ：2番目のWLANアーキテクチャファミリは、多数のWTPデバイスを管理するために1つ以上の集中コントローラーを利用した新興の階層アーキテクチャです。中央コントローラーは一般にアクセスコントローラー（AC）と呼ばれ、その主な機能は、ネットワークに存在するWTPデバイスを管理、制御、構成することです。制御および管理プレーンの集中型エンティティであることに加えて、通常、ワイヤレスアクセスネットワークの集中型の場所に位置するため、データプレーンの自然な集約点になる可能性があります。ACは、多くの場合、L2ブリッジ、スイッチ、またはL3ルーターと同時配置されており、これらの特定のケースではアクセスブリッジまたはアクセスルーターと呼ばれます。したがって、アクセスコントローラーはL3またはL2デバイスのいずれかであり、このドキュメント全体で使用する汎用用語です。また、冗長性、負荷分散などの目的でネットワークに複数のACSが存在する可能性もあります。このアーキテクチャファミリーには、注目に値するいくつかの明確な特性があります。第一に、階層アーキテクチャと集中化されたACは、大規模なネットワークによりはるかに優れた管理可能性を提供します。第二に、IEEE 802.11関数とCapWap制御関数はWTPデバイスとACを一緒に提供されるため、WTPデバイス自体は、標準で定義されている802.11関数を完全に実装できなくなる場合があります。したがって、完全な802.11関数は、複数の物理ネットワークデバイス、つまりWTPSとACSにわたって実装されていると言えます。WTPデバイスは、スタンドアロンAPが実装する機能の一部のみを実装するため、このアーキテクチャのWTPデバイスは、軽量または薄いAPと呼ばれることがあります。
o Distributed WLAN Architecture: The third emerging WLAN architecture family is the distributed architecture in which the participating wireless nodes are capable of forming a distributed network among themselves, via wired or wireless media. A wireless mesh network is one example within the distributed architecture family, where the nodes themselves form a mesh network and connect with neighboring mesh nodes via 802.11 wireless links. Some of these nodes also have wired Ethernet connections acting as gateways to the external network.
o 分散型WLANアーキテクチャ：3番目の新興WLANアーキテクチャファミリーは、参加しているワイヤレスノードが、有線またはワイヤレスメディアを介して分散ネットワークを形成できる分散アーキテクチャです。ワイヤレスメッシュネットワークは、分散アーキテクチャファミリー内の1つの例であり、ノード自体がメッシュネットワークを形成し、802.11ワイヤレスリンクを介して隣接するメッシュノードと接続します。これらのノードの一部には、外部ネットワークへのゲートウェイとして機能する有線イーサネット接続もあります。
Before the IETF CAPWAP working group started documenting the various WLAN architectures, we conducted an open survey soliciting WLAN architecture descriptions via the IETF CAPWAP mailing list. We provided the interested parties with a common template that included a number of questions about their WLAN architectures. We received 16 contributions in the form of short text descriptions answering those questions. 15 of them are from WLAN vendors (AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems, Extreme Networks, Intoto, Janusys Networks, Nortel, Panasonic, Trapeze, Instant802, Strix Systems, Symbol) and one from the academic research community (UCLA). Out of the 16 contributions, one describes an Autonomous WLAN Architecture, three are Distributed Mesh Architectures, and the remaining twelve entries represent architectures in the family of the Centralized WLAN Architecture.
IETF CapWapワーキンググループがさまざまなWLANアーキテクチャの文書化を開始する前に、IETF CapWapメーリングリストを介してWLANアーキテクチャの説明を勧誘するオープン調査を実施しました。利害関係者に、WLANアーキテクチャに関する多くの質問を含む共通のテンプレートを提供しました。これらの質問に答える短いテキストの説明という形で16の貢献を受けました。そのうち15は、WLANベンダー（Airespace、Aruba、Avaya、Chantry Networks、Cisco、Cranite Systems、Intoto、Janusys Networks、Nortel、Panasonic、Trapeze、Instant802、Strix Systems、Symbol）からのものです。（UCLA）。16の貢献のうち、1つは自律的なWLANアーキテクチャを説明し、3つは分散メッシュアーキテクチャであり、残りの12のエントリは集中化されたWLANアーキテクチャのファミリーのアーキテクチャを表しています。
The main objective of this survey was to identify the general categories and trends in WLAN architecture evolution, discover their common characteristics, and determine what is performed differently among them and why. In order to represent the survey data in a compact format, a "Functional Distribution Matrix" is used in this document, (mostly in the Centralized WLAN architecture section), to tabulate the various services and functions in the vendors' offerings. These services and functions are classified into three main categories: o Architecture Considerations: The choice of the connectivity between the AC and the WTP. The design choices regarding the physical device on which processing of management, control, and data frames of the 802.11 takes place.
この調査の主な目的は、WLANアーキテクチャの進化の一般的なカテゴリと傾向を特定し、それらの共通の特性を発見し、それらの間で何が異なるか、そしてその理由を決定することでした。コンパクトな形式で調査データを表すために、このドキュメント（主に集中型WLANアーキテクチャセクション）で「機能分布マトリックス」が使用され、ベンダーの提供物のさまざまなサービスと機能を表します。これらのサービスと機能は、3つの主要なカテゴリに分類されます。oアーキテクチャに関する考慮事項：ACとWTPの間の接続の選択。802.11の管理、制御、およびデータフレームの処理に関する物理デバイスに関する設計の選択が行われます。
o 802.11 Functions: As described in Section 1.1.
o 802.11関数：セクション1.1で説明されています。
o CAPWAP Functions: As described in Section 1.2.
o CAPWAP関数：セクション1.2で説明されています。
For each one of these categories, the mapping of each individual function to network entities implemented by each vendor is shown in tabular form. The rows in the Functional Distribution Matrix represent individual functions that are organized into the above mentioned three categories. Each column of the Matrix represents one vendor's architecture offering in the survey data. See Figure 7 as an example of the Matrix.
これらのカテゴリのそれぞれについて、各ベンダーによって実装されたネットワークエンティティへの個々の関数のマッピングは、表形式で表示されます。関数分布マトリックスの行は、上記の3つのカテゴリに編成された個々の関数を表します。マトリックスの各列は、調査データの1つのベンダーのアーキテクチャの提供を表しています。マトリックスの例として図7を参照してください。
This Functional Distribution Matrix is intended for the sole purpose of organizing the architecture taxonomy data, and represents the contributors' views of their architectures from an engineering perspective. It does not necessarily imply that a product exists or will be shipped, nor an intent by the vendor to build such a product.
この機能分布マトリックスは、アーキテクチャの分類データを整理することを目的とするためのものであり、エンジニアリングの観点からのアーキテクチャに対する貢献者の見解を表しています。製品が存在する、または出荷されることも、ベンダーがそのような製品を構築する意図も必ずしも暗示するわけではありません。
The next section provides a list of definitions used in this document. The rest of this document is organized around the three broad WLAN architecture families that were introduced in Section 1.3. Each architecture family is discussed in a separate section. The section on Centralized Architecture contains more in-depth details than the other two families, largely due to the large number of the survey data (twelve out of sixteen) collected that fall into the Centralized Architecture category. Summary and conclusions are provided at the end to highlight the basic findings from this taxonomy exercise.
次のセクションでは、このドキュメントで使用される定義のリストを示します。このドキュメントの残りの部分は、セクション1.3で導入された3つの広いWLANアーキテクチャファミリーを中心に編成されています。各アーキテクチャファミリについては、別のセクションで説明します。集中アーキテクチャのセクションには、主に集中アーキテクチャカテゴリに分類される調査データ（16人中12人）が収集されたため、他の2つのファミリーよりも詳細な詳細が含まれています。概要と結論は、この分類法の演習からの基本的な調査結果を強調するために最後に提供されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [3]に記載されているように解釈される。
Station (STA): A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).
ステーション（STA）：IEEE 802.11を含むデバイスは、ワイヤレス媒体（WM）へのIEEE 802.11コンフォーマントミディアムアクセス制御（MAC）および物理層（PHY）インターフェイスを含む。
Access Point (AP): An entity that has station functionality and provides access to distribution services via the wireless medium (WM) for associated stations.
Access Point（AP）：ステーション機能を備え、関連するステーションのワイヤレスメディア（WM）を介して配布サービスへのアクセスを提供するエンティティ。
Basic Service Set (BSS): A set of stations controlled by a single coordination function.
基本サービスセット（BSS）：単一の調整関数によって制御されるステーションのセット。
Station Service (SS): The set of services that support transport of medium access control (MAC) service data units (MSDUs) between stations within a basic service set (BSS).
ステーションサービス（SS）：基本サービスセット（BSS）内のステーション間の中間アクセス制御（MAC）サービスデータユニット（MSDU）の輸送をサポートするサービスのセット。
Distribution System (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS).
配電システム（DS）：一連の基本サービスセット（BSSS）と統合ローカルエリアネットワーク（LAN）を相互接続するために使用されるシステムは、拡張サービスセット（ESS）を作成します。
Extended Service Set (ESS): A set of one or more interconnected basic service sets (BSSs) with the same SSID and integrated local area networks (LANs), which appears as a single BSS to the logical link control layer at any station associated with one of those BSSs.
拡張サービスセット（ESS）：同じSSIDおよび統合されたローカルエリアネットワーク（LANS）を備えた1つ以上の相互接続された基本サービスセット（BSSS）のセット。それらのBSSSの1つ。
Portal: The logical point at which medium access control (MAC) service data units (MSDUs) from a non-IEEE 802.11 local area network (LAN) enter the distribution system (DS) of an extended service set (ESS).
ポータル：非IEEE 802.11ローカルエリアネットワーク（LAN）からのMedium Access Control（MAC）サービスデータユニット（MSDU）が拡張サービスセット（ESS）の配布システム（DS）に入る論理ポイント。
Distribution System Service (DSS): The set of services provided by the distribution system (DS) that enable the medium access control (MAC) layer to transport MAC service data units (MSDUs) between stations that are not in direct communication with each other over a single instance of the wireless medium (WM). These services include the transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), transport of MSDUs between portals and BSSs within an ESS, and transport of MSDUs between stations in the same BSS in cases where the MSDU has a multicast or broadcast destination address, or where the destination is an individual address, but the station sending the MSDU chooses to involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs.
配電システムサービス（DSS）：ミディアムアクセス制御（MAC）レイヤーが互いに直接通信しないステーション間でMACサービスデータユニット（MSDU）を輸送できるようにする配信システム（DS）が提供するサービスのセットワイヤレスメディア（WM）の単一インスタンス。これらのサービスには、拡張サービスセット（ESS）内の基本サービスセット（BSSS）のアクセスポイント（APS）間のMSDUの輸送、ESS内のポータルとBSSS間のMSDUの輸送、および同じステーション内のステーション間のMSDUの輸送が含まれますMSDUにマルチキャストまたはブロードキャストの宛先アドレスがある場合、または宛先が個別の住所である場合、BSSがDSSを含むことを選択するステーションが選択します。DSSは、IEEE 802.11 Macのペア間で提供されます。
Integration: The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution system (DS) and an existing, non-IEEE 802.11 local area network (via a portal).
統合：流通システム（DS）と既存の非IEEE 802.11ローカルエリアネットワーク（ポータル経由）の間の中間アクセス制御（MAC）サービスデータユニット（MSDU）の配信を可能にするサービス。
Distribution: The service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) within the distribution system (DS).
配布：Association情報を使用することにより、流通システム（DS）内で中程度のアクセス制御（MAC）サービスデータユニット（MSDU）を提供するサービス。
One of the motivations in defining new terminology is to clarify ambiguity and confusion surrounding some conventional terms. One such term is "Access Point (AP)". Typically, when people talk about "AP", they refer to the physical entity (box) that has an antenna, implements 802.11 PHY, and receives/transmits the station (STA) traffic over the air. However, the 802.11 Standard [1] describes the AP mostly as a logical entity that implements a set of logical services so that station traffic can be received and transmitted effectively over the air. When people refer to "AP functions", they usually mean the logical functions the whole WLAN access network supports, and not just the subset of functions supported by the physical entity (box) that the STAs communicate with directly. Such confusion can be especially acute when logical functions are implemented across a network instead of within a single physical entity. To avoid further confusion, we define the following terminology:
新しい用語を定義する動機の1つは、いくつかの従来の用語を取り巻く曖昧さと混乱を明確にすることです。そのような用語の1つは「アクセスポイント（AP）」です。通常、人々が「AP」について話すとき、彼らはアンテナを持つ物理エンティティ（ボックス）を参照し、802.11 PHYを実装し、空中にステーション（STA）のトラフィックを受け取り/送信します。ただし、802.11標準[1]は、APを主に論理サービスのセットを実装して、ステーションのトラフィックを空中に効果的に受信および送信できるようにする論理エンティティとして説明しています。人々が「AP関数」を参照する場合、通常、STAが直接通信する物理エンティティ（ボックス）によってサポートされる機能のサブセットだけでなく、WLANアクセスネットワーク全体がサポートする論理関数を意味します。このような混乱は、単一の物理エンティティ内ではなくネットワーク全体で論理関数が実装される場合、特に深刻なものになる可能性があります。さらなる混乱を避けるために、次の用語を定義します。
CAPWAP: Control and Provisioning of Wireless Access Points
CAPWAP：ワイヤレスアクセスポイントの制御とプロビジョニング
IEEE 802.11 WLAN Functions: A set of logical functions defined by the IEEE 802.11 Working Group, including all the MAC services, Station Services, and Distribution Services. These logical functions are required to be implemented in the IEEE 802.11 Wireless LAN (WLAN) access networks by the IEEE 802.11 Standard [1].
IEEE 802.11 WLAN関数：IEEE 802.11ワーキンググループによって定義された一連の論理関数、すべてのMACサービス、ステーションサービス、流通サービスを含む。これらの論理関数は、IEEE 802.11標準[1]によるIEEE 802.11ワイヤレスLAN（WLAN）アクセスネットワークに実装する必要があります。
CAPWAP Functions: A set of WLAN control functions that are not directly defined by IEEE 802.11 Standards, but deemed essential for effective control, configuration, and management of 802.11 WLAN access networks.
CAPWAP関数：IEEE 802.11標準では直接定義されていないが、802.11 WLANアクセスネットワークの効果的な制御、構成、および管理に不可欠であると見なされるWLAN制御関数のセット。
Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and 802.11 PHY to transmit and receive station traffic for the IEEE 802.11 WLAN access networks. Such physical entities were often called "Access Points" (AP), but "AP" can also refer to the logical entity that implements 802.11 services. We recommend "WTP" as the generic term that explicitly refers to the physical entity with the above property (e.g., featuring an RF antenna and 802.11 PHY), applicable to network entities of both Autonomous and Centralized WLAN Architecture (see below).
ワイヤレス終了点（WTP）：IEEE 802.11 WLANアクセスネットワークのステーショントラフィックを送信および受信するためのRFアンテナと802.11 PHYを含む物理またはネットワークエンティティ。このような物理エンティティはしばしば「アクセスポイント」（AP）と呼ばれていましたが、「AP」は802.11サービスを実装する論理エンティティを指します。「WTP」は、上記のプロパティ（例えば、RFアンテナと802.11 PHYを特徴とする）を持つ物理エンティティを明示的に指す一般的な用語として、自律的および集中的なWLANアーキテクチャの両方のネットワークエンティティに適用されます（以下を参照）。
Autonomous WLAN Architecture: The WLAN access network architecture family in which all the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented within each Wireless Termination Point (WTP) in the network. The WTPs in such networks are also called standalone APs, or fat APs, because these devices implement the full set of functions that enable the devices to operate without any other support from the network.
自律的なWLANアーキテクチャ：IEEE 802.11とCapWap関数（該当する場合は）を含むすべての論理関数（該当する場合）を含むすべての論理関数が、ネットワーク内の各ワイヤレス終端ポイント（WTP）内に実装されているWLANアクセスネットワークアーキテクチャファミリー。このようなネットワーク内のWTPは、スタンドアロンAPまたはFAT APとも呼ばれます。これらのデバイスは、ネットワークからの他のサポートなしでデバイスを動作させる機能の完全なセットを実装するためです。
Centralized WLAN Architecture: The WLAN access network architecture family in which the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented across a hierarchy of network entities. At the lower level are the WTPs, while at the higher level are the Access Controllers (ACs), which are responsible for controlling, configuring, and managing the entire WLAN access network.
集中WLANアーキテクチャ：IEEE 802.11とCapWap関数（該当する場合は）を含む論理関数がネットワークエンティティの階層全体に実装されているWLANアクセスネットワークアーキテクチャファミリー。低いレベルにはWTPがありますが、より高いレベルにはアクセスコントローラー（ACS）があり、WLANアクセスネットワーク全体の制御、構成、および管理を担当しています。
Distributed WLAN Architecture: The WLAN access network architecture family in which some of the control functions (e.g., CAPWAP functions) are implemented across a distributed network consisting of peer entities. A wireless mesh network can be considered an example of such an architecture.
分散型WLANアーキテクチャ：WLANアクセスネットワークアーキテクチャファミリーでは、一部の制御機能（CapWap関数など）がピアエンティティで構成される分散ネットワーク全体に実装されています。ワイヤレスメッシュネットワークは、このようなアーキテクチャの例と見なすことができます。
Access Controller (AC): The network entity in the Centralized WLAN Architecture that provides WTPs access to the centralized hierarchical network infrastructure in the data plane, control plane, management plane, or a combination therein.
Access Controller（AC）：データプレーン、コントロールプレーン、管理プレーン、またはその組み合わせの集中階層ネットワークインフラストラクチャへのWTPSアクセスを提供する集中WLANアーキテクチャのネットワークエンティティ。
Standalone WTP: Refers to the WTP in Autonomous WLAN Architecture.
スタンドアロンWTP：自律的なWLANアーキテクチャのWTPを指します。
Controlled WTP: Refers to the WTP in Centralized WLAN Architecture.
制御されたWTP：集中型WLANアーキテクチャのWTPを指します。
Split MAC Architecture: A subgroup of the Centralized WLAN Architecture whereby WTPs in such WLAN access networks only implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while all the remaining management and data frames are tunnelled to the AC for centralized processing. The IEEE 802.11 MAC, as defined by IEEE 802.11 Standards in [1], is effectively split between the WTP and AC.
分割MACアーキテクチャ：このようなWLANアクセスネットワーク内のWTPがIEEE 802.11の遅延に敏感なMACサービス（すべての制御フレームと一部の管理フレームを含む）のみを実装する一方で、残りの管理とデータフレームはすべての状態にあるため、そのようなWLANアクセスネットワークのWTPが実装する集中型WLANアーキテクチャのサブグループです。集中処理用のAC。[1]のIEEE 802.11標準で定義されているIEEE 802.11 Macは、WTPとACの間で効果的に分割されています。
Remote MAC Architecture: A subgroup of the Centralized WLAN Architecture, where the entire set of 802.11 MAC functions (including delay-sensitive functions) is implemented at the AC. The WTP terminates the 802.11 PHY functions.
リモートMacアーキテクチャ：802.11 Mac関数のセット全体（遅延感受性関数を含む）のセット全体がACで実装される集中WLANアーキテクチャのサブグループ。WTPは802.11 PHY関数を終了します。
Local MAC Architecture: A subgroup of the Centralized WLAN Architecture, where the majority or entire set of 802.11 MAC functions (including most of the 802.11 management frame processing) are implemented at the WTP. Therefore, the 802.11 MAC stays intact and local in the WTP, along with PHY.
ローカルMACアーキテクチャ：集中化されたWLANアーキテクチャのサブグループ。802.11Mac関数の過半数または全体がWTPで実装されています。したがって、802.11 MACは、PHYとともにWTPでそのままでローカルのままです。
While some terminology has been used by vendors historically to describe "Access Points", we recommend deferring its use, in order to avoid further confusion. A list of such terms and the recommended new terminology is provided below:
いくつかの用語は、歴史的に「アクセスポイント」を説明するためにベンダーによって使用されてきましたが、さらなる混乱を避けるために、その使用を延期することをお勧めします。そのような用語のリストと推奨される新しい用語を以下に示します。
Split WLAN Architecture: Use Centralized WLAN Architecture.
分割WLANアーキテクチャ：集中型WLANアーキテクチャを使用します。
Hierarchical WLAN Architecture: Use Centralized WLAN Architecture.
階層的なWLANアーキテクチャ：集中型WLANアーキテクチャを使用します。
Standalone Access Point: Use Standalone WTP.
スタンドアロンアクセスポイント：スタンドアロンWTPを使用します。
Fat Access Point: Use Standalone WTP.
脂肪アクセスポイント：スタンドアロンWTPを使用します。
Thin Access Point: Use Controlled WTP.
薄いアクセスポイント：制御されたWTPを使用します。
Light weight Access Point: Use Controlled WTP.
軽量アクセスポイント：制御されたWTPを使用します。
Split AP Architecture: Use Local MAC Architecture.
APアーキテクチャの分割：ローカルMacアーキテクチャを使用します。
Antenna AP Architecture: Use Remote MAC Architecture.
アンテナAPアーキテクチャ：リモートMacアーキテクチャを使用します。
Figure 1 shows an example network of the Autonomous WLAN Architecture. This architecture implements all the 802.11 functionality in a single physical device, the Wireless Termination Point (WTP). An embodiment of this architecture is a WTP that translates between 802.11 frames to/from its radio interface and 802.3 frames to/from an Ethernet interface. An 802.3 infrastructure that interconnects the Ethernet interfaces of different WTPs provides the distribution system. It can also provide portals for integrated 802.3 LAN segments.
図1は、自律的なWLANアーキテクチャのネットワークの例を示しています。このアーキテクチャは、すべての802.11機能を単一の物理デバイス、ワイヤレス終端ポイント（WTP）に実装します。このアーキテクチャの実施形態は、無線インターフェイスからの802.11フレーム、および802.3フレームからイーサネットインターフェイスから802.3フレームの間で変換するWTPです。異なるWTPのイーサネットインターフェイスを相互接続する802.3インフラストラクチャは、配電システムを提供します。また、統合された802.3 LANセグメントのポータルを提供することもできます。
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-----+ | | +-----+ | | +-----+ |
+----| WTP |----+ +----| WTP |----+ +----| WTP |----+
+--+--+ +--+--+ +--+--+
|Ethernet | |
+------------------+ | +------------------+
| | |
+---+--+--+---+
| Ethernet |
802.3 LAN --------------+ Switch +-------------- 802.3 LAN
segment 1 | | segment 2
+------+------+
Figure 1: Example of Autonomous WLAN Architecture
図1：自律的なWLANアーキテクチャの例
A single physical WTP can optionally be provisioned as multiple virtual WTPs by supporting multiple SSIDs to which 802.11 clients may associate. In some cases, this will involve putting a corresponding 802.1Q VLAN tag on each packet forwarded to the Ethernet infrastructure and removing 802.1Q tags prior to forwarding the packets to the wireless medium.
単一の物理WTPは、802.11クライアントが関連付けることができる複数のSSIDをサポートすることにより、オプションで複数の仮想WTPとしてプロビジョニングできます。場合によっては、パケットをワイヤレスメディアに転送する前に、イーサネットインフラストラクチャに転送された各パケットに対応する802.1Q VLANタグを配置し、802.1Qタグを削除することが含まれます。
The scope of the ESS(s) created by interconnecting the WTPs will be confined by the constraints imposed by the Ethernet infrastructure.
WTPを相互接続することによって作成されたESSの範囲は、イーサネットインフラストラクチャによって課される制約によって限定されます。
Authentication of 802.11 clients may be performed locally by the WTP or by using a centralized authentication server.
802.11クライアントの認証は、WTPまたは集中認証サーバーを使用してローカルに実行できます。
Since both the 802.11 and CAPWAP functions are tightly integrated into a single physical device, security issues with this architecture are confined to the WTP. There are no extra implications from the client authentication and encryption/decryption perspective, as the AAA interface and the key generation mechanisms required for 802.11i encryption/decryption are integrated into the WTP.
802.11とCapWap関数の両方が単一の物理デバイスに密接に統合されているため、このアーキテクチャのセキュリティの問題はWTPに限定されます。AAAインターフェイスと802.11iの暗号化/復号化に必要な主要な生成メカニズムがWTPに統合されるため、クライアント認証と暗号化/復号化の観点からは特別な意味はありません。
One of the security needs in this architecture is for mutual authentication between the WTP and the Ethernet infrastructure. This can be ensured by existing mechanisms such as 802.1X between the WTP and the Ethernet switch to which it connects. Another critical security issue is the fact that the WTP is most likely not under lock and key, but contains secret information to communicate with back-end systems, such as AAA and SNMP. Because IT personnel uses the common management method of pushing a "template" to all devices, theft of such a device would potentially compromise the wired network.
このアーキテクチャのセキュリティニーズの1つは、WTPとイーサネットインフラストラクチャ間の相互認証のためです。これは、WTPと接続するイーサネットスイッチの間の802.1xなどの既存のメカニズムによって確保できます。別の重要なセキュリティの問題は、WTPがロックとキーの下にない可能性が高いが、AAAやSNMPなどのバックエンドシステムと通信するための秘密情報が含まれている可能性が高いという事実です。IT担当者は、すべてのデバイスに「テンプレート」をプッシュする共通管理方法を使用するため、そのようなデバイスの盗難は、有線ネットワークを潜在的に侵害する可能性があります。
Centralized WLAN Architecture is an emerging architecture family in the WLAN market. Contrary to the Autonomous WLAN Architecture, where the 802.11 functions and network control functions are all implemented within each Wireless Termination Point (WTP), the Centralized WLAN Architecture employs one or more centralized controllers, called Access Controller(s), to enable network-wide monitoring, improve management scalability, and facilitate dynamic configurability.
集中化されたWLANアーキテクチャは、WLAN市場の新興アーキテクチャファミリーです。802.11関数とネットワーク制御機能がすべて各ワイヤレス端子ポイント（WTP）内に実装されている自律WLANアーキテクチャに反して、集中化されたWLANアーキテクチャは、ネットワーク全体でアクセスコントローラーと呼ばれる1つ以上の集中コントローラーを採用しています。監視、管理のスケーラビリティを改善し、動的な構成性を促進します。
The following figure schematically shows the Centralized WLAN Architecture network diagram, where the Access Controller (AC) connects to multiple Wireless Termination Points (WTPs) via an interconnection medium. This can be a direct connection, an L2- switched, or an L3-routed network as described in Section 5.1. The AC exchanges configuration and control information with the WTP devices, allowing the management of the network from a centralized point. Designs of the Centralized WLAN Architecture family do not presume (as the diagram might suggest) that the AC necessarily intercedes in the data plane to/from the WTP(s). More details are provided later in this section.
次の図は、集中化されたWLANアーキテクチャネットワーク図を模式的に示しています。ここでは、アクセスコントローラー（AC）が相互接続媒体を介して複数のワイヤレス終端ポイント（WTPS）に接続します。これは、セクション5.1で説明されているように、直接接続、L2スイッチ、またはL3ルーティングネットワークです。ACは、WTPデバイスと構成と制御情報を交換し、集中ポイントからネットワークの管理を可能にします。集中化されたWLANアーキテクチャファミリの設計は、[図が示唆しているように）ACが必然的にWTPとの間でデータプレーン内のACが挿入されるとは想定していません。詳細については、このセクションの後半で説明します。
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-------+ | | +-------+ | | +-------+ |
+----| WTP |--+ +----| WTP |--+ +----| WTP |--+
+---+---+ +---+---+ +---+---+
| | |
+------------------+ | +-----------------+
| |...|
+----+--+---+--------+
| Interconnection |
+-------+------------+
|
|
+-----+----+
| AC |
+----------+
Figure 2: Centralized WLAN Architecture Diagram
図2：集中型WLANアーキテクチャ図
In the diagram above, the AC is shown as a single physical entity that provides all of the CAPWAP functions listed in Section 1.2. However, this may not always be the case. Closer examination of the functions reveals that their different resource requirements (e.g., CPU, memory, storage) may be distributed across different devices. For instance, complex radio control algorithms can be CPU intensive. Storing and downloading images and configurations can be storage intensive. Therefore, different CAPWAP functions might be implemented on different physical devices due to the different nature of their resource requirements. The network entity marked 'AC' in the diagram above should be thought of as a multiplicity of logical functions, and not necessarily as a single physical device. The ACs may also choose to implement some control functions locally, and provide interfaces to access other global network management functions, which are typically implemented on separate boxes, such as a SNMP Network Management Station and an AAA back-end server (e.g., Radius Authentication Server).
上記の図では、ACはセクション1.2にリストされているすべてのCAPWAP関数を提供する単一の物理エンティティとして示されています。ただし、これは必ずしもそうであるとは限りません。関数を綿密に調べると、さまざまなリソース要件（CPU、メモリ、ストレージなど）がさまざまなデバイスに分布する可能性があることが明らかになりました。たとえば、複雑な無線制御アルゴリズムはCPU集約型である可能性があります。画像と構成の保存とダウンロードは、ストレージ集約的です。したがって、リソース要件の性質が異なるため、異なる物理デバイスに異なるCAPWAP関数が実装される場合があります。上記の図の「AC」とマークされたネットワークエンティティは、必ずしも単一の物理デバイスとは限りません。ACSは、一部の制御機能をローカルに実装することを選択し、SNMPネットワーク管理ステーションやAAAバックエンドサーバーなどの別のボックスに通常実装される他のグローバルネットワーク管理機能にアクセスするインターフェイスを提供することもできます。サーバ）。
There are several connectivity options to consider between the AC(s) and the WTPs, including direct connection, L2 switched connection, and L3 routed connection, as shown in Figures 3, 4, and 5.
図3、4、および5に示すように、直接接続、L2スイッチ接続、L3ルーティング接続を含む、AC（S）とWTPSの間で考慮すべきいくつかの接続オプションがあります。
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP |
+--+--+ +--+--+
Figure 3: Directly Connected
図3：直接接続
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +-----+-----+
| WTP | | Switch |
+--+--+ +---+-----+-+
| |
+-----+ +-----+
| WTP | | WTP |
+-----+ +-----+
Figure 4: Switched Connections
図4：交換された接続
+-------+-------+
| AC |
+-------+-------+
|
--------+------ LAN
|
+-------+-------+
| Router |
+-------+-------+
|
-----+--+--+--- LAN
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP|
+--+--+ +--+--+
Figure 5: Routed Connections
図5：ルーティングされた接続
Dynamic and consistent network management is one of the primary motivations for the Centralized Architecture. The survey data from vendors also shows that different varieties of this architecture family have emerged to meet a complex set of different requirements for various possible deployment scenarios. This is also a direct result of the inherent flexibility in the 802.11 standard [1] regarding the implementation of the logical functions that are broadly described under the term "Access Point (AP)". Because there is no standard mapping of these AP functions to physical network entities, several design choices have been made by vendors that offer related products. Moreover, the increased demand for monitoring and consistent configuration of large wireless networks has resulted in a set of 'value-added' services provided by the various vendors, most of which share common design properties and service goals.
動的で一貫したネットワーク管理は、集中アーキテクチャの主要な動機の1つです。ベンダーからの調査データは、このアーキテクチャファミリーのさまざまな種類が、さまざまな展開シナリオのさまざまな要件の複雑なセットを満たすために登場したことも示しています。これはまた、「アクセスポイント（AP）」という用語で広く説明されている論理関数の実装に関する802.11標準[1]に固有の柔軟性の直接的な結果です。これらのAP関数の物理ネットワークエンティティへの標準マッピングはないため、関連製品を提供するベンダーによっていくつかの設計選択が行われました。さらに、大規模なワイヤレスネットワークの監視と一貫した構成の需要の増加により、さまざまなベンダーが提供する「付加価値」サービスのセットが生まれました。
In the following, we describe the three main variants observed from the survey data within the family of Centralized WLAN Architecture, namely the Local MAC, Split MAC, and Remote MAC approaches. For each approach, we provide the mapping characteristics of the various functions into the network entities from each vendor. The naming of Local MAC, Split MAC, and Remote MAC reflects how the functions, and especially the 802.11 MAC functions, are mapped onto the network entities. Local MAC indicates that the MAC functions stay intact and local to WTPs, while Remote MAC denotes that the MAC has moved away from the WTP to a remote AC in the network. Split MAC shows the MAC being split between the WTPs and ACs, largely along the line of realtime sensitivity. Typically, Split MAC vendors choose to put realtime functions on the WTPs while leaving non-realtime functions to the ACs. 802.11 does not clearly specify what constitutes realtime functions versus non-realtime functions, and so a clear and definitive line does not exist. As shown in Section 5.4, each vendor has its own interpretation on this, and there are some discrepancies about where to draw the line between realtime and non-realtime functions. However, vendors agree on the characterization of the majority of MAC functions. For example, every vendor classifies the DCF as a realtime function.
以下では、集中化されたWLANアーキテクチャのファミリー内の調査データ、つまりローカルMAC、スプリットMAC、およびリモートMACアプローチの3つの主要なバリアントについて説明します。各アプローチについて、さまざまな機能のマッピング特性を各ベンダーのネットワークエンティティに提供します。ローカルMAC、スプリットMAC、およびリモートMACの命名は、関数、特に802.11 Mac関数がネットワークエンティティにマッピングされる方法を反映しています。ローカルMACは、Mac機能がそのままでWTPSにローカルであることを示していますが、リモートMACはMacがWTPからネットワーク内のリモートACに移動したことを示します。スプリットMACは、主にリアルタイム感度のラインに沿って、WTPSとACSの間でMacが分割されていることを示しています。通常、分割されたMacベンダーは、非リアルタイム関数をACSに残しながら、WTPSにリアルタイム関数を配置することを選択します。802.11は、リアルタイム関数と非リアルタイム関数を構成するものを明確に指定していないため、明確で決定的なラインは存在しません。セクション5.4に示されているように、各ベンダーにはこれについて独自の解釈があり、リアルタイムと非リアルタイムの関数の間の境界線を描く場所についていくつかの矛盾があります。ただし、ベンダーはMac機能の大部分の特性評価に同意します。たとえば、すべてのベンダーはDCFをリアルタイム関数として分類します。
The differences among Local MAC, Split MAC and Remote MAC architectures are shown graphically in the following figure:
ローカルMAC、スプリットMAC、およびリモートMACアーキテクチャの違いは、次の図にグラフィカルに示されています。
+--------------+--- +---------------+--- +--------------+---
| CAPWAP | | CAPWAP | | CAPWAP |
| functions |AC | functions |AC | functions |
|==============|=== |---------------| |--------------|
| | | non RT MAC | | |AC
| 802.11 MAC | |===============|=== | 802.11 MAC |
| |WTP | Realtime MAC | | |
|--------------| |---------------|WTP |==============|===
| 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP
+--------------+--- +---------------+--- +--------------+---
(a) "Local MAC" (b) "Split MAC" (c) "Remote MAC"
(a) 「ローカルマック」（b）「スプリットマック」（c）「リモートマック」
Figure 6: Three Architectural Variants within the Centralized WLAN Architecture Family
図6：集中型WLANアーキテクチャファミリー内の3つの建築バリアント
The main motivation of the Local MAC architecture model, as shown in Figure 6 (a), is to offload network access policies and management functions (CAPWAP functions described in Section 1.2) to the AC without splitting the 802.11 MAC functionality between WTPs and AC. The whole 802.11 MAC resides on the WTPs locally, including all the 802.11 management and control frame processing for the STAs. On the other hand, information related to management and configuration of the WTP devices is communicated with a centralized AC to facilitate management of the network and maintain a consistent network-wide configuration for the WTP devices.
図6（a）に示すように、ローカルMacアーキテクチャモデルの主な動機は、WTPSとAC間の802.11 Mac機能を分割せずに、ネットワークアクセスポリシーと管理機能（セクション1.2で説明したCAPWAP関数）をACにオフロードすることです。802.11 Mac全体は、STAのすべての802.11管理および制御フレーム処理を含むWTPSにローカルに存在します。一方、WTPデバイスの管理と構成に関連する情報は、ネットワークの管理を促進し、WTPデバイスの一貫したネットワーク全体の構成を維持するために集中化されたACと通信されます。
Figure 7 shows a tabular representation of the design choices made by the six vendors in the survey that follow the Local MAC approach, with respect to the above mentioned architecture considerations. "WTP-AC connectivity" shows the type connectivity between the WTPs and AC that every vendor's architecture can support. Clearly, all the vendors can support L3 routed network connectivity between WTPs and the AC, which implies that direct connections and L2 switched networks are also supported by all vendors. By '802.11 mgmt termination', and '802.11 control termination', we denote the physical network device on which processing of the 802.11 management and control frames is done respectively. All the vendors here choose to terminate 802.11 management and control frames at the WTPs. The last row of the table, '802.11 data aggregation', refers to the device on which aggregation and delivery of 802.11 data frames from one STA to another (possibly through a DS) is performed. As shown by the table, vendors make different choices as to whether all the 802.11 data traffic is aggregated and routed through the AC. The survey data shows that some vendors choose to tunnel or encapsulate all the station traffic to or from the ACs, implying that the AC also acts as the access router for this WLAN access network. Other vendors choose to separate the control and data plane by letting the station traffic be bridged or routed locally, while keeping the centralized control at the AC.
図7は、上記のアーキテクチャの考慮事項に関して、ローカルMACアプローチに続く調査の6つのベンダーによって行われた設計選択の表現を示しています。「WTP-AC接続」は、すべてのベンダーのアーキテクチャがサポートできるWTPSとACの間のタイプ接続性を示しています。明らかに、すべてのベンダーは、WTPSとAC間のL3ルーティングネットワーク接続をサポートできます。これは、直接接続とL2スイッチネットワークがすべてのベンダーによってサポートされていることを意味します。「802.11 mgmt終了」と「802.11の制御終了」までに、それぞれ802.11管理および制御フレームの処理が行われる物理ネットワークデバイスを示します。ここのすべてのベンダーは、WTPSで802.11管理および制御フレームを終了することを選択します。テーブルの最後の行である「802.11データ集約」は、あるSTAから別のSTAへの802.11データフレームの集約と配信（おそらくDSを介して）を実行するデバイスを指します。テーブルで示されているように、ベンダーは、すべての802.11データトラフィックが集計され、ACを介してルーティングされているかどうかについてさまざまな選択をします。調査データは、一部のベンダーがACSとの間のすべてのステーショントラフィックをトンネルまたはカプセル化することを選択していることを示しており、ACがこのWLANアクセスネットワークのアクセスルーターとしても機能することを意味します。他のベンダーは、ACに集中制御を維持しながら、ステーションのトラフィックを局所的に橋渡しまたはルーティングすることにより、コントロールとデータプレーンを分離することを選択します。
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
WTP-AC
connectivity L3 L3 L3 L3 L3
802.11 mgmt termination WTP WTP WTP WTP WTP
802.11 mgmt終了wtp wtp wtp wtp wtp
802.11 control termination WTP WTP WTP WTP WTP
802.11制御終了wtp wtp wtp wtp wtp
802.11 data aggregation AC AC WTP AC WTP
802.11データ集約AC AC WTP AC WTP
Figure 7: Architecture Considerations for Local MAC Architecture
図7：ローカルMacアーキテクチャのアーキテクチャに関する考慮事項
Figure 8 reveals that most of the CAPWAP functions, as described in Section 1.2, are implemented at the AC with help from WTPs to monitor RF channels, and collect statistics and state information from the STAs, as the AC offers the advantages of network-wide visibility, which is essential for many of the control, configuration, and value-added services.
図8は、セクション1.2で説明されているように、ACがRFチャネルを監視し、STAから統計と状態情報を収集するためにWTPSのヘルプを使用してACに実装されていることが、ACがネットワーク全体の利点を提供するため、ACに実装されていることを明らかにしています。可視性。これは、制御、構成、付加価値サービスの多くに不可欠です。
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
RF
Monitoring WTP WTP AC/WTP WTP WTP
RF Config. AC AC AC AC AC
rf config。AC AC AC AC AC
WTP config. AC AC AC AC AC
wtp config。AC AC AC AC AC
WTP Firmware AC AC AC AC AC
WTPファームウェアAC AC AC AC AC
STA state info database AC AC/WTP AC/WTP AC/WTP AC
STA STATE情報データベースAC/WTP AC/WTP AC/WTP AC
AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP
AC/WTP相互信authing。AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP
Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture
図8：ローカルMacアーキテクチャのCapWap関数のマッピング
The matrix in Figure 9 shows that most of the 802.11 functions are implemented at the WTPs for Local MAC Architecture, with some minor differences among the vendors regarding distribution service, 802.11e scheduling, and 802.1X/EAP authentication. The difference in distribution service is consistent with that described earlier regarding "802.11 data aggregation" in Figure 7.
図9のマトリックスは、802.11関数のほとんどがローカルMacアーキテクチャ用のWTPで実装されており、流通サービス、802.11eスケジューリング、802.1x/EAP認証に関するベンダーの間でいくつかの小さな違いがあることを示しています。分布サービスの違いは、図7の「802.11データ集約」に関する前述の違いと一致しています。
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
Distribution
Service AC AC WTP AC WTP
Integration Service WTP WTP WTP WTP WTP
統合サービスWTP WTP WTP WTP WTP
Beacon Generation WTP WTP WTP WTP WTP
ビーコン生成WTP WTP WTP WTP WTP
Probe Response WTP WTP WTP WTP WTP
プローブ応答WTP WTP WTP WTP WTP
Power mgmt Packet Buffering WTP WTP WTP WTP WTP
Power MGMTパケットバッファリングWTP WTP WTP WTP WTP
Fragmentation/ Defragment. WTP WTP WTP WTP WTP
フラグメンテーション/デフラグ。wtp wtp wtp wtp wtp
Association Disassoc. Reassociation AC WTP WTP WTP WTP
協会の分離。再配分AC WTP WTP WTP WTP
WME/11e
--------------
classifying AC WTP
scheduling WTP AC/WTP WTP WTP WTP
WTP AC/WTP WTP WTP WTPのスケジューリング
queuing WTP WTP WTP WTP
Authentication
and Privacy
--------------
802.1X/EAP AC AC AC/WTP AC AC/WTP
Keys Management AC AC WTP AC AC
キー管理AC AC WTP AC AC
802.11 Encryption/ Decryption WTP WTP WTP WTP WTP
802.11暗号化/復号化wtp wtp wtp wtp wtp
Figure 9: Mapping of 802.11 Functions for Local MAC Architecture
図9：ローカルMacアーキテクチャの802.11関数のマッピング
From Figures 7, 8, and 9, it is clear that differences among vendors in the Local MAC Architecture are relatively minor, and most of the functional mapping appears to be common across vendors.
図7、8、および9から、ローカルMacアーキテクチャのベンダー間の違いは比較的マイナーであり、機能マッピングのほとんどはベンダー全体で一般的であると思われます。
As depicted in Figure 6 (b), the main idea behind the Split MAC architecture is to implement part of the 802.11 MAC functionality on a centralized AC instead of the WTPs, in addition to providing the required services for managing and monitoring the WTP devices. Usually, the decision of which functions of the 802.11 MAC need to be provided by the AC is based on the time-criticality of the services considered.
図6（b）に示すように、Split Macアーキテクチャの背後にある主なアイデアは、WTPデバイスの管理と監視に必要なサービスを提供することに加えて、WTPSの代わりに集中化されたACに802.11 Mac機能の一部を実装することです。通常、802.11 Macの関数がACによって提供される必要がある決定は、考慮されるサービスの時間的批判に基づいています。
In the Split MAC architecture, the WTP terminates the infrastructure side of the wireless physical link, provides radio-related management, and also implements time-critical functionality of the 802.11 MAC. In addition, the non-realtime management functions are handled by a centralized AC, along with higher level services, such as configuration, QoS, policies for load balancing, and access control lists. The key distinction between Local MAC and Split MAC relates to non-realtime functions: in Split MAC architecture, the AC terminates 802.11 non realtime functions, whereas in Local MAC architecture, the WTP terminates the 802.11 non-realtime functions and consequently sends appropriate messages to the AC.
スプリットMACアーキテクチャでは、WTPはワイヤレス物理リンクのインフラストラクチャ側の側面を終了し、無線関連の管理を提供し、802.11 Macの時間的批判的な機能を実装します。さらに、非リアルタイム管理関数は、構成、QoS、ロードバランスのポリシー、アクセス制御リストなどのより高いレベルのサービスとともに、集中化されたACによって処理されます。ローカルMACとスプリットMACの重要な区別は、非リアルタイム関数に関連しています。分割MACアーキテクチャでは、ACは802.11非リアルタイム機能を終了しますが、ローカルMACアーキテクチャでは、WTPは802.11非リアルタイム機能を終了し、結果として適切なメッセージを送信します。AC。
There are several motivations for taking the Split MAC approach. The first is to offload functionality that is specific and relevant only to the locality of each BSS to the WTP, in order to allow the AC to scale to a large number of 'light weight' WTP devices. Moreover, realtime functionality is subject to latency constraints and cannot tolerate delays due to transmission of 802.11 control frames (or other realtime information) over multiple-hops. The latter would limit the available choices for connectivity between the AC and the WTP. Therefore, the realtime criterion is usually employed to separate MAC services between the devices. Another consideration is cost reduction of the WTP to make it as cheap and simple as possible. Finally, moving functions like encryption and decryption to the AC reduces vulnerabilities from a compromised WTP, since user encryption keys no longer reside on the WTP. As a result, any advancements in security protocol and algorithm designs do not necessarily obsolete the WTPs; the ACs implement the new security schemes instead, which simplifies the management and update task. Additionally, the network is protected against LAN-side eavesdropping.
スプリットMACアプローチをとるには、いくつかの動機があります。1つ目は、ACが多数の「軽量」WTPデバイスにスケーリングできるようにするために、各BSSの局所性にのみ具体的かつ関連性のある機能性をオフロードすることです。さらに、リアルタイムの機能はレイテンシの制約の対象となり、複数のホップを介した802.11コントロールフレーム（またはその他のリアルタイム情報）の送信により、遅延を許容することはできません。後者は、ACとWTP間の接続のために利用可能な選択肢を制限します。したがって、リアルタイムの基準は通常、デバイス間でMacサービスを分離するために採用されます。もう1つの考慮事項は、WTPをコスト削減して、できるだけ安くてシンプルにすることです。最後に、ユーザー暗号化キーがWTPに存在しなくなったため、暗号化やACへの復号化などの機能は、侵害されたWTPから脆弱性を減らします。その結果、セキュリティプロトコルとアルゴリズムの設計の進歩は、必ずしもWTPを廃止するものではありません。ACSは代わりに新しいセキュリティスキームを実装し、管理タスクと更新タスクを簡素化します。さらに、ネットワークはLAN側の盗聴から保護されています。
Since there is no clear definition in the 802.11 specification as to which 802.11 MAC functions are considered "realtime", each vendor interprets this in their own way. Most vendors agree that the following services of 802.11 MAC are examples of realtime services, and are chosen to be implemented on the WTPs.
802.11 Mac関数が「リアルタイム」と見なされる802.11仕様に明確な定義はないため、各ベンダーは独自の方法でこれを解釈します。ほとんどのベンダーは、802.11 Macの次のサービスがリアルタイムサービスの例であり、WTPで実装されるように選択されていることに同意します。
o Beacon Generation
o ビーコン生成
o Probe Response/Transmission
o プローブ応答/伝送
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o コントロールフレームの処理：RTS/CTS/ACK/PS-POLL/CF-END/CF-ack
o Synchronization
o 同期
o Retransmissions
o 再送信
o Transmission Rate Adaptation
o 伝送速度の適応
The following list includes examples of non-realtime MAC functions as interpreted by most vendors:
次のリストには、ほとんどのベンダーによって解釈される非リアルタイムMAC関数の例が含まれています。
o Authentication/De-authentication
o 認証/免除
o Association/Disassociation/Reassociation/Distribution
o 関連/分離/再配分/分布
o Integration Services: Bridging between 802.11 and 802.3
o 統合サービス：802.11から802.3の橋渡し
o Privacy: 802.11 Encryption/Decryption
o プライバシー：802.11暗号化/復号化
o Fragmentation/Defragmentation
o 断片化/解体
However, some vendors may choose to classify some of the above "non-realtime" functions as realtime functions in order to support specific applications with strict QoS requirements. For example, Reassociation is sometimes implemented as a "realtime" function to support VoIP applications.
ただし、一部のベンダーは、上記の「非リアルタイム」関数の一部をリアルタイム関数として分類することを選択して、厳密なQoS要件を持つ特定のアプリケーションをサポートすることを選択できます。たとえば、再配分は、VoIPアプリケーションをサポートする「リアルタイム」関数として実装される場合があります。
The non-realtime aspects of the 802.11 MAC are handled by the AC through the processing of raw 802.11 management frames (Split MAC). The following matrix in Figure 10 offers a tabular representation of the design choices made by the six vendors that follow the Split MAC design regarding the architecture considerations. While most vendors support L3 connectivity between WTPs and ACs, some can only support L2 switched connections due to the tighter delay constraint resulting from splitting MAC between two physical entities across a network. In Figure 7, it is clear that the WTP processes the 802.11 control frames in both the Split MAC and Local MAC. The difference between the two lies in the termination point for 802.11 management frames. Local MAC terminates 802.11 management frames at WTP, while at least some of the 802.11 management frames are terminated at the AC for the Split MAC Architecture. Since in most cases WTP devices are IP-addressable, any of the direct connection, L2-switched, or L3-routed connections of Section 1.2 can be used. If only Ethernet-encapsulation is performed (e.g., as in Architecture 4), then only direct connection and L2-switched connections are supported.
802.11 Macの非リアルタイムの側面は、RAW 802.11管理フレーム（Split Mac）の処理を通じてACによって処理されます。図10の次のマトリックスは、アーキテクチャの考慮事項に関するスプリットMACデザインに続く6つのベンダーが作成した設計選択の表現を表現しています。ほとんどのベンダーは、WTPSとACS間のL3接続をサポートしていますが、ネットワーク上の2つの物理エンティティ間でMACを分割することに起因するより緊密な遅延制約により、L2スイッチされた接続のみをサポートできます。図7では、WTPがスプリットMACとローカルMACの両方の802.11コントロールフレームを処理することは明らかです。2つの間の違いは、802.11管理フレームの終了点にあります。ローカルMACはWTPで802.11の管理フレームを終了しますが、少なくとも802.11の管理フレームの一部は、分割MACアーキテクチャのACで終了します。ほとんどの場合、WTPデバイスはIPアドレス可能であるため、セクション1.2の直接接続、L2スイッチ、またはL3ルーティングの接続を使用できます。イーサネットのカプセル化のみが実行される場合（たとえば、アーキテクチャ4のように）、直接接続とL2スイッチの接続のみがサポートされます。
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
WTP-AC
connectivity L3 L3 L3 L2 L3 L3
802.11 mgmt termination AC AC AC AC AC/WTP AC
802.11 mgmt終了AC AC AC AC/WTP AC
802.11 control termination WTP WTP WTP WTP WTP WTP
802.11制御終了wtp wtp wtp wtp wtp wtp
802.11 data aggregation AC AC AC AC AC AC
802.11データ集約AC AC AC AC AC AC
Figure 10: Architecture Considerations for Split MAC Architecture
図10：分割Macアーキテクチャのアーキテクチャに関する考慮事項
Similar to the Local MAC Architecture, the matrix in Figure 11 shows that most of the CAPWAP control functions are implemented at the AC. The exception is RF monitoring, and in some cases RF configuration, which are performed locally at the WTPs.
ローカルMacアーキテクチャと同様に、図11のマトリックスは、CapWap制御機能のほとんどがACで実装されていることを示しています。例外は、RFモニタリング、場合によってはWTPSでローカルに実行されるRF構成です。
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
RF
Monitoring WTP WTP WTP WTP WTP WTP
RF Config. AC/WTP AC/WTP AC AC AC
rf config。AC/WTP AC/WTP AC AC AC
WTP config. AC AC AC AC AC
wtp config。AC AC AC AC AC
WTP Firmware AC AC AC AC AC
WTPファームウェアAC AC AC AC AC
STA state info database AC AC AC AC AC
STA STATE情報データベースAC AC AC AC
AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP
AC/WTP相互信authing。AC/WTP AC/WTP AC/WTP AC/WTP
Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture
図11：分割MacアーキテクチャのCapWap関数のマッピング
The most interesting matrix for Split MAC Architecture is the Functional Distribution Matrix for 802.11 functions, as shown below in Figure 12. Vendors map the functions onto the WTPs and AC with a certain regularity. For example, all vendors choose to implement Distribution, Integration Service at the AC, along with 802.1X/EAP authentication and keys management. All vendors also choose to implement beacon generation at WTPs. On the other hand, vendors sometimes choose to map many of the other functions differently. Therefore, Split MAC Architectures are not consistent regarding the exact way the MAC is split.
図12に示すように、スプリットMACアーキテクチャの最も興味深いマトリックスは、802.11関数の関数分布マトリックスです。ベンダーは、機能をWTPSにマッピングし、ACを特定の規則性にマッピングします。たとえば、すべてのベンダーは、802.1x/EAP認証とキー管理とともに、ACでの配布、統合サービスを実装することを選択します。すべてのベンダーは、WTPSでビーコン生成を実装することも選択します。一方、ベンダーは、他の機能の多くを異なる方法でマッピングすることを選択する場合があります。したがって、分割されたMACアーキテクチャは、Macが分割される正確な方法に関して一貫していません。
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ------ ----- -----
Distribution
Service AC AC AC AC AC AC
Integration Service AC AC AC AC AC AC
統合サービスAC AC AC AC AC AC
Beacon Generation WTP WTP WTP WTP WTP WTP
ビーコン生成wtp wtp wtp wtp wtp wtp
Probe Response WTP AC/WTP WTP WTP WTP WTP
プローブ応答wtp ac/wtp wtp wtp wtp wtp
Power mgmt Packet Buffering WTP WTP WTP AC AC/WTP WTP
POWERMGMTパケットバッファリングWTP WTP WTP AC AC/WTP WTP
Fragmentation Defragment. WTP WTP AC AC AC
断片化の脱線。WTP WTP AC AC AC
Association Disassoc. Reassociation AC AC AC AC WTP AC
協会の分離。再配信AC AC AC AC WTP AC
WME/11e
--------------
classifying AC AC AC AC
scheduling WTP/AC AC WTP AC AC WTP/AC
WTP/AC AC WTP AC AC WTP/ACのスケジューリング
queuing WTP/AC WTP WTP AC WTP WTP
Queuing WTP/AC WTP WTP AC WTP WTP
Authentication
and Privacy
--------------
802.1X/EAP AC AC AC AC AC AC
802.1x/EAP AC AC AC AC AC AC
Keys Management AC AC AC AC AC AC
キー管理AC AC AC AC AC AC
802.11 Encryption/ Decryption WTP AC WTP AC AC AC
802.11暗号化/復号化WTP AC WTP AC AC AC AC AC AC
Figure 12: Mapping of 802.11 Functions for Split MAC Architecture
図12：分割Macアーキテクチャの802.11関数のマッピング
One of the main motivations for the Remote MAC Architecture is to keep the WTPs as light weight as possible, by having only the radio interfaces on the WTPs and offloading the entire set of 802.11 MAC functions (including delay-sensitive ones) to the Access Controller. This leaves all the complexities of the MAC and other CAPWAP control functions to the centralized controller.
リモートMACアーキテクチャの主な動機の1つは、WTPSに無線インターフェイスのみを持ち、802.11 Mac機能（遅延敏感な機能を含む）のセット全体をアクセスコントローラーにオフロードすることにより、WTPSを可能な限り軽量に保つことです。。これにより、Macおよびその他のCapWap制御機能のすべての複雑さが集中コントローラーに残されます。
The WTP acts only as a pass-through between the Wireless LAN clients (STA) and the AC, though they may have an additional feature to convert the frames from one format (802.11) to the other (i.e., Ethernet, TR, Fiber). The centralized controller provides network monitoring, management and control, an entire set of 802.11 AP services, security features, resource management, channel selection features, and guarantees Quality of Service to the users. Because the MAC is separated from the PHY, we call this the "Remote MAC Architecture". Typically, such architecture is deployed with special attention to the connectivity between the WTPs and AC so that the delay is minimized. The Radio over Fiber (RoF) from Architecture 5 is an example of Remote MAC Architecture.
WTPは、ワイヤレスLANクライアント（STA）とACの間のパススルーとしてのみ機能しますが、1つの形式（802.11）から他の形式（イーサネット、TR、ファイバー）にフレームを変換する追加機能がある場合があります。。集中コントローラーは、ネットワーク監視、管理、および制御、802.11 APサービス、セキュリティ機能、リソース管理、チャネル選択機能のセット全体を提供し、ユーザーにサービスの品質を保証します。MacはPhyから分離されているため、これを「リモートMacアーキテクチャ」と呼びます。通常、このようなアーキテクチャは、WTPSとACの間の接続性に特に注意して展開され、遅延が最小化されます。アーキテクチャ5のラジオオーバーファイバー（ROF）は、リモートMacアーキテクチャの例です。
Two commonalities across all three Centralized Architectures (Local MAC, Split MAC, and Remote MAC) are:
3つの集中アーキテクチャすべて（ローカルMAC、スプリットMAC、およびリモートMAC）の2つの共通点は次のとおりです。
o Most of the CAPWAP functions related to network control and configuration reside on the AC.
o ネットワーク制御と構成に関連するCAPWAP関数のほとんどは、ACに存在します。
o IEEE 802.11 PHY resides on the WTP.
o IEEE 802.11 PhyはWTPに居住しています。
There is a clear difference between Remote MAC and the other two Centralized Architectures (namely, Local MAC and Split MAC), as the 802.11 MAC is completely separated from the PHY in the former, while the other two keep some portion of the MAC functions together with PHY at the WTPs. The implication of PHY and MAC separation is that it severely limits the kind of interconnection between WTPs and ACs, so that the 802.11 timing constraints are satisfied. As pointed out earlier, this usually results in tighter constraint over the interconnection between WTP and AC for the Remote MAC Architecture. The advantage of Remote MAC Architecture is that it offers the lightest possible WTPs for certain deployment scenarios.
802.11 Macは前者のPhyから完全に分離されているため、リモートMacと他の2つの集中アーキテクチャ（つまり、ローカルMacとSplit Mac）には明確な違いがあります。WTPSでPhyと。PHYとMACの分離の意味は、WTPSとACS間の相互接続の種類を厳しく制限しているため、802.11タイミングの制約が満たされることです。先に指摘したように、これは通常、リモートMacアーキテクチャのWTPとACの相互接続に対するより厳しい制約をもたらします。リモートMacアーキテクチャの利点は、特定の展開シナリオに可能な限り軽量のWTPを提供することです。
The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 to Figure 10. The commonality is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that the WTP terminates only the 802.11 control frames in the Split MAC, while the WTP may terminate all 802.11 frames in the Local MAC. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC and by the WTP in the Local MAC, as shown in Figures 9 and 12, respectively.
ローカルMACとスプリットMACの共通性と違いは、図7を図10と比較することで最も明確に見られます。ローカルMACとスプリットMACの主な違いは、WTPがスプリットMACの802.11コントロールフレームのみを終了し、WTPはローカルMACのすべての802.11フレームを終了する可能性があることです。この違いの興味深い結果は、802.11から802.3フレームの間の橋渡しを基本的に指す統合サービスが、それぞれ図9と12に示すように、スプリットMACのACとローカルMACのWTPによって実装されることです。。
As a second note, the Distribution Service, although usually provided by the AC, can also be implemented at the WTP in some Local MAC architectures. This approach is meant to increase performance in delivering STAs data traffic by avoiding tunneling it to the AC, and relaxing the dependency of the WTP from the AC. Therefore, it is possible for the data and control planes to be separated in the Local MAC Architecture.
2番目のメモとして、通常はACによって提供される分布サービスは、一部のローカルMACアーキテクチャのWTPで実装することもできます。このアプローチは、STASデータトラフィックをACにトンネルすることを避け、ACからのWTPの依存関係を緩和することにより、STASデータトラフィックを提供するパフォーマンスを向上させることを目的としています。したがって、データと制御プレーンをローカルMacアーキテクチャで分離する可能性があります。
Even though all the 802.11 traffic is aggregated at ACs in the case of Split MAC Architecture, the data and control planes can still be separated by employing multiple ACs. For example, one AC can implement most of the CAPWAP functions (control plane), while other ACs can be used for 802.11 frames bridging (data plane).
Split Macアーキテクチャの場合、すべての802.11トラフィックはACSで集約されていますが、データと制御プレーンは、複数のACSを使用することで引き続き分離できます。たとえば、1つのACはほとんどのCAPWAP関数（コントロールプレーン）を実装できますが、もう1つのACは802.11フレームブリッジング（データプレーン）に使用できます。
Each of the three architectural variants may be advantageous for certain deployment scenarios. While the Local MAC retains most of the STA's state information at the local WTPs, Remote MAC centralizes most of the state into the back-end AC. Split MAC sits somewhat in the middle of this spectrum, keeping some state information locally at the WTPs, and the rest centrally at the AC. Many factors should be taken into account to determine the exact balance desired between the centralized and decentralized state. The impact of such balance on network manageability is currently a matter of dispute within the technical community.
3つのアーキテクチャバリエーションのそれぞれは、特定の展開シナリオにとって有利な場合があります。ローカルMACはローカルWTPSでSTAの州情報のほとんどを保持していますが、リモートMACは州のほとんどをバックエンドACに集中させます。Split Macは、このスペクトルの中央にある程度座り、WTPSで地元の情報を局所的に保持し、残りはACで中央に保持します。集中状態と分散状態の間で望まれる正確なバランスを決定するために、多くの要因を考慮する必要があります。このようなバランスがネットワークの管理可能性に与える影響は、現在、技術コミュニティ内での紛争の問題です。
Before any messages can be exchanged between an AC and WTP, the WTP needs to discover, authenticate, and register with the AC first, then download the firmware and establish a control channel with the AC. Message exchanges between the WTP and AC for control and configuration can happen after that. The following list outlines the basic operations that are typically performed between the WTP and the AC in their typical order:
ACとWTPの間でメッセージを交換する前に、WTPは最初にACに発見、認証、登録する必要があります。次にファームウェアをダウンロードして、ACでコントロールチャネルを確立する必要があります。その後、制御と構成のためのWTPとACの間のメッセージ交換が行われる可能性があります。次のリストは、通常、WTPとACの間で通常の順序で実行される基本操作の概要を示しています。
1. Discovery: The WTPs discover the AC with which they will be bound to and controlled by. The discovery procedure can employ either static or dynamic configuration. In the latter case, a protocol is used in order for the WTP to discover candidate AC(s).
1. 発見：WTPは、それらに拘束され、制御されるACを発見します。発見手順は、静的または動的構成のいずれかを使用できます。後者の場合、WTPが候補AC（S）を発見するためにプロトコルが使用されます。
2. Authentication: After discovery, the WTP device authenticates itself with the AC. However, mutual authentication, in which the WTP also authenticates the AC, is not always supported since some vendors strive for zero-configuration on the WTP side. This is not necessarily secure as it leaves the possible vulnerability of the WTP being attached to a rogue AC.
2. 認証：発見後、WTPデバイスはACで認証されます。ただし、WTPがACを認証する相互認証は、一部のベンダーがWTP側のゼロ構成を目指して努力しているため、必ずしもサポートされていません。これは、WTPが不正なACに取り付けられている可能性のある脆弱性を残すため、必ずしも安全ではありません。
3. WTP Association: After successful authentication, a WTP registers with the AC in order to start receiving management and configuration messages.
3. WTP Association：認証が成功した後、WTPがACに登録して、管理および構成メッセージの受信を開始します。
4. Firmware Download: After successful association, the WTP may pull, or the AC may push, the WTPs firmware, which may be protected in some manner, such as digital signatures.
4. ファームウェアのダウンロード：関連性が成功した後、WTPがプルするか、ACがプッシュする場合があります。これは、デジタル署名などの何らかの方法で保護される場合があります。
5. Control Channel Establishment: The WTP establishes either an IP-tunnel or performs Ethernet encapsulation with the AC in order to transfer data traffic and management frames.
5. 制御チャネルの確立：WTPは、データトラフィックと管理フレームを転送するために、IPトンネルを確立するか、ACでイーサネットカプセル化を実行します。
6. Configuration Download: Following the control channel establishment process, the AC may push configuration parameters to the WTPs.
6. 構成のダウンロード：制御チャネルの確立プロセスに続いて、ACは構成パラメーターをWTPSにプッシュする場合があります。
Given the varied distribution of functionalities for the Centralized Architecture, as surveyed in Section 4.3, it is obvious that an extra network binding is created between the WTP and the AC. This brings new and unique security issues and subsequent requirements.
セクション4.3で調査したように、集中アーキテクチャの機能のさまざまな分布を考えると、WTPとACの間に追加のネットワークバインディングが作成されることは明らかです。これにより、新しい独自のセキュリティの問題とその後の要件がもたらされます。
The survey shows clearly that the termination point for "over the air" 802.11 encryption [4] can be implemented either in the WTP or in the AC. Furthermore, the 802.1X/EAP [6] functionality is distributed between the WTP and the AC where, in most cases, the AC performs the necessary functions as the authenticator in the 802.1X exchange.
この調査では、「Over the Air」802.11暗号化[4]の終了点がWTPまたはACで実装できることを明確に示しています。さらに、802.1x/EAP [6]機能は、WTPとACの間に分布され、ほとんどの場合、ACは802.1X Exchangeの認証機として必要な機能を実行します。
If the STA and AC are the parties in the 4-way handshake (defined in [4]), and 802.11i traffic encryption terminates at the WTP, then the Pairwise Transient Key (PTK) has to be transferred from the AC to the WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material.
STAとACが4ウェイハンドシェイク（[4]で定義）の当事者であり、802.11iトラフィック暗号化がWTPで終了する場合、ペアワイズトランジェントキー（PTK）をACからWTPに転送する必要があります。。キーイング材料はWTPSの制御とプロビジョニングの一部であるため、キーイン材を輸送するために制御フレーム用の安全な暗号化されたトンネルが使用されます。
The centralized model encourages AC implementations to use one PMK for many different WTPs. This practice facilitates speedy transition by an STA from one WTP to another that is connected to the same AC without establishing a separate PMK. However, this leaves the STA in a difficult position, as the STA cannot distinguish between a compromised PMK and one that is intentionally being shared. This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for this resolution is to be determined by the IEEE 802 and IETF liaisons.
集中モデルは、AC実装が多くの異なるWTPに1つのPMKを使用することを奨励しています。このプラクティスは、別のPMKを確立せずに同じACに接続されているあるWTPから別のWTPへのSTAによる迅速な移行を促進します。ただし、STAは侵害されたPMKと意図的に共有されているPMKを区別できないため、STAは困難な位置になります。この問題は解決する必要がありますが、解決策はCAPWAPワーキンググループの範囲を超えています。この解決策の会場は、IEEE 802およびIETF Liaisonsによって決定されます。
When the 802.11i encryption/decryption is performed in the AC, the key exchange and state transitions occur between the AC and the STA. Therefore, there is no need to transfer any crypto material between the AC and the WTP.
ACで802.11iの暗号化/復号化が実行されると、ACとSTAの間にキー交換と状態の移行が発生します。したがって、ACとWTPの間に暗号材料を転送する必要はありません。
Regardless of where the 802.11i termination point occurs, the Centralized WLAN Architecture records two practices for "over the wire" client data security. In some cases there is an encrypted tunnel (IPsec or SSL) between the WTP and AC, which assumes that the security boundary is in the AC. In other cases, an end-to-end mutually authenticated secure VPN tunnel is assumed between the client and AC, other security gateway, or end host entity.
802.11i終了ポイントが発生する場所に関係なく、集中化されたWLANアーキテクチャは、「Over the Wire」クライアントデータセキュリティの2つのプラクティスを記録します。場合によっては、WTPとACの間に暗号化されたトンネル（IPSECまたはSSL）があり、セキュリティ境界がACにあると仮定します。それ以外の場合、クライアントとAC、その他のセキュリティゲートウェイ、またはエンドホストエンティティの間で、エンドツーエンドの相互に認証された安全なVPNトンネルが想定されます。
In order for the CAPWAP functions to be implemented in the Centralized WLAN Architecture, a control channel is necessary between the WTP and AC.
CAPWAP関数を集中化されたWLANアーキテクチャに実装するには、WTPとACの間に制御チャネルが必要です。
To address potential security threats against the control channel, existing implementations feature one or more of the following security mechanisms:
制御チャネルに対する潜在的なセキュリティの脅威に対処するために、既存の実装は、次のセキュリティメカニズムの1つ以上を備えています。
1. Secure discovery of WTP and AC.
1. WTPとACの安全な発見。
2. Authentication of the WTPs to the ACs (and possibly mutual authentication).
2. ACSへのWTPの認証（およびおそらく相互認証）。
3. Confidentiality, integrity, and replay protection of control channel frames.
3. 制御チャネルフレームの機密性、完全性、およびリプレイ保護。
4. Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets and state.
4. 秘密と状態を安全に設定およびリセットするためのメカニズムを含む、WTPとACSの安全な管理。
Discovery and authentication of WTPs are addressed in the submissions by implementing authentication mechanisms that range from X.509 certificates, AAA authentication to pre-shared credential authentication. In all cases, confidentiality, integrity, and protection against man-in-the-middle attacks of the control frames are addressed by a secure encrypted tunnel between the WTP and AC(s), utilizing keys derived from the authentication methods mentioned previously. Finally, one of the motivations for the Centralized WLAN Architecture is to minimize the storage of cryptographic and security sensitive information, in addition to operational configuration parameters within the WTPs. It is for that reason that the majority of the submissions under the Centralized Architecture category have employed a post WTP authenticated discovery phase of configuration provisioning, which in turn protects against the theft of WTPs.
WTPの発見と認証は、X.509証明書、AAA認証から事前共有資格認証までの範囲の認証メカニズムを実装することにより、提出物に対処されます。すべての場合において、制御フレームの中間攻撃に対する機密性、完全性、および保護は、前述の認証方法から派生したキーを使用して、WTPとAC（S）の間の安全な暗号化されたトンネルによって対処されます。最後に、集中型WLANアーキテクチャの動機の1つは、WTPS内の運用構成パラメーターに加えて、暗号化に敏感な情報の保存を最小限に抑えることです。そのため、集中化されたアーキテクチャカテゴリの下での提出の大部分は、構成プロビジョニングのWTP認証された発見フェーズを採用しており、WTPの盗難から保護しています。
To provide comprehensive radio coverage, WTPs are often installed in locations that are difficult to secure physically; it is relatively easier to secure the AC physically. If high-value secrets, such as a RADIUS shared secret, are stored in the AC instead of WTPs, then the physical loss of an WTP does not compromise these secrets. Hence, the Centralized Architecture may reduce the security consequences of a stolen WTP. On the other hand, concentrating all the high-value secrets in one place makes the AC an attractive target that requires strict physical, procedural, and technical controls to protect the secrets.
包括的な無線カバレッジを提供するために、WTPは多くの場合、物理的に保護するのが難しい場所にインストールされます。ACを物理的に保護するのは比較的簡単です。半径の共有秘密などの高価値の秘密がWTPの代わりにACに保存されている場合、WTPの物理的損失はこれらの秘密を妥協しません。したがって、集中化されたアーキテクチャは、盗まれたWTPのセキュリティ結果を減らす可能性があります。一方、すべての価値の高い秘密を1つの場所に集中させると、ACが秘密を保護するために厳格な物理的、手続き的、技術的なコントロールを必要とする魅力的なターゲットとなります。
Out of the sixteen architecture survey submissions, three belong to the Distributed Mesh Architecture family. An example of the Distributed Mesh Architecture is shown in Figure 13, and reflects some of the common characteristics found in these three submissions.
16のアーキテクチャ調査の提出のうち、3つは分散メッシュアーキテクチャファミリーに属します。分散メッシュアーキテクチャの例を図13に示し、これら3つの提出物に見られる一般的な特性の一部を反映しています。
+-----------------+ +-----------------+
| 802.11 BSS 1 | | 802.11 BSS 2 |
| ... | | ... |
| +---------+ | | +---------+ |
+----|mesh node|--+ +----|mesh node|--+
+-+---+---+ +-+-+-----+
| | | |
| | | | +----------+
| +-----------------------+ | Ethernet | Ethernet |
| 802.11 wireless links | +--------+ Switch |
| +-----------------------+ | | | |
| | | | | +----------+
+-+---+---+ +-+--+----+
+----|mesh node|--+ +----|mesh node|--+
| +---------+ | | +---------+ |
| ... | | ... |
| 802.11 BSS 4 | | 802.11 BSS 3 |
+-----------------+ +-----------------+
Figure 13: Example of Distributed Mesh Architecture
図13：分散メッシュアーキテクチャの例
To provide wider wireless coverage, mesh nodes in the network may act as APs to client stations in their respective BSS, as well as traffic relays to neighboring mesh nodes via 802.11 wireless links. It is also possible that some mesh nodes in the network may serve only as wireless traffic relays for other mesh nodes, but not as APs for any client stations. Instead of pulling Ethernet cable connections to every AP, wireless mesh networks provide an attractive alternative to relaying backhaul traffic.
より広いワイヤレスカバレッジを提供するために、ネットワーク内のメッシュノードは、それぞれのBSSのクライアントステーションへのAPSとして機能し、802.11ワイヤレスリンクを介して隣接するメッシュノードへのトラフィックリレーが機能する場合があります。ネットワーク内の一部のメッシュノードは、他のメッシュノードのワイヤレストラフィックリレーとしてのみ機能する可能性がありますが、クライアントステーションのAPとしてはそうではありません。すべてのAPにイーサネットケーブル接続を引く代わりに、ワイヤレスメッシュネットワークは、バックホールトラフィックを中継する魅力的な代替品を提供します。
Mesh nodes can also keep track of the state of their neighboring nodes, or even nodes beyond their immediate neighborhood by exchanging information periodically amongst them; this way, mesh nodes can be fully aware of the dynamic network topology and RF conditions around them. Such peer-to-peer communication model allows mesh nodes to actively coordinate among themselves to achieve self-configuration and self-healing. This is the major distinction between this Distributed Architecture family and the Centralized Architecture -- much of the CAPWAP functions can be implemented across the mesh nodes in a distributed fashion, without a centralized entity making all the control decisions.
メッシュノードは、隣接するノードの状態を追跡することも、その間の情報を定期的に交換することで、すぐ近くの近隣を越えてノードを追跡することもできます。これにより、メッシュノードは、動的ネットワークトポロジとそれらの周囲のRF条件を完全に認識できます。このようなピアツーピア通信モデルにより、メッシュノードは、自己構成と自己修復を実現するために、メッシュノードを積極的に調整できます。これは、この分散アーキテクチャファミリーと集中化されたアーキテクチャの主要な区別です。多くのCAPWAP関数は、すべての制御決定を行うことなく、分散型ファッションでメッシュノード全体で実装できます。
It is worthwhile to point out that mesh networks do not necessarily preclude the use of centralized control. It is possible that a combination of centralized and distributed control co-exists in mesh networks. Some global configuration or policy change may be better served in a coordinated fashion if some form of Access Controller (AC) exists in the mesh network (even if not the full blown version of the AC, as defined in the Centralized WLAN Architecture). For example, a centralized management entity can be used to update every mesh node's default configuration. It may also be more desirable to leave certain functions, such as user authentication to a single centralized end point (such as a RADIUS server), but mesh networks allow each mesh AP to directly talk to the RADIUS server. This eliminates the single point of failure and takes advantage of the client distribution in the network.
メッシュネットワークが必ずしも集中制御の使用を排除しないことを指摘する価値があります。メッシュネットワークで一元化されたコントロールと分散制御の共存の組み合わせが共存する可能性があります。一部のグローバルな構成またはポリシーの変更は、メッシュネットワークに何らかの形式のアクセスコントローラー（AC）が存在する場合、調整された方法でより適切に提供される場合があります（集中化されたWLANアーキテクチャで定義されているように、ACの完全な吹きバージョンではない場合でも）。たとえば、集中管理エンティティを使用して、すべてのメッシュノードのデフォルト構成を更新できます。また、ユーザー認証などの特定の機能を単一の集中エンドポイント（RADIUSサーバーなど）に残すことが望ましい場合がありますが、メッシュネットワークにより、各メッシュAPがRADIUSサーバーに直接通信できるようになります。これにより、単一の障害ポイントが排除され、ネットワーク内のクライアント配信を活用します。
The backhaul transport network of the mesh network can be either an L2 or L3 networking technology. Currently, vendors are using proprietary mesh technologies on top of standard 802.11 wireless links to enable peer-to-peer communication between the mesh nodes. Hence, there is no interoperability among mesh nodes from different vendors. The IEEE 802.11 WG has recently started a new Task Group (TGs) to define the mesh standard for 802.11.
メッシュネットワークのバックホール輸送ネットワークは、L2またはL3ネットワーキングテクノロジーのいずれかです。現在、ベンダーは標準の802.11ワイヤレスリンクに加えて独自のメッシュテクノロジーを使用して、メッシュノード間のピアツーピア通信を有効にしています。したがって、さまざまなベンダーのメッシュノード間に相互運用性はありません。IEEE 802.11 WGは最近、802.11のメッシュ標準を定義するための新しいタスクグループ（TGS）を開始しました。
Similar security concerns for client data security, as described in Section 5.8.1, also apply to the Distributed Mesh Architecture. Additionally, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain. To protect user and management data that may not be secured at layer 3, data transmission among neighboring nodes should be secured by a layer 2 mechanism of confidentiality, integrity, and replay protection.
セクション5.8.1で説明されているように、クライアントデータセキュリティに関する同様のセキュリティの懸念は、分散メッシュアーキテクチャにも適用されます。さらに、メッシュネットワークの重要なセキュリティに関する考慮事項の1つは、メッシュノードが同じ管理ドメイン内で互いに認証する必要があることです。レイヤー3で保護されていないユーザーおよび管理データを保護するには、隣接するノード間のデータ送信は、機密性、完全性、およびリプレイ保護のレイヤー2メカニズムによって保護される必要があります。
We requested existing WLAN vendors and other interested parties to submit a short description of existing or desired WLAN access network architectures to define a taxonomy of possible WLAN access network architectures. The information from the 16 submissions was condensed and summarized in this document.
既存のWLANベンダーおよびその他の利害関係者に、既存または望ましいWLANアクセスネットワークアーキテクチャの短い説明を提出して、可能なWLANアクセスネットワークアーキテクチャの分類法を定義するよう要求しました。16の提出物からの情報は凝縮され、この文書に要約されました。
New terminology has been defined wherever existing terminology was found to be either insufficient or ambiguous in describing the WLAN architectures and supporting functions listed in the document. For example, the broad set of Access Point functions has been divided into two categories: 802.11 functions, which include those that are required by the IEEE 802.11 standards, and CAPWAP functions, which include those that are not required by the IEEE 802.11, but are deemed essential for control, configuration, and management of 802.11 WLAN access networks. Another term that has caused considerable ambiguity is "Access Point", which usually reflected a physical box that has the antennas, but did not have a uniform set of externally consistent behavior across submissions. To remove this ambiguity, we have redefined the AP as the set of 802.11 and CAPWAP functions, while the physical box that terminates the 802.11 PHY is called the Wireless Termination Point.
既存の用語が、ドキュメントにリストされているWLANアーキテクチャとサポート機能を説明する際に不十分または曖昧であることがわかった場合、新しい用語が定義されています。たとえば、アクセスポイント関数の広範なセットは、IEEE 802.11標準で必要なものを含む802.11関数の2つのカテゴリと、IEEE 802.11では要求されていないものを含むCapWap関数に分割されています。802.11 WLANアクセスネットワークの制御、構成、および管理に不可欠であるとみなされます。かなりのあいまいさを引き起こした別の用語は「アクセスポイント」です。これは通常、アンテナを持つ物理ボックスを反映していますが、提出全体で外部的に一貫した動作の均一なセットはありませんでした。このあいまいさを削除するために、APを802.11およびCapWap関数のセットとして再定義しましたが、PHYを終了する物理ボックスはワイヤレス終端ポイントと呼ばれます。
Based on the submissions during the architecture survey phase, we have classified the existing WLAN architectures into three broad classes:
アーキテクチャ調査段階での提出に基づいて、既存のWLANアーキテクチャを3つの広範なクラスに分類しました。
1. Autonomous WLAN Architecture: Indicates a family of architectures in which all the 802.11 functions and, where applicable, CAPWAP functions are implemented in the WTPs.
1. 自律的なWLANアーキテクチャ：すべての802.11が機能し、該当する場合、capWap関数がWTPSに実装されるアーキテクチャのファミリーを示します。
2. Centralized WLAN Architecture: Indicates a family of architectures in which the AP functions are split between the WTPs and the AC, with the AC acting as a centralized control point for multiple WTPs.
2. 集中型WLANアーキテクチャ：AP関数がWTPとACの間で分割されるアーキテクチャのファミリーを示し、ACは複数のWTPの集中制御ポイントとして機能します。
3. Distributed WLAN Architecture: Indicates a family of architectures in which part of the control functions is implemented across a distributed network of peer entities.
3. 分散型WLANアーキテクチャ：制御機能の一部が、ピアエンティティの分散ネットワーク全体に実装されているアーキテクチャファミリーを示します。
Within the Centralized WLAN Architecture, there are a few visible sub-categories that depend on how one maps the MAC functions (at a high-level), between the WTP and the AC. Three prominent sub-categories emerged from the information in the submissions:
集中化されたWLANアーキテクチャ内には、WTPとACの間にMac機能（高レベル）をマッピングする方法に依存する目に見えるサブカテゴリがいくつかあります。提出物の情報から3つの著名なサブカテゴリが登場しました。
1. Split MAC Architecture: The 802.11 MAC functions are split between the WTP and the AC. This subgroup includes all architectures that split the 802.11 MAC functions even though individual submissions differed on the specifics of the split.
1. 分割MACアーキテクチャ：802.11 Mac関数は、WTPとACの間で分割されます。このサブグループには、個々の提出物が分割の詳細で異なっていても、802.11 Mac関数を分割するすべてのアーキテクチャが含まれています。
2. Local MAC Architecture: The entire set of 802.11 MAC functions is implemented on the WTP.
2. ローカルMACアーキテクチャ：802.11 Mac関数のセット全体がWTPに実装されています。
3. Remote MAC Architecture: The entire set of 802.11 MAC functions is implemented on the AC.
3. リモートMacアーキテクチャ：802.11 Mac関数のセット全体がACに実装されています。
The following tree diagram summarizes the architectures documented in this taxonomy.
次のツリー図は、この分類法で文書化されたアーキテクチャをまとめたものです。
+----------------+
|Autonomous |
+---------->|Architecture |
| |Family |
| +----------------+
| +--------------+
| |Local |
| +---->|MAC |
| | |Architecture |
| | +--------------+
| |
| +----------------+ | +--------------+
| |Centralized | | |Split |
+---------->|Architecture |--+---->|MAC |
| |Family | | |Architecture |
| +----------------+ | +--------------+
| |
| | +--------------+
| | |Remote |
| +---->|MAC |
| |Architecture |
| +--------------+
| +----------------+
| |Distributed Mesh|
+---------->|Architecture |
|Family |
+----------------+
A majority of the submitted WLAN access network architectures (twelve out of sixteen) followed the Centralized WLAN Architecture. All but one of the Centralized WLAN Architecture submissions were grouped into either a Split MAC Architecture or a Local MAC Architecture. One submission followed the Autonomous WLAN Architecture, and three followed the Distributed WLAN Architecture.
提出されたWLANアクセスネットワークアーキテクチャの大部分（16人中12人）が集中化されたWLANアーキテクチャに続きました。集中化されたWLANアーキテクチャの提出物の1つを除くすべてが、スプリットMacアーキテクチャまたはローカルMacアーキテクチャのいずれかにグループ化されました。1つの提出物は自律的なWLANアーキテクチャに続き、3つは分散されたWLANアーキテクチャに続きました。
The WLAN access network architectures in the submissions indicated that the connectivity assumptions were:
提出物のWLANアクセスネットワークアーキテクチャは、接続の仮定は次のとおりであることを示しました。
o Direct connection between the WTP and the AC.
o WTPとACの間の直接接続。
o L2 switched connection between the WTP and the AC.
o L2は、WTPとACの間の接続を切り替えました。
o L3 routed connection between the WTP and the AC.
o L3は、WTPとACの間の接続をルーティングしました。
o Wireless connection between the mesh nodes in the distributed mesh architecture.
o 分散メッシュアーキテクチャのメッシュノード間のワイヤレス接続。
Interoperability between equipment from different vendors is one of the fundamental problems in the WLAN market today. To achieve interoperability via open standard development, the following steps are suggested for IETF and IEEE 802.11.
さまざまなベンダーからの機器間の相互運用性は、今日のWLAN市場の根本的な問題の1つです。Open Standard Developmentを介して相互運用性を実現するには、IETFおよびIEEE 802.11について次の手順を提案します。
Using this taxonomy, a functional model of an Access Point should be defined by the new study group recently formed within the IEEE 802.11. The functional model will consist of defining functional elements of an 802.11 Access Point that are considered atomic, i.e., not subject to further splitting across multiple network elements. Such a functional model should serve as a common foundation to support the existing WLAN architectures as outlined in this taxonomy, and any further architecture development within or outside the IEEE 802.11 group. It is possible, and even recommended, that work on the functional model definition may also include impact analysis of implementing each functional element on either the WTP or the AC.
この分類法を使用して、アクセスポイントの機能モデルは、IEEE 802.11内で最近形成された新しい研究グループによって定義される必要があります。機能モデルは、原子と見なされる802.11アクセスポイントの機能要素を定義することで構成されます。つまり、複数のネットワーク要素にさらに分割されることはありません。このような機能モデルは、この分類法で概説されている既存のWLANアーキテクチャをサポートする共通の基盤として、およびIEEE 802.11グループ内外のアーキテクチャ開発をサポートする必要があります。機能モデル定義での作業には、WTPまたはACのいずれかに各機能要素を実装する影響分析が含まれる可能性があります。
As part of the functional model definition, interfaces must be defined as primitives between these functional elements. If a pair of functional elements that have an interface defined between them is being implemented on two different network entities, then a protocol specification definition between such a pair of network elements is required, and should be developed by the IETF.
機能モデル定義の一部として、インターフェイスはこれらの機能要素間のプリミティブとして定義する必要があります。それらの間に定義されたインターフェイスを持つ関数要素のペアが2つの異なるネットワークエンティティに実装されている場合、そのような1つのネットワーク要素間のプロトコル仕様定義が必要であり、IETFが開発する必要があります。
This document does not intend to provide a comprehensive threat analysis of all of the security issues with the different WLAN architectures. Nevertheless, in addition to documenting the architectures employed in the existing IEEE 802.11 products in the market, this taxonomy document also catalogues the security issues that arise and the manner in which vendors address these security threats. The WLAN architectures are broadly categorized into three families: Autonomous Architecture, Centralized Architecture, and Distributed Architecture. While Sections 4, 5, and 6 are devoted to each of these three architecture families, respectively, each section also contains a subsection to address the security issues within each architecture family.
このドキュメントは、さまざまなWLANアーキテクチャに関するすべてのセキュリティ問題の包括的な脅威分析を提供するものではありません。それにもかかわらず、市場の既存のIEEE 802.11製品で採用されているアーキテクチャの文書化に加えて、この分類法は、発生するセキュリティの問題と、ベンダーがこれらのセキュリティの脅威に対処する方法をカタログ化します。WLANアーキテクチャは、自律アーキテクチャ、集中アーキテクチャ、分散アーキテクチャの3つの家族に広く分類されています。セクション4、5、および6はそれぞれこれら3つのアーキテクチャファミリーのそれぞれに専念していますが、各セクションには各アーキテクチャファミリー内のセキュリティ問題に対処するためのサブセクションも含まれています。
In summary, the main security concern in the Autonomous Architecture is the mutual authentication between the WTP and the wired (Ethernet) infrastructure equipment. Physical security of the WTPs is also a network security concern because the WTPs contain secret information and theft of these devices could potentially compromise even the wired network.
要約すると、自律アーキテクチャの主なセキュリティ上の懸念は、WTPと有線（イーサネット）インフラストラクチャ機器の間の相互認証です。WTPSには秘密の情報が含まれており、これらのデバイスの盗難が有線ネットワークを侵害する可能性があるため、WTPSの物理的セキュリティもネットワークセキュリティの懸念事項です。
In the Centralized Architecture there are a few new security concerns due to the new network binding between the WTP and AC. The following security concerns are raised for this architecture family: keying material for mobile client traffic may need to be securely transported from the AC to WTP; secure discovery of the WTP and AC is required, as well as mutual authentication between the WTPs and AC; man-in-the-middle attacks to the control channel between WTP and AC, confidentiality, integrity and replay protection of control channel frames, and theft of WTPs for extraction of embedded secrets within. Each of the survey results for this broad architecture category has presented mechanisms to address these security issues.
集中アーキテクチャでは、WTPとACの間の新しいネットワークの結合により、いくつかの新しいセキュリティ上の懸念があります。このアーキテクチャファミリには、次のセキュリティ上の懸念が提起されています。モバイルクライアントトラフィックのためのキーイング素材は、ACからWTPにしっかりと輸送する必要がある場合があります。WTPとACの間の相互認証と同様に、WTPとACの安全な発見が必要です。WTPとACの間のコントロールチャネル、機密性、整合性、制御チャネルフレームの保護、および内部の埋め込み秘密の抽出のためのWTPの盗難、およびリプレイの間のコントロールチャネルへの中間攻撃。この幅広いアーキテクチャカテゴリの調査結果は、これらのセキュリティの問題に対処するためのメカニズムを提示しています。
The new security issue in the Distributed Mesh Architecture is the need for mesh nodes to authenticate each other before forming a secure mesh network. Encrypted communication between mesh nodes is recommended to protect both control and user data.
分散メッシュアーキテクチャの新しいセキュリティ問題は、安全なメッシュネットワークを形成する前にメッシュノードが互いに認証される必要性です。コントロールデータとユーザーデータの両方を保護するために、メッシュノード間の暗号化された通信が推奨されます。
This taxonomy is truly a collaborative effort with contributions from a large group of people. First, we want to thank all the CAPWAP Architecture Design Team members who have spent many hours in the teleconference calls, over e-mails, and in writing and reviewing the document. The full Design Team is listed here:
この分類法は、大勢の人々からの貢献との共同作業です。まず、電子メールの通話、電子メール、および文書の書面とレビューに何時間も費やしたすべてのCapWapアーキテクチャデザインチームのメンバーに感謝します。完全なデザインチームはここにリストされています：
o Peyush Agarwal STMicroelectronics Plot# 18, Sector 16A Noida, U.P 201301 India Phone: +91-120-2512021 EMail: peyush.agarwal@st.com
o Peyush Agarwal Stmicroelectronics Plot＃18、Sector 16a Noida、U.P 201301インド電話：91-120-2512021メール：peyush.agarwal@st.com
o Dave Hetherington Roving Planet 4750 Walnut St., Suite 106 Boulder, CO 80027 United States Phone: +1-303-996-7560 EMail: Dave.Hetherington@RovingPlanet.com
o Dave Hetherington Roving Planet 4750 Walnut St.、Suite 106 Boulder、Co 80027米国電話：1-303-996-7560メール：dave.hetherington@rovingplanet.com
o Matt Holdrege Strix Systems 26610 Agoura Road Calabasas, CA 91302 Phone: +1 818-251-1058 EMail: matt@strixsystems.com
o MattRege Strix Systems 26610 Agoura Road Calabasas、CA 91302電話：1 818-251-1058メール：matt@strixsystems.com
o Victor Lin Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 Phone: +1 408-579-3383 EMail: vlin@extremenetworks.com
o Victor Lin Extreme Networks 3585 Monroe Street Santa Clara、CA 95051電話：1 408-579-3383メール：vlin@extremenetworks.com
o James M. Murphy Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588 Phone: +1 925-474-2233 EMail: jmurphy@trapezenetworks.com
o ジェームズ・M・マーフィー・トレイプネットワーク5753 W. Las Positas Blvd.カリフォルニア州プレザントン94588電話：1 925-474-2233メール：jmurphy@trapezenetworks.com
o Partha Narasimhan Aruba Wireless Networks 180 Great Oaks Blvd San Jose, CA 95119 Phone: +1 408-754-3018 EMail: partha@arubanetworks.com
o Partha Narasimhan Aruba Wireless Networks 180 Great Oaks Blvd San Jose、CA 95119電話：1 408-754-3018メール：partha@arubanetworks.com
o Bob O'Hara Airespace 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2025 EMail: bob@airespace.com
o ボブ・オハラ・エアスパス110 Nortech Parkway San Jose、CA 95134電話：1 408-635-2025メール：bob@airespace.com
o Emek Sadot (see Authors' Addresses)
o Emek Sadot（著者のアドレスを参照）
o Ajit Sanzgiri Cisco Systems 170 W Tasman Drive San Jose, CA 95134 Phone: +1 408-527-4252 EMail: sanzgiri@cisco.com
o Ajit Sanzgiri Cisco Systems 170 W Tasman Drive San Jose、CA 95134電話：1 408-527-4252メール：sanzgiri@cisco.com
o Singh Chantry Networks 1900 Minnesota Court Mississauga, Ontario L5N 3C9 Canada Phone: +1 905-567-6900 EMail: isingh@chantrynetworks.com
o Singh Chantry Networks 1900 Minnesota Court Mississauga、Ontario L5N 3C9カナダ電話：1 905-567-6900メール：isingh@chantrynetworks.com
o L. Lily Yang (Editor, see Authors' Addresses)
o L.リリー・ヤン（編集者、著者の住所を参照）
o Petros Zerfos (see Authors' Addresses) In addition, we would also like to acknowledge contributions from the following individuals who participated in the architecture survey and provided detailed input data in preparation of the taxonomy: Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach, Dennis Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao Addepalli, Subhashini A. Venkataramanan, Kue Wong, Kevin Dick, Ted Kuo, and Tyan-shu Jou. It is simply impossible to write this taxonomy without the large set of representative data points that they provided to us. We would also like to thank our CAPWAP WG co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area Director, Bert Wijnen, for their unfailing support.
o Petros Zerfos（著者の住所を参照）さらに、建築調査に参加し、分類法の準備に詳細な入力データを提供した以下の個人からの貢献を認めたいと思います。、デニス・ヴォルパノ、シャンカール・ナラヤナスワミー、サイモン・バーバー、スリニバサ・ラオ・アッデパリ、スバシニ・A・ベンカタラマナン、キュー・ウォン、ケビン・ディック、テッド・クオ、ティアン・シュー・ジュウ彼らが私たちに提供した代表的なデータポイントの大規模なセットなしで、この分類法を書くことは単に不可能です。また、CapWap WGの共同議長であるMahalingam ManiとDorothy Gellertと、エリアディレクターのBert Wijnenのサポートに感謝します。
[1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE 802.11-99>.
[1] 「IEEE WLAN MACおよびPHYレイヤー仕様」、1999年8月、<IEEE 802.11-99>。
[2] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[2] O'Hara、B.、Calhoun、P。、およびJ. Kempf、「ワイヤレスアクセスポイント（CAPWAP）問題ステートメントの構成とプロビジョニング」、RFC 3990、2005年2月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] "IEEE Std 802.11i: Medium Access Control (MAC) Security Enhancements", April 2004.
[4] 「IEEE STD 802.11i：Medium Access Control（MAC）セキュリティ強化」、2004年4月。
[5] "IEEE Std 802.11h: Spectrum and Transmit Power Management Extensions in the 5 GHz Band in Europe", October 2003.
[5] 「IEEE STD 802.11H：ヨーロッパの5 GHzバンドのスペクトルと送信電力管理拡張機能」、2003年10月。
[6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.
[6] 「IEEE STD 802.1x：ポートベースのネットワークアクセス制御」、2001年6月。
Authors' Addresses
著者のアドレス
L. Lily Yang Intel Corp. MS JF3 206, 2111 NE 25th Avenue Hillsboro, OR 97124
L. Lily Yang Intel Corp. MS JF3 206、2111 NE 25th Avenue Hillsboro、または97124
Phone: +1 503-264-8813
EMail: lily.l.yang@intel.com
Petros Zerfos UCLA - Computer Science Department 4403 Boelter Hall Los Angeles, CA 90095
Petros Zerfos UCLA-コンピューターサイエンス部門4403 Boelter Hall Los Angeles、CA 90095
Phone: +1 310-206-3091
EMail: pzerfos@cs.ucla.edu
Emek Sadot Avaya Atidim Technology Park, Building #3 Tel-Aviv 61131 Israel
Emek Sadot Avaya Atidim Technology Park、ビル＃3 Tel-Aviv 61131イスラエル
Phone: +972-3-645-7591
EMail: esadot@avaya.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。