Network Working Group                                            L. Yang
Request for Comments: 4118                                   Intel Corp.
Category: Informational                                        P. Zerfos
                                                                E. Sadot
                                                               June 2005
                       Architecture Taxonomy for
      Control and Provisioning of Wireless Access Points (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).




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
1. Introduction
1. はじめに

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のセット全体にわたって一貫した構成を配布し、維持することは困難な作業です。無線媒体の共有及び動的な性質は、無線干渉を最小化し、ネットワークのパフォーマンスを最大化するAP間効果的な調整を必要とします。常に存在し、大規模な展開と新しいアーキテクチャでも、多くの課題の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を含む)が関与標準化団体のための市場慣行の凝集理解を提供したいと考えています。この文書では、APの機能アーキテクチャを定義する際に、入力としてIEEE 802.11ワーキンググループによってレビューされ、利用されてもよいです。

1.1. IEEE 802.11 WLAN Functions
1.1. IEEE 802.11 WLAN機能

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によって制御されます。二つ以上の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.

BSSを相互接続するために使用されるアーキテクチャコンポーネントは、配信システム(DS)です。 APは、DSサービスを提供するだけでなく、STAとして作用することにより、DSへのアクセスを提供するSTAです。別の論理アーキテクチャコンポーネント、ポータルは、従来の有線LANとIEEE 802.11アーキテクチャを統合するために導入されます。 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サブレイヤによって使用されています。ステーションサービスは、次の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 De-authentication: Voids an existing authentication relationship.


o Confidentiality: Prevents the content of messages from being read by others than the intended recipients.


o MSDU Delivery: Delivers the MAC service data unit (MSDU) for the stations.

O MSDU配信は:ステーションのMACサービスデータユニット(MSDU)を提供します。

Distribution system services consist of the following five services:


o Association: Establishes Access Point/Station (AP/STA) mapping and enables STA invocation of the distribution system services.

協会○:アクセスポイント/ステーション(AP / STA)のマッピングを確立し、物流システムサービスのSTA呼び出しを可能にします。

o Disassociation: Removes an existing association.


o Reassociation: Enables an established association (between AP and STA) to be transferred from one AP to another or the same AP.

O再会合は、別の又は同じAP 1つのAPから転送される(APとSTAとの間)確立されたアソシエーションを有効にします。

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分散:それらに関連するSTAのためのAPによってMSDUの転送を提供します。 MSDUは、いずれかの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'.

統合○:MSDUは、非802.11フォーマット及びその逆への配信システムから受信した変換します。 「ディストリビューション」のサービスが起動される前に、DSから受信されているすべてのMSDUは、DSSの「統合」のサービスを起動します。有線LANへのDSの接続点は、「ポータル」と呼ばれています。

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のAPによって実装されなければならない追加のMACサービスを定義します。例えば:

o Beacon Generation


o Probe Response/Transmission


o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK

O制御フレームの処理:RTS / CTS / ACK / PSポール/ CF-エンド/ CF-ACK

o Synchronization


o Retransmissions


o Transmission Rate Adaptation


o Privacy: 802.11 Encryption/Decryption


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規格)、AP間プロトコル(IAPP、または802.11F - お勧め) STA等、別のBSSからローミング、無線リソース測定強化(802.11k)場合APを更新します

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つの物理デバイスに実装されるように指定ありません。それが唯一のAPとDSの残りの部分は一緒にすべてのこれらのサービスを実装する必要があります。典型的には、ベンダーはIEEE 802.11規格で定義されたサービスだけでなく、このような負荷分散サポート、QoSの、ステーションモビリティサポート、および不正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アクセスネットワーク機能と、個々の物理デバイスとの間に明確な区別をしたいです。我々は、RFアンテナ及び802.11 PHYがBSSネットワークにおけるステーショントラフィックを送受信することを可能にする物理デバイスに配信サービスへのアクセスを提供する論理エンティティ、および「WTP」(ワイヤレス終端ポイント)を指すために「AP」を使用します。集中型アーキテクチャ(セクション5を参照)、アクセスコントローラ(AC)とWTPsの組み合わせは、すべての論理機能を実現します。これらの物理デバイス(WTPまたはAC)の各々は、論理機能の一部のみを実装することができます。しかし、全体としてすべての物理デバイスを含むDSは、機能のすべてまたは大部分を実装しています。

1.2. CAPWAP Functions
1.2. CAPWAP機能

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 WTPの構成、例えば、SSIDのために。

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 Mutual authentication between network entities, e.g., for AC and WTP authentication in a Centralized WLAN Architecture.


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').

記載されているサービスは、無線リソースWTPデバイス(「WTPの設定」、「WTPファームウェアのアップグレード」)の(「RF監視」と「RFコンフィギュ」)、管理と構成、および、セキュリティに関するの構成および制御に関するものです交流(「AC / WTP相互認証」)にWTPの登録。また、このようなサブネットと負荷分散を横切って移動管理などの他のサービス、デバイスは、無線ネットワークに関連付けられているSTA(S)に関する状態情報を取得することができ、また、サービス(「STA状態情報データベース」)として報告されます。

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.


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 Transmit Power Control


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:


o RADAR detection


o Transmit Power Control


o Dynamic Channel Selection


1.3. WLAN Architecture Proliferation
1.3. WLANアーキテクチャ増殖

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ワーキンググループは、最初に機能し、現在、既存の無線LANベンダーが提供するネットワークアーキテクチャの両方を文書化されています。最終結果は、この分類の文書です。

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.

ダース以上の異なるベンダーのアーキテクチャを分析した後、我々は既存の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アーキテクチャ:最初の建築家は、それぞれのWTPが分配統合サービス、およびポータル機能の両方を含むすべての802.11サービスを実装し、単一の物理デバイスである、伝統的な自律WLANアーキテクチャです。各WTPはその機能に自律的であり、明示的な802.11サポートがWTP以外のデバイスから必要とされていないため、このようなAPのアーキテクチャは、自律WLANアーキテクチャと呼ばれています。このようなアーキテクチャでは、WTPは、典型的には、構成と個別に制御し、SNMPのような一般的なネットワーク管理プロトコルを介して監視および管理することができるされています。 WTPsは、ほとんどの人が馴染みのある伝統的なAPのです。このようなWTPs時々「脂肪の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アーキテクチャ:二WLANアーキテクチャファミリはWTPの多数のデバイスを管理するための1つのまたは複数の集中コントローラを利用新興階層アーキテクチャです。集中制御装置は、一般に、その主な機能は、管理制御、およびネットワーク内に存在するWTPデバイスを設定するアクセスコントローラ(AC)と呼ばれています。それは通常、無線アクセスネットワーク内の中央の場所に位置しているので、制御および管理プレーンのための集中型のエンティティであることに加えて、それはまた、データプレーンの天然の集約点になることができます。 ACは、多くの場合、L2ブリッジ、スイッチ、またはL3ルータと同じ場所に配置され、それらの特定の場合にアクセスブリッジまたはアクセスルータと呼ぶことができます。そのため、アクセスコントローラは、L3またはL2デバイスのいずれかである、と私たちは、この文書全体で使う一般的な用語である可能性があります。複数のACSが、冗長性、負荷分散などの目的で、ネットワーク内に存在することも可能である。このアーキテクチャファミリ注目に値するいくつかの明確な特徴を持っています。まず、階層化アーキテクチャと集中ACは、大規模ネットワークのためのより良い管理を提供します。第二に、IEEE 802.11機能とCAPWAP制御機能するので、一緒にWTPデバイスおよびACによって規格で定義されるように、それ自体がもはや完全に802.11の機能を実装することができるWTP装置が設けられています。したがって、完全な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アーキテクチャの分散:第新興WLANアーキテクチャ・ファミリは、有線または無線媒体を介して、参加する無線ノードがそれ自体の間で分散型ネットワークを形成することが可能である、分散アーキテクチャです。無線メッシュネットワークは、ノード自体がメッシュネットワークを形成し、802.11無線リンクを介してメッシュノードに隣接して接続する分散アーキテクチャファミリー内の一例です。これらのノードのいくつかは、外部ネットワークへのゲートウェイとして動作する有線のイーサネット接続を持っています。

1.4. Taxonomy Methodology and Document Organization
1.4. 分類方法論とマニュアルの構成

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の、アルバ、アバイア、チャントリーネットワークス、シスコ、Craniteシステムズ、エクストリームネットワークス、Intoto、Janusysネットワークス、ノーテル、パナソニック、ブランコ、Instant802、ストリックスシステムズ、シンボル)と学術研究団体から1からです(UCLA)。 16の拠出金のうち、一つは自律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アーキテクチャセクションで)、このドキュメントで使用されています。 Oアーキテクチャの考慮事項:ACとWTPの間の接続の選択これらのサービスや機能は、3つの主要なカテゴリに分類されています。 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.


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.


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.


2. Conventions

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。

3. Definitions
3.1. IEEE 802.11 Definitions
3.1. IEEE 802.11の定義

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):無線媒体(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.


Basic Service Set (BSS): A set of stations controlled by a single coordination function.


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).


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).


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.


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)からで媒体アクセス制御(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)を有効分配システム(DS)によって提供されるサービスのセットを介して互いに直接通信していない局間のMACサービスデータユニット(のMSDU)を輸送する層無線媒体(WM)の単一のインスタンス。これらのサービスは、同じで局間のMSDUの拡張サービスセット(ESS)、ESS内のポータルとのBSSとの間のMSDUのトランスポート内の基本サービスセット(のBSS)のアクセスポイント(AP)との間のMSDUの輸送、及び輸送を含みますMSDUは、マルチキャストまたはブロードキャスト宛先アドレスを有する、または宛先が個別アドレスであるが、MSDUを送信局はDSSを含むことを選択した場合にはBSS。意思決定支援システムは、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).


3.2. Terminology Used in This Document
3.2. この文書で使用される用語

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:

新しい用語を定義する動機の一つは、いくつかの従来の用語を取り巻く曖昧さや混乱を明らかにすることです。そのような用語は、「アクセスポイント(AP)」です。一般的に、人々は「AP」について話すとき、彼らはアンテナを持っている物理的なエンティティ(ボックス)を参照して、802.11 PHYを実装し、受信/駅(STA)の空気を超えるトラフィックが送信されます。しかし、802.11標準[1]は主にそのステーションのトラフィックを受信して​​無線で有効伝送することができるように論理的なサービスのセットを実装する論理エンティティとしてAPを記載しています。人々は「AP機能」を参照するとき、彼らは通常のSTAが直接通信することを全体のWLANアクセスネットワークがサポートする論理的機能、および物理的なエンティティ(ボックス)がサポートしている機能だけではなくサブセットを意味します。論理機能をネットワーク全体の代わりに、単一の物理エンティティ内に実装される場合、このような混乱は特に深刻であることができます。さらに混乱を避けるために、我々は以下の用語を定義します。

CAPWAP: Control and Provisioning of Wireless Access Points


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機能:すべてのMACサービス、駅サービス、および配信サービスを含むIEEE 802.11ワーキンググループによって定義された論理関数のセット。これらの論理機能は、IEEE 802.11規格によりIEEE 802.11無線LAN(WLAN)アクセスネットワークに実装する必要がある[1]。

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サービスを実装する論理エンティティを参照することができます。私たちは、明示的に自律し、中央集中型WLANアーキテクチャの両方のネットワークエンティティに適用される上記のプロパティを持つ物理的なエンティティ(例えば、RFアンテナと802.11 PHYを搭載)、(下記参照)を意味し、一般的な用語として「WTP」をお勧めします。

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アーキテクチャ:WLANアクセスネットワークアーキテクチャ・ファミリIEEE 802.11およびCAPWAP機能(適用可能であれば)の両方を含むすべての論理機能は、ネットワーク内の各無線ターミネーションポイント(WTP)内に実装されています。これらのデバイスは、ネットワークから、他の支援がなくても動作するようにデバイスを可能にする機能のフルセットを実装しているため、このようなネットワークでWTPsも、スタンドアロンのAP、または脂肪の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アクセスネットワークアーキテクチャファミリー。高いレベルで、制御構成、及び全体WLANアクセスネットワークの管理を担当するアクセスコントローラ(ACS)があるが、より低いレベルで、WTPsあります。

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.


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.


Standalone WTP: Refers to the WTP in Autonomous WLAN Architecture.

スタンドアロンWTP:自律WLAN ArchitectureでWTPを指します。

Controlled WTP: Refers to the WTP in Centralized WLAN Architecture.


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アクセスネットワークにおけるWTPsのみ、IEEE 802.11のために(すべての制御フレームと、いくつかの管理フレームを含む)は、遅延に敏感なMACサービスを実装することにより、中央集中型WLANアーキテクチャの亜群集中処理のためのAC。 IEEE 802.11 MACは、[1]にIEEE 802.11規格によって定義されるように、効果的に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アーキテクチャ:(802.11管理フレーム処理の大部分を含む)802.11 MAC機能の大部分又は全体のセットがWTPに実装されている集中型WLANアーキテクチャのサブグループ。したがって、802.11 MACは、PHYと一緒に、WTPで無傷で、地元のまま。

3.3. Terminology Used Historically but Not Recommended
3.3. 用語は、歴史的に使用されますが、推奨されません

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.


Hierarchical WLAN Architecture: Use Centralized WLAN Architecture.


Standalone Access Point: Use Standalone WTP.


Fat Access Point: Use Standalone WTP.


Thin Access Point: Use Controlled WTP.


Light weight Access Point: Use Controlled WTP.


Split AP Architecture: Use Local MAC Architecture.


Antenna AP Architecture: Use Remote MAC Architecture.


4. Autonomous Architecture
4.1. Overview
4.1. 概要

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.3フレームから/に802.11フレームとの間の変換をWTPです。異なるWTPsのイーサネットインターフェースを相互接続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


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をサポートすることによって、複数の仮想WTPsとしてプロビジョニングすることができます。いくつかの場合において、これは、イーサネットインフラストラクチャに転送される各パケットに対応する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.


Authentication of 802.11 clients may be performed locally by the WTP or by using a centralized authentication server.


4.2. Security
4.2. セキュリティ

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.

このアーキテクチャにおけるセキュリティニーズの一つは、WTPとイーサネットインフラストラクチャ間の相互認証のためです。これは、WTPとそれが接続するイーサネットスイッチとの間の802.1Xのような既存のメカニズムによって確保することができます。別の重要なセキュリティ上の問題はWTPがないロックおよびキーの下に可能性が高いですが、そのようなAAAやSNMPなどのバックエンド・システムと通信するための秘密情報が含まれているという事実です。 IT担当者は、すべてのデバイスに「テンプレート」を押すの共通の管理方法を使用しているため、そのようなデバイスの盗難は、潜在的に有線ネットワークを危険にさらすことになります。

5. Centralized WLAN Architecture

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アーキテクチャは、ネットワーク全体を有効にするには、アクセスコントローラ(S)と呼ばれる、一つ以上の集中型のコントローラを採用します監視、管理のスケーラビリティを改善し、動的構成可能性を容易にします。

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.

次の図は概略的アクセスコントローラ(AC)は、相互接続媒体を介して複数の無線ターミネーションポイント(WTPs)に接続集中WLANアーキテクチャのネットワーク図を示します。セクション5.1で説明したように、これは直接接続することができ、L2-を切り替え、またはL3ルーティングネットワーク。 AC交換構成と集中点から、ネットワークの管理を可能にする、WTPデバイスと情報を制御します。 (図が示唆するように)中央集中型WLANアーキテクチャファミリーのデザインは、ACは必ずしもWTP(S)への/からのデータプレーンにとりなしていることを前提としません。詳細は、このセクションの後半で提供されています。

    +---------------+     +---------------+     +---------------+
    |  802.11 BSS 1 |     |  802.11 BSS 2 |     |  802.11 BSS 3 |
    |  ...          |     |  ...          |     |  ...          |
    |    +-------+  |     |    +-------+  |     |    +-------+  |
    +----|  WTP  |--+     +----|  WTP  |--+     +----|  WTP  |--+
         +---+---+             +---+---+             +---+---+
             |                     |                     |
             +------------------+  |   +-----------------+
                                |  |...|
                           |  Interconnection   |
                             |    AC    |

Figure 2: Centralized WLAN Architecture Diagram


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バックエンドサーバ(例えば、RADIUS認証などの別のボックス、上に実装されてもよいですサーバ)。

5.1. Interconnection between WTPs and ACs
5.1. WTPsとACSとの間の相互接続

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.


                             -------+------ LAN
                            |      AC       |
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | WTP |       | WTP |
                          +--+--+       +--+--+

Figure 3: Directly Connected


                             -------+------ LAN
                            |      AC       |
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+    +-----+-----+
                          | WTP |    |   Switch  |
                          +--+--+    +---+-----+-+
                                         |     |
                                      +-----+  +-----+
                                      | WTP |  | WTP |
                                      +-----+  +-----+

Figure 4: Switched Connections


                            |      AC       |
                            --------+------ LAN
                            |     Router    |
                            -----+--+--+--- LAN
                                 |     |
                             +---+     +---+
                             |             |
                          +--+--+       +--+--+
                          | WTP |       |  WTP|
                          +--+--+       +--+--+

Figure 5: Routed Connections


5.2. Overview of Three Centralized WLAN Architecture Variants
5.2. 三つの中央集中型WLANアーキテクチャのバリアントの概要

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.


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のアプローチについて説明します。各アプローチのために、我々は、各ベンダーからネットワークエンティティに様々な機能のマッピング特性を提供します。ローカルMAC、スプリットMAC、およびリモートMACの命名は、機能、および特に802.11 MAC機能は、ネットワークエンティティにマッピングする方法を反映しています。リモートMACはMACは、ネットワーク内のリモートACに離れWTPから移動したことを示しながら、ローカルMACは、MAC機能はそのままとWTPsに現地に滞在することを示しています。スプリットMACは、MACが大きくリアルタイム感度の線に沿って、WTPsとACSの間で分割されて示されています。一般的に、スプリット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:


      +--------------+---    +---------------+---    +--------------+---
      |  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)は、 "ローカルMAC"(B) "スプリットMAC"(C) "遠隔MAC"

Figure 6: Three Architectural Variants within the Centralized WLAN Architecture Family


5.3. Local MAC
5.3. ローカルMAC

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.

ローカルMACアーキテクチャモデルの主な動機は、図6(a)に示すように、WTPsとACとの間の802.11 MAC機能を分割することなく、ACへのネットワーク・アクセス・ポリシーおよび管理機能(セクション1.2に記載CAPWAP機能)をオフロードすることです。全体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間のタイプの接続を示しています。明らかに、すべてのベンダーは、L3は、直接接続、L2はネットワークは、すべてのベンダーによってサポートされて切り替えることを意味する、WTPsとACとの間のネットワーク接続をルーティングサポートすることができます。 「802.11 MGMT終了」、および「802.11制御終了」によって、我々は、802.11管理および制御フレームの処理がそれぞれ行われている物理ネットワークデバイスを示します。ここですべてのベンダーがWTPsで802.11管理および制御フレームを終了することを選択しました。表の最後の行は、「802.11データ集約」は、凝集および(おそらくはDSを介して)別のSTAから802.11データフレームの配信が行われたデバイスを指します。表に示すように、ベンダーは、すべての802.11データトラフィックが集約され、ACを介してルーティングされているか否かの異なる選択を行います。調査データは、いくつかのベンダーがトンネルに選択するか、ACも、このWLANアクセスネットワークのアクセスルータとして動作することを意味している、またはACSからすべての駅のトラフィックをカプセル化することを示しています。他のベンダーは、ACでの集中制御を維持しながら駅のトラフィックが、ローカルにブリッジまたはルーティングさせることによって制御およびデータプレーンを分離することを選択しました。

                        Arch7   Arch8   Arch9   Arch10   Arch11
                        -----   -----   -----   ------   ------
      connectivity       L3      L3       L3      L3      L3

802.11 mgmt termination WTP WTP WTP WTP WTP


802.11 control termination 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


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.


                    Arch7   Arch8   Arch9   Arch10   Arch11
                    -----   -----   -----   ------   ------
       Monitoring    WTP     WTP    AC/WTP    WTP     WTP



WTP config. AC AC AC AC AC




STA state info database AC AC/WTP AC/WTP AC/WTP AC

私は、1/1 utpa第六状態データベース情報/ utpaのA / utpaが来ました



Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture


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の機能のほとんどは、配信サービス、802.11eのスケジューリング、および802.1X / EAP認証に関するベンダー間のいくつかのマイナーな違いは、ローカルMACアーキテクチャ用WTPsで実装されていることを示しています。配信サービスの差は、図7の「802.11データ集約」に関して先に説明したものと一致しています。

                    Arch7   Arch8   Arch9   Arch10   Arch11
                    -----   -----   -----   ------   ------
       Service       AC      AC      WTP     AC       WTP

Integration Service WTP WTP WTP WTP WTP


Beacon Generation WTP WTP WTP WTP WTP


Probe Response WTP WTP WTP WTP WTP


Power mgmt Packet Buffering 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

協会Disassoc。再会合AC WTP WTP WTP WTP

       classifying   AC                               WTP





       and Privacy
       802.1X/EAP    AC      AC     AC/WTP    AC     AC/WTP

Keys Management 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


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.


5.4. Split MAC
5.4. スプリット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)に示すように、スプリット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は、ローカルMACアーキテクチャにおいて、WTPは802.11非リアルタイム機能を終了し、結果的に適切なメッセージを送信するのに対し、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.

WTP。そのため、リアルタイムの基準は通常、デバイス間のMACサービスを分離するために採用されています。もう1つの考慮事項は、それをできるだけ安価かつ簡単にするためにWTPのコスト削減です。ユーザーの暗号化キーは、もはやWTPに常駐していないので、最後に、ACの暗号化と復号化のような機能を移動させることは、妥協WTPからの脆弱性を低減します。その結果、セキュリティプロトコルとアルゴリズムの設計における任意の進歩は必ずしもないWTPs時代遅れありません。 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仕様には明確な定義がないのでこれに802.11 MAC機能を「リアルタイム」とみなされるように、各ベンダーが独自の方法でこれを解釈します。ほとんどのベンダーは、802.11 MACの以下のサービスがリアルタイムサービスの一例であり、WTPs上に実装するように選択されることに同意します。

o Beacon Generation


o Probe Response/Transmission


o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK

O制御フレームの処理:RTS / CTS / ACK / PSポール/ CF-エンド/ CF-ACK

o Synchronization


o Retransmissions


o Transmission Rate Adaptation


The following list includes examples of non-realtime MAC functions as interpreted by most vendors:


o Authentication/De-authentication


o Association/Disassociation/Reassociation/Distribution

お あっそしあちおん/ぢさっそしあちおん/れあっそしあちおん/ぢstりぶちおん

o Integration Services: Bridging between 802.11 and 802.3


o Privacy: 802.11 Encryption/Decryption


o Fragmentation/Defragmentation


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.


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の非リアルタイムの態様は、生の802.11管理フレーム(スプリットMAC)の処理を経てACによって処理されます。図10の次の行列は、アーキテクチャ上の考慮事項についてのスプリットMACの設計に従っ6つのベンダーによって行われた設計上の選択の表形式の表現を提供しています。ほとんどのベンダーがWTPsとACSの間のL3接続をサポートしながら、いくつかは、L2は、ネットワークを介して2つの物理エンティティ間MACを分割することから生じるより厳しい遅延制約のために接続を切り替えサポートすることができます。図7には、WTPがスプリットMACとローカルMACの両方における802.11管理フレームを処理することは明らかです。 802.11管理フレームの終了時点で2つの嘘の違い。 802.11管理フレームの少なくとも一部は、スプリットMACアーキテクチャ用ACで終端されている間、ローカルMACは、WTPの802.11管理フレームを終了します。ほとんどの場合、WTPデバイスがIPアドレス指定可能であるので、直接接続のいずれか、L2は、スイッチ、またはセクション1.2のL3ルーティング接続を使用することができます。唯一のイーサネットカプセル化(例えば、建築4のように)実行された場合、直接接続およびL2交換接続のみがサポートされています。

                   Arch1   Arch2   Arch3   Arch4   Arch5   Arch6
                   -----   -----   -----   -----   -----   -----
      connectivity   L3     L3      L3      L2      L3      L3

802.11 mgmt termination AC AC AC AC AC/WTP AC


802.11 control termination WTP WTP WTP WTP WTP WTP


802.11 data aggregation AC AC AC AC AC AC

AC AC ACデータ集約802.11 AC AC AC

Figure 10: Architecture Considerations for Split MAC Architecture


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.


                    Arch1   Arch2   Arch3   Arch4   Arch5   Arch6
                    -----   -----   -----   -----   -----   -----
      Monitoring    WTP     WTP      WTP    WTP     WTP     WTP



WTP config. AC AC AC AC AC




STA state info database AC AC AC AC AC


AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP


Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture


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.ベンダーは一定の規則でWTPsとAC上の機能をマッピングして以下に示すように、スプリットMACアーキテクチャの最も興味深いマトリックスは、802.11の機能のための機能分散行列です。たとえば、すべてのベンダーは、802.1X / EAP認証およびキー管理とともに、流通、ACでの統合サービスを実装することを選択しました。すべてのベンダーもWTPsでビーコン生成を実装することを選択します。一方、ベンダーは時々異なった他の機能の多くをマッピングすることを選択しました。したがって、スプリットMACアーキテクチャは、MACが分割された正確な方法については一貫していません。

                    Arch1   Arch2   Arch3   Arch4    Arch5   Arch6
                    -----   -----   -----   ------   -----   -----
      Service       AC      AC      AC      AC       AC      AC

Integration Service AC AC AC AC AC AC


Beacon Generation WTP WTP WTP WTP WTP WTP




Power mgmt Packet Buffering 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

協会Disassoc。再会合AC AC AC AC AC WTP

      classifying                   AC      AC       AC      AC


スケジューリングWTP / AC AC WTP AC AC WTP / AC



      and Privacy



Keys Management AC AC AC AC AC AC


802.11 Encryption/ Decryption WTP AC WTP AC AC AC

802.11暗号化/復号化WTP AC WTP AC AC AC

Figure 12: Mapping of 802.11 Functions for Split MAC Architecture


5.5. Remote MAC
5.5. リモートMAC

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アーキテクチャのための主要な動機の一つは、アクセスコントローラに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.

それらは1つのフォーマット(802.11)からフレームを変換するための追加的な特徴を有していてもよいけれどもWTPは、唯一の無線LANクライアント(STA)とACとの間のパススルーとして作用する他の(すなわち、イーサネット(登録商標)、TR、ファイバ) 。集中制御装置は、ネットワーク監視、管理および制御、802.11 APサービスのセット全体、セキュリティ機能、リソース管理、チャンネル選択機能を提供し、ユーザへのサービスの品質を保証します。 MACは、PHYから分離されているので、私たちはこの「リモートMACアーキテクチャ」を呼び出します。典型的には、このようなアーキテクチャは、遅延が最小になるようWTPsとACとの間の接続に特別な注意を払って配備されます。アーキテクチャ5からファイバ上ラジオ(のRoF)は、リモートMACアーキテクチャの一例です。

5.6. Comparisons of Local MAC, Split MAC, and Remote MAC
5.6. ローカルMAC、スプリットMAC、およびリモートMACの比較

Two commonalities across all three Centralized Architectures (Local MAC, Split MAC, and Remote MAC) are:


o Most of the CAPWAP functions related to network control and configuration reside on the 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から分離されるように他の2つは一緒にMAC機能の一部を維持しながら、リモートMACと他の二つの集中型アーキテクチャ(すなわち、ローカルMAC及びスプリットMAC)との間の明確な差は、ありますWTPsでPHYと。 PHYとMAC分離の含意は802.11タイミング制約が満たされるように、それは厳しく、WTPsとACSとの間の相互接続の種類を制限することです。先に指摘したように、これは通常、リモートMACアーキテクチャのためのWTPとACとの間の相互接続を介してより厳しい制約になります。リモートMACアーキテクチャの利点は、特定の展開シナリオのための最軽量の可能なWTPsを提供することです。

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の間の共通点と相違点を最も明確図10に共通性を図7を比較することによって理解されている802.11制御フレームは両方のケースでWTPsで終端されていることです。ローカルMACとスプリットMACとの間の主な違いは、WTPローカルMACのすべての802.11フレームを終了することができながら、WTPは、スプリットMACのみ802.11制御フレームを終了することです。この差の興味深い結果は、図9及び図12に示すように、本質的に802.11および802.3フレーム間のブリッジを意味統合サービスは、それぞれ、スプリットMACおよびローカルMAC WTPでによってACによって実現されることです。

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.


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).


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.


5.7. Communication Interface between WTPs and ACs
5.7. WTPsとACSの間の通信インタフェース

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:


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).


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.


3. WTP Association: After successful authentication, a WTP registers with the AC in order to start receiving management and configuration messages.

3. WTP協会:認証が成功した後、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.


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.


6. Configuration Download: Following the control channel establishment process, the AC may push configuration parameters to the WTPs.


5.8. Security
5.8. セキュリティ

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.


5.8.1. Client Data Security
5.8.1. クライアントのデータセキュリティ

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.

調査では、「空中」802.11暗号化の終了点[4] WTPまたはACのいずれかで実施することができることを明確に示しています。また、802.1X / EAP [6]機能はWTPとACとの間に分配され、ほとんどの場合、ACは、802.1X交換にオーセンティケータとして必要な機能を実行します。

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.


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.

集中型モデルは、多くの異なるWTPsのための1つのPMKを使用するAC実装を奨励しています。この方法は、別個のPMKを確立することなく、同じACに接続されている別のWTPからSTAによって迅速な移行を促進します。 STAが損なわPMKと意図的に共有されているものとを区別することができないようにしかし、これは、困難な位置にSTAを残します。この問題は解決されなければならないが、解像度はCAPWAPワーキンググループの範囲を超えています。この解像度の会場は、IEEE 802とIETFリエゾンによって決定されるべきです。

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.


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.


5.8.2. Security of Control Channel between the WTP and AC
5.8.2. WTPとAC間の制御チャネルのセキュリティ

In order for the CAPWAP functions to be implemented in the Centralized WLAN Architecture, a control channel is necessary between the WTP and AC.


To address potential security threats against the control channel, existing implementations feature one or more of the following security mechanisms:


1. Secure discovery of WTP and AC.


2. Authentication of the WTPs to the ACs (and possibly mutual authentication).

2. ACSにWTPsの認証(及びおそらく相互認証)。

3. Confidentiality, integrity, and replay protection of control channel frames.


4. Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets and state.


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.


5.8.3. Physical Security of WTPs and ACs
5.8.3. WTPsとACSの物理的なセキュリティ

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.


6. Distributed Mesh Architecture

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.


       +-----------------+         +-----------------+
       |  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


6.1. Common Characteristics
6.1. 共通の特徴

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.


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.

メッシュネットワークは、必ずしも集中制御の使用を排除していないことを指摘する価値があります。集中型および分散型制御の組み合わせは、メッシュネットワークに共存することが可能です。 (中央集中型WLANアーキテクチャで定義されているように、たとえないACの本格的なバージョン)アクセスコントローラ(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)を開始しました。

6.2. Security
6.2. セキュリティ

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.


7. Summary and Conclusions

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アクセスネットワークアーキテクチャの簡単な説明を提出する既存の無線LANベンダーやその他の利害関係者を要求しました。 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 IEEE 802.11規格によって必要とされるものを含む関数、、およびCAPWAP機能、たとえば、アクセスポイント機能の広範なセットは、2つのカテゴリに分けられています制御、構成、および802.11 WLANアクセスネットワークの管理のために不可欠とみなされます。かなりの曖昧さの原因となっている他の用語は、通常のアンテナを持っている物理的なボックスを反映しますが、応募作品全体で外部に一貫性のある動作の均一なセットを持っていなかった「アクセスポイント」、です。 802.11 PHYを終了物理ボックスがワイヤレスターミネーションポイントと呼ばれながら、この曖昧さを取り除くために、我々は、802.11およびCAPWAP機能のセットとしてAPを再定義しています。

Based on the submissions during the architecture survey phase, we have classified the existing WLAN architectures into three broad classes:


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.


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.


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.


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:


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.


The WLAN access network architectures in the submissions indicated that the connectivity assumptions were:


o Direct connection between the WTP and the 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.


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市場における基本的な問題今日の一つです。オープンな標準的な開発を介した相互運用性を実現するには、次の手順では、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アクセスポイントの機能要素を定義で構成されます。そのような機能モデルは、IEEE 802.11グループ内又は外この分類に概説されるように、既存のWLANのアーキテクチャをサポートするための共通基盤、及び任意の更なるアーキテクチャの発展として役立つべきです。ことが可能であり、さらに推奨される、機能モデルの定義上の作業も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.


8. Security Considerations

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間の結合の新しいネットワークのためにいくつかの新しいセキュリティ上の問題があります。次のセキュリティ上の懸念は、このアーキテクチャの家族のために提起されている:モバイルクライアントのトラフィックのための鍵材料は、しっかりとWTPにACから輸送する必要があるかもしれません。 AC WTPの、安全な発見はWTPsとACとの間の相互認証と同様に、必要とされます。 WTPと制御チャネルフレームのAC、機密性、完全性および再生保護、および内に埋め込まれた秘密の抽出のためのWTPsの盗難間の制御チャネルへのman-in-the-middle攻撃。この広範なアーキテクチャカテゴリの調査結果のそれぞれは、これらのセキュリティ問題に対処するためのメカニズムを提示しました。

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.


9. Acknowledgements

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:


o Peyush Agarwal STMicroelectronics Plot# 18, Sector 16A Noida, U.P 201301 India Phone: +91-120-2512021 EMail:

O Peyush AgarwalさんSTマイクロエレクトロニクスのプロット#18、セクター16Aノイダ、U.P 201301インド電話:+ 91-120-2512021 Eメール

o Dave Hetherington Roving Planet 4750 Walnut St., Suite 106 Boulder, CO 80027 United States Phone: +1-303-996-7560 EMail:

Oデイブ・ヘザーリントンロービングプラネット4750ウォルナット聖、スイート106ボルダー、CO 80027米国電話:+ 1-303-996-7560 Eメール

o Matt Holdrege Strix Systems 26610 Agoura Road Calabasas, CA 91302 Phone: +1 818-251-1058 EMail:

Oマット・ホールドレッジストリックスシステムズ26610アゴーラ道路カラバサス、CA 91302電話:+1 818-251-1058電子メール

o Victor Lin Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 Phone: +1 408-579-3383 EMail:

Oビクター林エクストリームネットワークス3585モンローストリートサンタクララ、CA 95051電話:+1 408-579-3383電子メール

o James M. Murphy Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588 Phone: +1 925-474-2233 EMail:

Oジェームス・M.マーフィーブランコNetworksの5753 W.ラスポシタスブルバードプレザントン、CA 94588電話:+1 925-474-2233電子メール

o Partha Narasimhan Aruba Wireless Networks 180 Great Oaks Blvd San Jose, CA 95119 Phone: +1 408-754-3018 EMail:

O Partha Narasimhanアルバワイヤレスネットワークス180グレートオークスブールバードサンノゼ、CA 95119電話:+1 408-754-3018電子メール

o Bob O'Hara Airespace 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2025 EMail:

Oボブ・オハラのAirespace 110 Nortechパークウェイサンノゼ、CA 95134電話:+1 408-635-2025電子メール

o Emek Sadot (see Authors' Addresses)


o Ajit Sanzgiri Cisco Systems 170 W Tasman Drive San Jose, CA 95134 Phone: +1 408-527-4252 EMail:

アジットSanzgiriシスコシステムズO 170 Wタスマン・ドライブサンノゼ、CA 95134電話:+1 408-527-4252電子メール

o Singh Chantry Networks 1900 Minnesota Court Mississauga, Ontario L5N 3C9 Canada Phone: +1 905-567-6900 EMail:

O・シンチャントリーネットワークス1900年ミネソタ州裁判所ミシソーガ、オンタリオL5N 3C9カナダ電話:+1 905-567-6900電子メール

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.

また、我々はまた、アーキテクチャの調査に参加し、分類の製造における詳細な入力データを提供する以下の個人からの寄付を認めることを希望:Parviz Yegani、チェン香港、Saravananゴヴィンダン、ボブ・ビーチ、デニスVolpano、シャンカールNarayanaswamy、サイモン理容室、スリニヴァサラオAddepalli、サブハッシーニA. Venkataramanan、KUEウォン、ケビン・ディック、テッド・クオ、およびタイアン-集嬢。彼らが私たちに提供されている代表的なデータポイントの大規模なセットせずに、この分類を書くことだけでは不可能です。また、当社のCAPWAP WGの共同議長、Mahalingamマニとドロシーゲッレールトと、その尽きることのない支援のための私たちの地域のディレクター、バートWijnenを、感謝したいと思います。

10. Normative References

[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]オハラ、B.、カルフーン、P.、およびJ.ケンフ、 "ワイヤレスアクセスポイント(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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[4] "IEEE Std 802.11i: Medium Access Control (MAC) Security Enhancements", April 2004.

[4] "IEEE標準の802.11i規格:媒体アクセス制御(MAC)セキュリティ強化"、2004年4月。

[5] "IEEE Std 802.11h: Spectrum and Transmit Power Management Extensions in the 5 GHz Band in Europe", October 2003.


[6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.

[6] "IEEE 802.1X STD:ポートベースのネットワークアクセスコントロール"、2001年6月を。

Authors' Addresses


L. Lily Yang Intel Corp. MS JF3 206, 2111 NE 25th Avenue Hillsboro, OR 97124

L.リリーヤンインテル社MS JF3 206、2111 NE 25日アベニューヒルズボロ、OR 97124

Phone: +1 503-264-8813 EMail:

電話:+1 503-264-8813電子メール

Petros Zerfos UCLA - Computer Science Department 4403 Boelter Hall Los Angeles, CA 90095

ペトロスZerfos UCLA - コンピュータサイエンス学部4403 Boelterホールロサンゼルス、CA 90095

Phone: +1 310-206-3091 EMail:

電話:+1 310-206-3091電子メール

Emek Sadot Avaya Atidim Technology Park, Building #3 Tel-Aviv 61131 Israel

Emaeka sadotaアバイアatidima tecanoloji公園、ビル#3、テルアビブ61131イスラエル

Phone: +972-3-645-7591 EMail:

電話:+ 972-3-645-7591 Eメール

Full Copyright Statement


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。