RFC4118 日本語訳
4118 Architecture Taxonomy for Control and Provisioning of WirelessAccess Points (CAPWAP). L. Yang, P. Zerfos, E. Sadot. June 2005. (Format: TXT=93695 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Yang
Request for Comments: 4118 Intel Corp.
Category: Informational P. Zerfos
UCLA
E. Sadot
Avaya
June 2005
コメントを求めるワーキンググループL.陽の要求をネットワークでつないでください: 4118年のインテル社カテゴリ: 情報のP.Zerfos UCLA E.Sadot Avaya2005年6月
Architecture Taxonomy for
Control and Provisioning of Wireless Access Points (CAPWAP)
ワイヤレス・アクセスポイントのコントロールと食糧を供給するアーキテクチャ分類学(CAPWAP)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.
このドキュメントは、これらの機能とサービスを建築実体に広げる際にWireless LAN(WLAN)機能とサービスを分析するのによる市場の802.11個の製品を既存のIEEEで採用しているアーキテクチャの分類学に提供して、異なった異形を説明に提供します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 IEEE802.11WLANは.31.2に機能します。 CAPWAP機能. . . . . . . . . . . . . . . . . . . 5 1.3。 WLANアーキテクチャ増殖. . . . . . . . . . . 6 1.4。 分類学方法論とドキュメント組織. . . . 8 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . 9 3。 定義. . . . . . . . . . . . . . . . . . . . . . . . 9 3.1。 IEEE802.11定義.93.2 用語は本書では.113.3を使用しました。 用語は、.134を歴史的に使用されましたが、推薦しませんでした。 自治のアーキテクチャ. . . . . . . . . . . . . . . . . . 13 4.1。 概要. . . . . . . . . . . . . . . . . . . . . . 13 4.2。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . 14 5。 WLANアーキテクチャ. . . . . . . . . . . . . . . 15 5.1を集結しました。 WTPsとACs. . . . . . . . . 16の間のインタコネクト
Yang, et al. Informational [Page 1] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [1ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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
5.2. 3の概要はWLANアーキテクチャ異形. . . . . . . . . . . . . . . . . . . . . . . 17 5.3を集結しました。 地方のMAC. . . . . . . . . . . . . . . . . . . . . . 19 5.4。 MAC. . . . . . . . . . . . . . . . . . . . . . 22 5.5を分割してください。 リモートMAC. . . . . . . . . . . . . . . . . . . . . . 27 5.6。 地方のMAC、分裂MAC、およびリモートMACの比較。 . 27 5.7. WTPsとACs. . . . . 29 5.8の間の通信インターフェース。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . 29 5.8.1。 クライアントデータセキュリティ. . . . . . . . . . . . . 30 5.8.2。 WTPと交流. . . . . . . . . . . . . . . . 30 5.8.3の間の制御チャンネルのセキュリティ。 WTPsとACs. . . . . . 31 6の物理的なセキュリティ。 分配されたメッシュアーキテクチャ. . . . . . . . . . . . . . . 32 6.1。 共通する特徴. . . . . . . . . . . . . . . . 32 6.2。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . 33 7。 概要と結論. . . . . . . . . . . . . . . . . . 33 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . 36 9。 承認. . . . . . . . . . . . . . . . . . . . . . 37 10。 引用規格. . . . . . . . . . . . . . . . . . . . 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.
IEEE802.11Wireless LAN(WLAN)技術が熟すとき、WLANネットワークの大規模展開はある技術的難関を強調しています。 [2]に概説されているように、ネットワークにおける多くのAccess Points(APs)の管理、モニター、およびコントロールはネットワーク管理に、重要な負担であると判明するかもしれません。 APsの全体のセットの間中WLANで一貫した構成を分配して、維持するのは、厄介な問題です。 また、ワイヤレスの媒体の共有されてダイナミックな本質は、無線妨害を最小にして、ネットワーク性能を最大にするためにAPsの中で有効なコーディネートを要求します。 ネットワーク安全保障問題(いつもWLANsの関心である)は大きい展開と新しいアーキテクチャにおけるさらに多くの挑戦を提示します。
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とIEEE802.11を含んでいて)。 このドキュメントは、APの機能的な建築を定義する際に入力されるようにIEEE802.11作業部会によって見直されて、利用されるかもしれません。
Yang, et al. Informational [Page 2] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [2ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
1.1. IEEE 802.11 WLAN Functions
1.1. IEEE802.11WLANは機能します。
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)とAccess Point(AP)の間と、そして、ワイヤレスのクライアントの中でも連結してください。 802.11また、基本サービスセット(BSS)にモバイル機器がどう交際できるかを説明します。 BSSは基本サービスセット識別子(BSSID)か名前によって特定されます。 一種の'セル'アーキテクチャであるとWLANアーキテクチャをみなすことができます、そして、各BSSはAPによって制御されます。(そこでは、各セルがBasic Service Set(BSS)です)。 2APsが放送層2のネットワークを通して接続されて、すべてが同じSSIDを使用しているとき、拡張サービスセット(ESS)は創設されます。
The architectural component used to interconnect BSSs is the distribution system (DS). An AP is an STA that provides access to the DS by providing DS services, as well as acting as an STA. Another logical architectural component, portal, is introduced to integrate the IEEE 802.11 architecture with a traditional wired LAN. It is possible for one device to offer both the functions of an AP and a portal.
BSSsとインタコネクトするのに使用される建築コンポーネントは流通制度(DS)です。 APはSTAとして機能することと同様にサービスをDSに供給することによってDSへのアクセスを提供するSTAです。 IEEE802.11アーキテクチャを伝統的なワイヤードなLANと統合するために、別の論理的な建築コンポーネント(入り口)を導入します。 1台のデバイスがAPと入り口の両方の機能を提供するのは、可能です。
IEEE 802.11 does not specify the details of DS implementations explicitly. Instead, the 802.11 standard defines services that provide functions that the LLC layer requires for sending MAC Service Data Units (MSDUs) between two entities on the network. These services can be classified into two categories: the station service (SS) and the distribution system service (DSS). Both categories of service are used by the IEEE 802.11 MAC sublayer. Station services consist of the following four services:
IEEE802.11は明らかにDS実装の詳細を指定しません。 代わりに、802.11規格はLLC層がネットワークでMAC Service Data Units(MSDUs)を2つの実体の間に送るために必要とする機能を提供するサービスを定義します。 これらのサービスを2つのカテゴリに分類できます: ステーションサービス(SS)と流通制度サービス(DSS)。 両方のサービスのカテゴリはIEEE802.11MAC副層によって使用されます。 駅のサービスは以下の四軍から成ります:
o Authentication: Establishes the identity of one station as a
member of the set of stations that are authorized to associate
with one another.
o 認証: お互いと交際するのが認可されるステーションのセットのメンバーと1つのステーションのアイデンティティを書き立てます。
o De-authentication: Voids an existing authentication relationship.
o 反-認証: 既存の認証関係を欠如させます。
o Confidentiality: Prevents the content of messages from being read
by others than the intended recipients.
o 秘密性: 意図している受取人より他のものによって読まれるのからのメッセージの内容を防ぎます。
o MSDU Delivery: Delivers the MAC service data unit (MSDU) for the
stations.
o MSDU配送: デリバーズ、ステーションへのMACサービスデータ単位(MSDU。)
Distribution system services consist of the following five
services:
流通制度サービスは以下の5つのサービスから成ります:
o Association: Establishes Access Point/Station (AP/STA) mapping and
enables STA invocation of the distribution system services.
o 協会: Access Point/駅(AP/STA)のマッピングを確立して、流通制度サービスのSTA実施を可能にします。
Yang, et al. Informational [Page 3] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [3ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
o Disassociation: Removes an existing association.
o Disassociation: 既存の協会を取り除きます。
o Reassociation: Enables an established association (between AP and
STA) to be transferred from one AP to another or the same AP.
o Reassociation: 設立された協会(APとSTAの間の)が別のものか1APから同じAPまで移されるのを可能にします。
o Distribution: Provides MSDU forwarding by APs for the STAs
associated with them. MSDUs can be either forwarded to the
wireless destination or to the wired (Ethernet) destination (or
both) using the "Distribution System" concept of 802.11.
o 分配: 彼らに関連しているSTAsのためにAPsによる推進をMSDUに供給します。 ワイヤレスの目的地に送るか、ワイヤードな(イーサネット)の目的地(ともに)のどちらかにはMSDUsが、802.11の「流通制度」概念を使用することであることができます。
o Integration: Translates the MSDU received from the Distribution
System to a non-802.11 format and vice versa. Any MSDU that is
received from the DS invokes the 'Integration' services of the DSS
before the 'Distribution' services are invoked. The point of
connection of the DS to the wired LAN is termed as 'portal'.
o 統合: Distribution Systemから非802.11形式まで逆もまた同様に受け取られたMSDUを翻訳します。 '分配'サービスが呼び出される前に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:
また、これらのサービスは別として、IEEE802.11はWLANでAPsが実装しなければならない追加MACサービスを定義します。 例えば:
o Beacon Generation
o 標識世代
o Probe Response/Transmission
o 応答/トランスミッションを調べてください。
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o 制御フレームの処理: Cf Cf PS RTS/CTS/ACK/投票/終わり/ACK
o Synchronization
o 同期
o Retransmissions
o Retransmissions
o Transmission Rate Adaptation
o 通信速度適合
o Privacy: 802.11 Encryption/Decryption
o プライバシー: 802.11暗号化/復号化
In addition to the services offered by the 802.11, the IEEE 802.11 WG is also developing technologies to support Quality of Service (802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or 802.11F -- recommended practice) to update APs when a STA roams from one BSS to another, Radio Resource Measurement Enhancements (802.11k), etc.
また、802.11で提供されたサービスに加えて、IEEE802.11WGは、STAが1BSSから別のもの、Radio Resource Measurement Enhancements(802.11k)などまで移動するとき、APsをアップデートするためにService(802.11e)、Security Algorithms(802.11i)、Inter-APプロトコル(IAPP、または802.11F--習慣を推薦する)のQualityをサポートする技術を開発しています。
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
IEEE802.11はこれらの機能がちょうどどう実装されるかを指定しません、そして、それはそれらが1個のフィジカル・デバイスで実装されると指定しません。 それは、APsと一緒にDSの残りがこれらのすべてのサービスを実装するのを必要とするだけです。 通常、ベンダーはIEEE802.11規格で定義されたサービスだけではなく、さまざまな付加価値が付いたサービスか機能も実装します、ロードバランシングサポートや、QoSや、ステーション移動性サポートや、凶暴なAPなどのように
Yang, et al. Informational [Page 4] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [4ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
検出。 このドキュメントから明確になることはベンダーが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.11PHYがBSSネットワークでステーショントラフィックを送受信できるフィジカル・デバイスと"WTP"(ワイヤレスの終了ポイント)を呼ぶのに"AP"を使用します。 Centralized Architecture(セクション5を見る)では、Access Controller(西暦)へのWTPsの組み合わせはすべての論理関数を実装します。 それぞれのこれらのフィジカル・デバイス(WTPか西暦)は論理関数の一部だけを実装するかもしれません。 しかし、全体ですべてのフィジカル・デバイスを含む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ネットワークの向こう側により良いコーディネートとコントロールを助けるためにベンダーによって通常提供されています。 WLAN機能が大規模ネットワークにおける複数の実体の上でIEEE802.11に実装されるとき、そのような機能は特に重要です、単一体の代わりに。 そのような機能は:
o RF monitoring, such as Radar detection, noise and interference
detection, and measurement.
o Radar検出などのように雑音をモニターするRF、干渉検出、および測定。
o RF configuration, e.g., for retransmission, channel selection,
transmission power adjustment.
o 例えば、「再-トランスミッション」、経路選択、トランスミッションパワー調整のためのRF構成。
o WTP configuration, e.g., for SSID.
o 例えば、SSIDのためのWTP構成。
o WTP firmware loading, e.g., automatic loading and upgrading of WTP
firmware for network wide consistency.
o ネットワークの広い一貫性のためのWTPファームウェアのWTPのファームウェアのロードしていて、例えば、自動である荷重とアップグレード。
o Network-wide STA state information database, including the
information needed to support value-added services, such as
mobility and load balancing.
o ネットワーク全体のSTAは移動性やロードバランシングなどの付加価値が付いたサービスをサポートするのに必要である情報を含む情報データベースを述べます。
o Mutual authentication between network entities, e.g., for AC and
WTP authentication in a Centralized WLAN Architecture.
o ネットワーク実体、例えば、西暦の互いの認証とCentralized WLAN ArchitectureでのWTP認証。
Yang, et al. Informational [Page 5] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [5ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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 Configuration'、'WTP Firmwareアップグレード')はWTPデバイスのラジオリソース('RF Monitoring'と'RF Configuration')、管理、および構成の構成とコントロールに関係があって、また、セキュリティが関係があります。 そのうえ、サブネットとロードバランシングの向こう側の移動性管理などの他のサービスが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.
CAPWAP機能の上記のリストはベンダーによって提供されたすべての追加サービスの網羅的列挙ではありません。 私たちは調査データに一般的に表された、相互運用性の主要な問題を理解しているのに適切なそれらの機能だけを入れました。
Most of these functions are not explicitly specified by IEEE 802.11, but some of the functions are. For example, the control and management of the radio-related functions of an AP are described implicitly in the MIB, such as:
これらの機能の大部分はIEEE802.11によって明らかに指定されませんが、機能のいくつかはそのように指定されます。 例えば、APのラジオ関連の機能のコントロールと管理は以下などのMIBでそれとなく説明されます。
o Channel Assignment
o チャネル割当
o Transmit Power Control
o 電源制御装置を送ってください。
o Radio Resource Measurement (work is currently under way in IEEE
802.11k)
o ラジオリソース測定(仕事は現在、IEEE 802.11kで進行中です)
The 802.11h [5] amendment to the base 802.11 standard specifies the operation of a MAC management protocol to accomplish the requirements of some regulatory bodies (principally in Europe, but expanding to others) in the following areas:
802.11規格がMAC管理プロトコルの操作を指定するベースの802.11h[5]修正は以下の領域でいくつかの取締機関の要件(しかし、他のものへの主にヨーロッパの広げる)を達成します:
o RADAR detection
o RADAR検出
o Transmit Power Control
o 電源制御装置を送ってください。
o Dynamic Channel Selection
o ダイナミックな経路選択
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ネットワークアーキテクチャの分類学を提供します。 IEEE802.11規格が、DS実装の詳細を指定するのをわざわざ避けるとき、異なったアーキテクチャは市場で増殖しました。 これらのすべての異なったアーキテクチャが全体でIEEE802.11規格に従っている間、それらの個々の機能部品は標準化されません。
Yang, et al. Informational [Page 6] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [6ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Interfaces between the network architecture components are mostly proprietary, and there is no guarantee of cross-vendor interoperability of products, even within the same family of architectures.
ネットワークアーキテクチャコンポーネントの間のインタフェースはほとんど独占です、そして、製品の交差しているベンダー相互運用性の保証が全くありません、アーキテクチャの同じファミリーの中でさえ。
To achieve interoperability in the market place, the IETF CAPWAP working group is first documenting both the functions and the network architectures currently offered by the existing WLAN vendors. The end result is this taxonomy document.
相互運用性を達成するために、市場、IETF CAPWAPワーキンググループには、機能とネットワークアーキテクチャの両方が現在既存のWLANベンダーで提供した最初のドキュメントがあります。 結末はこの分類学ドキュメントです。
After analyzing more than a dozen different vendors' architectures, we believe that the existing 802.11 WLAN access network architectures can be broadly categorized into three distinct families, based on the characteristics of the Distribution Systems that are employed to provide the 802.11 functions.
1ダースの異なったベンダーのアーキテクチャ以上を分析した後に、私たちは、802.11の既存のWLANアクセスネットワークアーキテクチャを3つの異なったファミリーに露骨に分類できると信じています、802.11の機能を提供するのに使われるDistribution Systemsの特性に基づいて。
o Autonomous WLAN Architecture: The first architecture family is the
traditional autonomous WLAN architecture, in which each WTP is a
single physical device that implements all the 802.11 services,
including both the distribution and integration services, and the
portal function. Such an AP architecture is called Autonomous
WLAN Architecture because each WTP is autonomous in its
functionality, and no explicit 802.11 support is needed from
devices other than the WTP. In such architecture, the WTP is
typically configured and controlled individually, and can be
monitored and managed via typical network management protocols
like SNMP. The WTPs are the traditional APs with which most
people are familiar. Such WTPs are sometimes referred to as "Fat
APs" or "Standalone APs".
o 自治のWLANアーキテクチャ: 最初のアーキテクチャファミリーは伝統的な自治のWLANアーキテクチャです、分配と統合サービスと入り口の機能の両方を含んでいて。(各WTPはそれですべての802.11のサービスを実装する単一のフィジカル・デバイスです)。 それぞれのWTPが機能性で自治であるので、そのようなAPアーキテクチャはAutonomous WLAN Architectureと呼ばれます、そして、どんな明白な802.11サポートもWTP以外のデバイスから必要ではありません。 そのようなアーキテクチャでは、SNMPのような典型的なネットワーク管理プロトコルで、WTPを個別に通常構成されて、制御して、モニターされて、対処できます。 WTPsはほとんどの人々が詳しい伝統的なAPsです。 そのようなWTPsは時々「脂肪APs」か「スタンドアロンAPs」と呼ばれます。
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
o 集結されたWLANアーキテクチャ: 2番目のWLANアーキテクチャファミリーは多くのWTPデバイスを管理するのに1かさらに集結されたコントローラを利用する現れている階層的なアーキテクチャです。 集結されたコントローラは一般的にネットワークで存在しているWTPデバイスを管理して、制御して、構成する主な機能がことであるAccess Controller(西暦)と呼ばれます。 コントロールと管理飛行機のための集結された実体であることに加えて、それは、集結された位置にワイヤレス・アクセスネットワークで通常位置しているので、また、データ飛行機のための自然な集合ポイントになるかもしれません。 西暦は、しばしばL2ブリッジ、スイッチ、またはL3ルータで共同位置していて、それらの特定の場合でAccess BridgeかAccess Routerと呼ばれるかもしれません。 したがって、Access ControllerはL3かL2デバイスのどちらかであるかもしれなく、私たちがこのドキュメント中で費やす総称です。 また、複数のACsが冗長、ロードバランシングなどの目的のためにネットワークで存在しているのも、可能です。 このアーキテクチャファミリーには、いくつかの注意する価値があるはっきりした性格があります。 そして最初に、階層的なアーキテクチャ。
Yang, et al. Informational [Page 7] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [7ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
集結された西暦は大規模ネットワークには、はるかに良い管理可能性を提供します。 2番目に、WTPデバイス自体は、IEEE802.11が機能して、WTPデバイスと西暦でCAPWAPコントロール機能を一緒に提供するので、もう規格で定義されるように完全に802.11の機能を実装するかもしれないというわけではありません。 したがって、それを言うことができます。完全な802.11の機能がすなわち、複数の物理ネットワークデバイス、WTPs、およびACsの向こう側に実装されます。 WTPデバイスが、機能の部分がAPsが実装するそのスタンドアロンであると実装するだけであるので、このアーキテクチャのWTPデバイスは時々軽量か薄いAPsと呼ばれます。
o Distributed WLAN Architecture: The third emerging WLAN
architecture family is the distributed architecture in which the
participating wireless nodes are capable of forming a distributed
network among themselves, via wired or wireless media. A wireless
mesh network is one example within the distributed architecture
family, where the nodes themselves form a mesh network and connect
with neighboring mesh nodes via 802.11 wireless links. Some of
these nodes also have wired Ethernet connections acting as
gateways to the external network.
o 分配されたWLANアーキテクチャ: 3番目の現れているWLANアーキテクチャファミリーは参加のワイヤレスのノードが自分たちの中で分配されたネットワークを形成できる分配されたアーキテクチャです、ワイヤードであるかワイヤレスのメディアを通して。 ワイヤレスの網目状ネットワークは分配されたアーキテクチャファミリーの中の1つの例です。そこでは、ノード自体は、802.11個のワイヤレスのリンクを通して網目状ネットワークを形成して、隣接しているメッシュノードに接続します。 また、これらのいくつかのノードが外部のネットワークへのゲートウェイとして務めているイーサネット接続を配線しました。
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、アルーバAvaya、Chantry Networks、シスコ、Cranite Systems、Extreme Networks、Intoto、Janusys Networks、ノーテルパナソニック、Trapeze、Instant802、Strix Systems、Symbol)と学問研究共同体からの1(UCLA)から来ています。 16の貢献から、1つはAutonomous WLAN Architectureについて説明します、そして、3はDistributed Mesh Architecturesです、そして、残っている12のエントリーがCentralized WLAN Architectureのファミリーでアーキテクチャを表します。
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:
この調査の主な目標は、それらとなぜ中でWLANアーキテクチャ発展で一般的なカテゴリと傾向を特定して、それらの共通する特徴を発見して、何が異なって実行されるかを決定するかことでした。 コンパクトな形式で調査データを表して、「機能的分配マトリクス」は、ベンダーの提供に様々なサービスと機能について表にするのにこのドキュメント、(ほとんどCentralized WLANアーキテクチャが区分するコネ)に使用されます。 これらのサービスと機能は3つの主なカテゴリに分類されます:
Yang, et al. Informational [Page 8] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [8ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
o アーキテクチャ問題: 西暦、WTPの間の接続性の選択。 管理、コントロール、およびデータのどの処理のときにフィジカル・デバイスを見なすかと縁どられる802.11のもののデザイン選択は行われます。
o 802.11 Functions: As described in Section 1.1.
o 802.11の機能: セクション1.1で説明されるように。
o CAPWAP Functions: As described in Section 1.2.
o CAPWAPは機能します: セクション1.2で説明されるように。
For each one of these categories, the mapping of each individual function to network entities implemented by each vendor is shown in tabular form. The rows in the Functional Distribution Matrix represent individual functions that are organized into the above mentioned three categories. Each column of the Matrix represents one vendor's architecture offering in the survey data. See Figure 7 as an example of the Matrix.
これらのカテゴリのそれぞれに関しては、各ベンダーによって実装されたネットワーク実体へのそれぞれの個々の機能に関するマッピングは表にして示されます。 Functional Distributionマトリクスによる行は上記の3つのカテゴリに組織化される個々の機能を表します。 マトリクスに関する各コラムは調査でデータを提供する1つのベンダーのアーキテクチャを表します。 図7をマトリクスに関する例であるとみなしてください。
This Functional Distribution Matrix is intended for the sole purpose of organizing the architecture taxonomy data, and represents the contributors' views of their architectures from an engineering perspective. It does not necessarily imply that a product exists or will be shipped, nor an intent by the vendor to build such a product.
このFunctional Distributionマトリクスは、アーキテクチャ分類学データを組織化する唯一の目的のために意図して、工学見解からそれらのアーキテクチャに関する貢献者の意見を表します。 それは、製品が存在するのを必ず含意もしませんし、出荷もされないで、そのような製品を造るベンダーによる意図をそうされます。
The next section provides a list of definitions used in this document. The rest of this document is organized around the three broad WLAN architecture families that were introduced in Section 1.3. Each architecture family is discussed in a separate section. The section on Centralized Architecture contains more in-depth details than the other two families, largely due to the large number of the survey data (twelve out of sixteen) collected that fall into the Centralized Architecture category. Summary and conclusions are provided at the end to highlight the basic findings from this taxonomy exercise.
次のセクションは本書では使用される定義のリストを提供します。 このドキュメントの残りはセクション1.3で紹介された3つの広いWLANアーキテクチャファミリーの周りで組織化されます。 別々のセクションでそれぞれのアーキテクチャファミリーについて議論します。 Centralized Architectureの上のセクションは他の2つのファミリーより徹底的な詳細を含みます、主にその秋にCentralized Architectureカテゴリに集められた多くの調査データ(16のうちの12)のため。 終わりにこの分類学運動から基本の調査結果を強調するために概要と結論を提供します。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[3]で説明されるように本書では解釈されることであるべきですか?
3. Definitions
3. 定義
3.1. IEEE 802.11 Definitions
3.1. IEEE802.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): IEEE802.11conformant媒体アクセス制御(MAC)を含むデバイスと物理的な層(PHY)はワイヤレスの媒体(WM)に連結します。
Yang, et al. Informational [Page 9] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [9ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Access Point (AP): An entity that has station functionality and provides access to distribution services via the wireless medium (WM) for associated stations.
アクセスポイント(AP): 関連ステーションへのワイヤレスの媒体(WM)で、ステーションの機能性を持って、配布サービスへのアクセスを提供する実体。
Basic Service Set (BSS): A set of stations controlled by a single coordination function.
基本サービスはセットしました(BSS): 1セットのステーションはただ一つのコーディネート機能によって制御されました。
Station Service (SS): The set of services that support transport of medium access control (MAC) service data units (MSDUs) between stations within a basic service set (BSS).
駅のサービス(ss): 基本サービスの中でステーションの間で媒体アクセス制御(MAC)サービスデータ単位(MSDUs)の輸送をサポートするサービスのセットはセットしました(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).
流通制度(DS): 1セットの基本サービスとインタコネクトするのに使用されるシステムは、(BSSs)と統合ローカル・エリア・ネットワーク(LAN)に拡張サービスセット(ESS)を創設するように設定します。
Extended Service Set (ESS): A set of one or more interconnected basic service sets (BSSs) with the same SSID and integrated local area networks (LANs), which appears as a single BSS to the logical link control layer at any station associated with one of those BSSs.
拡張サービスはセットしました(ESS): 1つ以上のインタコネクトされた基本サービスのセットは同じSSIDと統合ローカル・エリア・ネットワーク(LAN)がある(BSSs)を設定します。(どんなステーションの論理的なリンク制御層への独身のBSSもそれらのBSSsの1つと交際したので、それは、現れます)。
Portal: The logical point at which medium access control (MAC) service data units (MSDUs) from a non-IEEE 802.11 local area network (LAN) enter the distribution system (DS) of an extended service set (ESS).
入り口: 非IEEE802.11ローカル・エリア・ネットワーク(LAN)からの媒体アクセス制御(MAC)サービスデータ単位(MSDUs)が拡張サービスの流通制度(DS)に入る論理的なポイントは(ESS)を設定しました。
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)層がワイヤレスの媒体(WM)のただ一つのインスタンスの上に互いとのダイレクトコミュニケーションにないステーションの間でMACサービスデータ単位(MSDUs)を輸送するのを可能にする流通制度(DS)によって提供されました。 これらのサービスは拡張サービスの中のセット(BSSs)が設定する基本サービス(ESS)のアクセスポイント(APs)と、ESSの中の入り口とBSSsの間のMSDUsの輸送と、同じBSSのステーションの間のMSDUsの輸送の間にMSDUにはマルチキャストかブロードキャストあて先アドレスがあるか、目的地が個々のアドレスですが、またはMSDUを送るステーションがDSSにかかわるのを選ぶ場合でMSDUsの輸送を含んでいます。 IEEE802.11の組の間にDSSを提供します。MACs。
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)サービスデータ単位(MSDUs)の配送を可能にするサービス。
Distribution: The service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) within the distribution system (DS).
分配: 流通制度(DS)の中で協会情報を使用することによってサービスデータ単位(MSDUs)を媒体アクセス制御(MAC)に提供するサービス。
Yang, et al. Informational [Page 10] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [10ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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:
新しい用語を定義することにおける動機の1つはいくつかの従来の期間を囲むあいまいさと混乱をはっきりさせることです。そのようなある用語は「アクセスポイント(AP)」です。 人々が"AP"に関して話すとき、通常、彼らはステーション(STA)トラフィックを空気の上にアンテナを持って、802.11PHYを実装して、受けるか、または伝える物理的実体(箱)について言及します。 しかしながら、802.11Standard[1]は有効にステーショントラフィックを空気の上に受け取って、伝えることができるように1セットの論理的なサービスを実装する論理的な実体としてAPをほとんど記述します。 人々が「AP機能」について言及するとき、通常、彼らは物理的実体(箱)によってサポートされた機能の部分集合だけではなく、STAsが直接交信する全体のWLANアクセスネットワークがサポートする論理関数を意味します。 論理関数がただ一つの物理的実体の代わりにネットワークの向こう側に実装されるとき、そのような混乱は特に鋭い場合があります。 さらなる混乱を避けるために、私たちは以下の用語を定義します:
CAPWAP: Control and Provisioning of Wireless Access Points
CAPWAP: ワイヤレス・アクセスポイントのコントロールと食糧を供給すること
IEEE 802.11 WLAN Functions: A set of logical functions defined by the IEEE 802.11 Working Group, including all the MAC services, Station Services, and Distribution Services. These logical functions are required to be implemented in the IEEE 802.11 Wireless LAN (WLAN) access networks by the IEEE 802.11 Standard [1].
IEEE802.11WLANは機能します: 1セットの論理関数はIEEEで802.11作業部会を定義しました、すべてのMACサービス、駅のServices、およびDistribution Servicesを含んでいて。 IEEE802.11Wireless LAN(WLAN)アクセスネットワークでIEEE802.11Standard[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は機能します: 直接そうでない1セットのWLANコントロール機能はIEEEで802.11Standardsを定義しましたが、802.11の有効なコントロール、構成、および管理に不可欠であると考えられて、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): RFアンテナを含む物理的であるかネットワーク実体とIEEE802.11WLANのためにステーショントラフィックを送受信する802.11PHYはネットワークにアクセスします。 そのような物理的実体はしばしば「アクセスポイント」(AP)と呼ばれましたが、また、"AP"は802.11のサービスを実装する論理的な実体を示すことができます。 私たちは上の特性(例えば、rfアンテナと802.11PHYを特集する)で明らかに物理的実体について言及する総称として"WTP"を推薦します、自治の、そして、集結の両方にされたWLANアーキテクチャのネットワーク実体に適切です(以下を見てください)。
Autonomous WLAN Architecture: The WLAN access network architecture family in which all the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented within each Wireless Termination Point (WTP) in the network. The WTPs in
自治のWLANアーキテクチャ: ネットワークでWLANはIEEE802.11とCAPWAP機能の両方(適切であるどこ)を含むすべての論理関数が各Wireless Termination Pointの中で実装されるネットワークアーキテクチャファミリー(WTP)にアクセスします。 中のWTPs
Yang, et al. Informational [Page 11] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [11ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
また、そのようなネットワークはスタンドアロンAPs、または脂肪APsと呼ばれます、これらのデバイスがデバイスがネットワークからサポートなしでいかなる他のも作動するのを可能にする機能のフルセットを実装するので。
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アーキテクチャ: WLANはIEEE802.11とCAPWAP機能の両方(適切であるどこ)を含む論理関数がネットワーク実体の階層構造の向こう側に実装されるネットワークアーキテクチャファミリーにアクセスします。 下のレベルに、WTPsがあります、より高いレベルに、制御するのに責任があるAccess Controllers(ACs)がありますが、全体のWLANアクセスネットワークを構成して、経営していて。
Distributed WLAN Architecture: The WLAN access network architecture family in which some of the control functions (e.g., CAPWAP functions) are implemented across a distributed network consisting of peer entities. A wireless mesh network can be considered an example of such an architecture.
分配されたWLANアーキテクチャ: 何らかのコントロールが機能するWLANアクセスネットワークアーキテクチャファミリー(例えば、CAPWAP機能)は、同輩実体から成りながら、分配されたネットワークの向こう側に実装されます。 そのようなアーキテクチャに関する例であるとワイヤレスの網目状ネットワークを考えることができます。
Access Controller (AC): The network entity in the Centralized WLAN Architecture that provides WTPs access to the centralized hierarchical network infrastructure in the data plane, control plane, management plane, or a combination therein.
コントローラ(西暦)にアクセスしてください: そこにデータ飛行機、制御飛行機、管理飛行機、または組み合わせで集結された階層的なネットワークインフラへのアクセスをWTPsに供給するCentralized WLAN Architectureのネットワーク実体。
Standalone WTP: Refers to the WTP in Autonomous WLAN Architecture.
スタンドアロンWTP: 自治のWLANアーキテクチャでWTPについて言及します。
Controlled WTP: Refers to the WTP in Centralized WLAN Architecture.
制御WTP: 集結されたWLANアーキテクチャでWTPについて言及します。
Split MAC Architecture: A subgroup of the Centralized WLAN Architecture whereby WTPs in such WLAN access networks only implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while all the remaining management and data frames are tunnelled to the AC for centralized processing. The IEEE 802.11 MAC, as defined by IEEE 802.11 Standards in [1], is effectively split between the WTP and AC.
MACアーキテクチャを分けてください: そのようなWLANアクセスネットワークにおけるWTPsが、IEEE802.11のために遅れが敏感なMACサービス(すべての制御フレームといくつかの管理フレームを含んでいる)であると実装するだけですが、すべての残っている管理とデータフレームが集結された処理のために西暦にトンネルを堀られるCentralized WLAN Architectureのサブグループ。 IEEE802.11MACであり、IEEEによって定義されるように事実上、[1]の802.11StandardsがWTPと西暦の間の分裂です。
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アーキテクチャ: Centralized WLAN Architectureのサブグループ。そこでは、802.11のMAC機能(遅れ敏感な機能を含んでいる)の全体のセットが西暦で実装されます。 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アーキテクチャ: Centralized WLAN Architectureのサブグループ。そこでは、802.11のMAC機能(802.11管理フレーム処理の大部分を含んでいる)の大多数か全体のセットがWTPで実装されます。 したがって、802.11MACはPHYに伴うWTPで完全であって、地方のままです。
Yang, et al. Informational [Page 12] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [12ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
WLANアーキテクチャを分けてください: 使用はWLANアーキテクチャを集結しました。
Hierarchical WLAN Architecture: Use Centralized WLAN Architecture.
階層的なWLANアーキテクチャ: 使用はWLANアーキテクチャを集結しました。
Standalone Access Point: Use Standalone WTP.
スタンドアロンアクセスポイント: スタンドアロンWTPを使用してください。
Fat Access Point: Use Standalone WTP.
太っているアクセスポイント: スタンドアロンWTPを使用してください。
Thin Access Point: Use Controlled WTP.
アクセスポイントを薄くしてください: 使用はWTPを制御しました。
Light weight Access Point: Use Controlled WTP.
重さのAccess Pointを点灯してください: 使用はWTPを制御しました。
Split AP Architecture: Use Local MAC Architecture.
APアーキテクチャを分けてください: ローカルのMACアーキテクチャを使用してください。
Antenna AP Architecture: Use Remote MAC Architecture.
アンテナAPアーキテクチャ: リモートMACアーキテクチャを使用してください。
4. Autonomous Architecture
4. 自治のアーキテクチャ
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はAutonomous WLAN Architectureの例のネットワークを示しています。 このアーキテクチャは単一のフィジカル・デバイス、Wireless Termination Point(WTP)のすべての802.11の機能性を実装します。 このアーキテクチャの具体化は802.11個のフレームの間でイーサネットインタフェースからのそのラジオインタフェースと802.3個のフレームから/までの/に翻訳するWTPです。 異なったWTPsのイーサネットインタフェースとインタコネクトする802.3インフラストラクチャは流通制度を提供します。 また、それは802.3の統合LANセグメントに入り口を提供できます。
Yang, et al. Informational [Page 13] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [13ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
+---------------+ +---------------+ +---------------+
| 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
+------+------+
+---------------+ +---------------+ +---------------+ | 802.11 BSS1| | 802.11 BSS2| | 802.11 BSS3| | ... | | ... | | ... | | +-----+ | | +-----+ | | +-----+ | +----| WTP|----+ +----| WTP|----+ +----| WTP|----+ +--+--+ +--+--+ +--+--+ |イーサネット| | +------------------+ | +------------------+ | | | +---+--+--+---+ | イーサネット| 802.3 ラン--------------+ スイッチ+-------------- 802.3 LANセグメント1| | セグメント2+------+------+
Figure 1: Example of Autonomous WLAN Architecture
図1: 自治のWLANアーキテクチャに関する例
A single physical WTP can optionally be provisioned as multiple virtual WTPs by supporting multiple SSIDs to which 802.11 clients may associate. In some cases, this will involve putting a corresponding 802.1Q VLAN tag on each packet forwarded to the Ethernet infrastructure and removing 802.1Q tags prior to forwarding the packets to the wireless medium.
どの802.11人のクライアントに複数のSSIDsをサポートするかによる複数の仮想のWTPsが交際するとき、任意に独身の物理的なWTPに食糧を供給することができます。 いくつかの場合、これは、ワイヤレスの媒体にパケットを送る前にイーサネットインフラストラクチャに送られて、802.1Qタグを移しながら対応する802.1Q VLANタグを各パケットに置くことを伴うでしょう。
The scope of the ESS(s) created by interconnecting the WTPs will be confined by the constraints imposed by the Ethernet infrastructure.
WTPsとインタコネクトすることによって作成されたESS(s)の範囲はイーサネットインフラストラクチャによって課された規制で閉じ込められるでしょう。
Authentication of 802.11 clients may be performed locally by the WTP or by using a centralized authentication server.
802.11人のクライアントの認証は、WTPか集結された認証サーバを使用することによって、局所的に実行されるかもしれません。
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に閉じ込められます。 クライアント認証と暗号化/復号化見解からのどんな付加的な含意もありません、メカニズムが802.11i暗号化/復号化のために必要としたAAAインタフェースとキー生成が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とイーサネットインフラストラクチャの間には、このアーキテクチャの安全要求の1つは互いの認証のためにあります。 それが接続するWTPとイーサネットスイッチの間の802.1Xなどの既存のメカニズムはこれを確実にすることができます。 別の重要な安全保障問題はWTPがしっかりカギをかけてない最もありそうですが、バックエンドシステムと伝える秘密の情報を含んでいるという事実です、AAAやSNMPのように。 IT人員が「テンプレート」をすべてのデバイスに押す一般的な管理法を使用するので、そのようなデバイスの窃盗は潜在的に有線ネットワークに感染するでしょう。
Yang, et al. Informational [Page 14] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [14ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
5. Centralized WLAN Architecture
5. 集結されたWLANアーキテクチャ
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 ArchitectureはWLAN市場の現れているアーキテクチャファミリーです。 Autonomous WLAN Architectureとは逆に、Centralized WLAN Architectureは、ネットワーク全体のモニターを可能にして、管理スケーラビリティを改良して、ダイナミックなconfigurabilityを容易にするためにAccess Controller(s)と呼ばれる1かさらに集結されたコントローラを雇います。そこでは、802.11の機能とネットワーク制御機能が各Wireless Termination Point(WTP)の中ですべて実装されます。
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.
以下の図はCentralized WLAN Architectureネットワーク図を図式的に示しています。そこでは、Access Controller(西暦)はインタコネクト媒体で複数のWireless Termination Points(WTPs)に接続します。 これは、セクション5.1で説明されるようにダイレクト接続、切り換えられたL2、またはL3によって発送されたネットワークであるかもしれません。 西暦はWTPデバイスと構成と制御情報を交換します、集結されたポイントからネットワークの経営を許して。 Centralized WLAN Architectureファミリーのデザインは、西暦が必ずデータ飛行機でWTP(s)からの/に仲裁すると推定しません(ダイヤグラムが示すかもしれないように)。 後でこのセクションにその他の詳細を提供します。
+---------------+ +---------------+ +---------------+
| 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 |
| ... | | ... | | ... |
| +-------+ | | +-------+ | | +-------+ |
+----| WTP |--+ +----| WTP |--+ +----| WTP |--+
+---+---+ +---+---+ +---+---+
| | |
+------------------+ | +-----------------+
| |...|
+----+--+---+--------+
| Interconnection |
+-------+------------+
|
|
+-----+----+
| AC |
+----------+
+---------------+ +---------------+ +---------------+ | 802.11 BSS1| | 802.11 BSS2| | 802.11 BSS3| | ... | | ... | | ... | | +-------+ | | +-------+ | | +-------+ | +----| WTP|--+ +----| WTP|--+ +----| WTP|--+ +---+---+ +---+---+ +---+---+ | | | +------------------+ | +-----------------+ | |...| +----+--+---+--------+ | インタコネクト| +-------+------------+ | | +-----+----+ | 西暦| +----------+
Figure 2: Centralized WLAN Architecture Diagram
図2: 集結されたWLANアーキテクチャダイヤグラム
Yang, et al. Informational [Page 15] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [15ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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).
ダイヤグラムで、CAPWAP機能のすべてを提供するただ一つの物理的実体がセクション1.2に記載したように上では、西暦が示されます。 しかしながら、これはいつもそうであるかもしれないというわけではありません。 機能の、より厳密な試験は、それらの異なったリソース要件(例えば、CPU、メモリ、ストレージ)が異なったデバイスの向こう側に分配されるかもしれないのを明らかにします。 例えば、複雑なラジコンアルゴリズムはCPU徹底的である場合があります。 イメージと構成を保存して、ダウンロードするのはストレージ徹底的である場合があります。 したがって、異なったCAPWAP機能はそれらのリソース要件の異なった本質のため異なったフィジカル・デバイスで実装されるかもしれません。 上のダイヤグラムによる'西暦'であるとマークされたネットワーク実体は必ず単一のフィジカル・デバイスとして考えられるのではなく、論理関数の多様性として考えられるべきです。 ACsはまた、何らかのコントロールが機能であると局所的に実装するのを選んで、別々の箱の上に通常実装される他の世界的なネットワーク管理機能にアクセスするためにインタフェースを前提とするかもしれません、SNMP Network Management駅やAAAバックエンドサーバ(例えば、Radius Authentication Server)のように。
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.
ダイレクト接続を含む西暦、WTPsの間でL2が接続を切り換えたと考えるために、いくつかの接続性オプションがありました、そして、L3は接続を発送しました、図3、4、および5に示されるように。
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP |
+--+--+ +--+--+
-------+------ LAN| +-------+-------+ | 西暦| +----+-----+----+ | | +---+ +---+ | | +--+--+ +--+--+ | WTP| | WTP| +--+--+ +--+--+
Figure 3: Directly Connected
図3: 直接接続されます。
Yang, et al. Informational [Page 16] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [16ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
-------+------ LAN
|
+-------+-------+
| AC |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +-----+-----+
| WTP | | Switch |
+--+--+ +---+-----+-+
| |
+-----+ +-----+
| WTP | | WTP |
+-----+ +-----+
-------+------ LAN| +-------+-------+ | 西暦| +----+-----+----+ | | +---+ +---+ | | +--+--+ +-----+-----+ | WTP| | スイッチ| +--+--+ +---+-----+-+ | | +-----+ +-----+ | WTP| | WTP| +-----+ +-----+
Figure 4: Switched Connections
図4: 切り換えられたコネクションズ
+-------+-------+
| AC |
+-------+-------+
|
--------+------ LAN
|
+-------+-------+
| Router |
+-------+-------+
|
-----+--+--+--- LAN
| |
+---+ +---+
| |
+--+--+ +--+--+
| WTP | | WTP|
+--+--+ +--+--+
+-------+-------+ | 西暦| +-------+-------+ | --------+------ LAN| +-------+-------+ | ルータ| +-------+-------+ | -----+--+--+--- LAN| | +---+ +---+ | | +--+--+ +--+--+ | WTP| | WTP| +--+--+ +--+--+
Figure 5: Routed Connections
図5: 発送されたコネクションズ
5.2. Overview of Three Centralized WLAN Architecture Variants
5.2. 3の概要は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
ダイナミックで一貫したネットワークマネージメントはCentralized Architectureに関するプライマリ動機の1つです。 また、ベンダーからの調査データは、このアーキテクチャファミリーの異なった品種が様々な可能な展開シナリオのための複雑なセットの異なった必要条件を満たすために現れたのを示します。 また、これは論理関数の実装に関する802.11規格[1]において、固有の柔軟性の直接の結果です。
Yang, et al. Informational [Page 17] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [17ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
「アクセスポイント(AP)」という諸条件で広く説明されています。 物理ネットワーク実体へのこれらのAP機能のどんな標準のマッピングもないので、いくつかのデザイン選択が関連商品を提供するベンダーによってされました。 そのうえ、大きいワイヤレス・ネットワークのモニターしていて一貫した構成を求める需要増はそれの大部分が一般的なデザインの特性とサービス目標を共有する様々なベンダーによって提供された1セットの'付加価値が付いた'サービスをもたらしました。
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.
以下では、私たちはすなわち、Centralized WLAN Architectureのファミリーの中で調査データから観測された、3つの主な異形、Local MAC、Split MAC、およびRemote MACアプローチについて説明します。 各アプローチのために、私たちは様々な機能のマッピングの特性を各ベンダーからネットワーク実体に提供します。 Local MAC、Split MAC、およびRemote MACの命名は機能、および特に802.11のMAC機能がどうネットワーク実体に写像されるかを反映します。 地方のMACは、MAC機能がWTPsに完全であって、地方であることで残っているのを示します、Remote MACは、MACがネットワークでWTPからリモート西暦までの遠くに移行したのを指示しますが。 分裂MACは、MACが主にリアルタイムで感度の系列に沿ってWTPsとACsで分割されるのを示します。 通常、Split 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:
Local MAC、Split MAC、およびRemote MACアーキテクチャの中の違いはグラフィカルに以下の図的に案内されます:
+--------------+--- +---------------+--- +--------------+---
| CAPWAP | | CAPWAP | | CAPWAP |
| functions |AC | functions |AC | functions |
|==============|=== |---------------| |--------------|
| | | non RT MAC | | |AC
| 802.11 MAC | |===============|=== | 802.11 MAC |
| |WTP | Realtime MAC | | |
|--------------| |---------------|WTP |==============|===
| 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP
+--------------+--- +---------------+--- +--------------+---
+--------------+--- +---------------+--- +--------------+--- | CAPWAP| | CAPWAP| | CAPWAP| | 機能|西暦| 機能|西暦| 機能| |==============|=== |---------------| |--------------| | | | 非RT MAC| | |西暦| 802.11 Mac| |===============|=== | 802.11 Mac| | |WTP| リアルタイムで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
図6: 集結されたWLANアーキテクチャファミリーの中の3つの建築異形
Yang, et al. Informational [Page 18] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [18ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
図6(a)に示されるLocal MACアーキテクチャモデルの主な動機はWTPsと西暦の間で802.11MACの機能性を分けないでネットワークアクセス方針と管理機能(セクション1.2で説明されたCAPWAP機能)を西暦へ積み下ろすことです。 全体の802.11MACはWTPsに局所的に住んでいます、STAsのためのすべての802.11の管理とコントロールフレーム処理を含んでいて。 他方では、WTPデバイスの管理と構成に関連する情報は、WTPデバイスのためにネットワークの経営を容易にして、一貫したネットワーク全体の構成を維持するために集結された西暦と伝えられます。
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は調査におけるLocal MACアプローチに続く6つのベンダーによってされたデザイン選択の表表現を示しています、上記のアーキテクチャ問題に関して。 「WTP-交流の接続性」はあらゆるベンダーのアーキテクチャがサポートすることができるWTPsと西暦の間のタイプの接続性を示しています。 明確に、すべてのベンダーがWTPsと西暦の間の発送されたネットワークの接続性をL3にサポートすることができます。(それは、また、ダイレクト接続とL2交換網がすべてのベンダーがサポートされるのを含意します)。 '802.11管理終了'、および'802.11コントロール終了'で、私たちは802.11の管理と制御フレームの処理がそれぞれ行われる物理ネットワークデバイスを指示します。 ここのすべてのベンダーが、WTPsの802.11の管理と制御フレームを終えるのを選びます。 テーブルの最後の行('802.11データ集合')は802.11個のデータフレームの1STAから別のもの(ことによるとDSを通した)までの集合と配送が実行されるデバイスについて言及します。 テーブルによって示されるように、ベンダーはすべての802.11データ通信量が西暦を通して集められて、発送されるかどうかに関して異なった選択をします。 調査データは、いくつかのベンダーが、ACsかACsからすべてのステーショントラフィックをトンネルを堀るか、またはカプセル化するのを選ぶのを示します、また、西暦がこのWLANアクセスネットワークのためのアクセスルータとして機能するのを含意して。 他のベンダーは、西暦に集中制御を保っている間、ステーショントラフィックを局所的にブリッジされるか、または発送させることによってコントロールとデータ飛行機を切り離すのを選びます。
Yang, et al. Informational [Page 19] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [19ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
WTP-AC
connectivity L3 L3 L3 L3 L3
Arch7 Arch8 Arch9 Arch10 Arch11----- ----- ----- ------ ------ WTP-交流の接続性L3 L3 L3 L3 L3
802.11 mgmt
termination WTP WTP WTP WTP WTP
802.11 管理終了WTP WTP WTP WTP WTP
802.11 control
termination WTP WTP WTP WTP WTP
802.11 コントロール終了WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC WTP AC WTP
802.11 データ集合AC AC WTP AC WTP
Figure 7: Architecture Considerations for Local MAC Architecture
図7: ローカルのMACアーキテクチャのためのアーキテクチャ問題
Figure 8 reveals that most of the CAPWAP functions, as described in Section 1.2, are implemented at the AC with help from WTPs to monitor RF channels, and collect statistics and state information from the STAs, as the AC offers the advantages of network-wide visibility, which is essential for many of the control, configuration, and value-added services.
エイト環はSTAsからセクション1.2で説明されるCAPWAP機能の大部分が西暦で助けでWTPsから実装されて、RFチャンネルをモニターして、統計と州の情報を集めるのを明らかにします、西暦がコントロール、構成、および付加価値が付いたサービスの多くに、不可欠のネットワーク全体の目に見えることの利点を示すとき。
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
RF
Monitoring WTP WTP AC/WTP WTP WTP
Arch7 Arch8 Arch9 Arch10 Arch11----- ----- ----- ------ ------ rfのモニターしているWTP WTP西暦/WTP WTP WTP
RF
Config. AC AC AC AC AC
rfコンフィグ交流交流交流交流西暦
WTP config. AC AC AC AC AC
WTPコンフィグ交流交流交流交流西暦
WTP
Firmware AC AC AC AC AC
WTPファームウェア交流交流交流交流西暦
STA state
info
database AC AC/WTP AC/WTP AC/WTP AC
STA州のインフォメーションデータベース交流西暦/WTP AC/WTP AC/WTP AC
AC/WTP
mutual
authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP
西暦/WTPの互いのauthent。 西暦/WTP西暦/WTP西暦/WTP西暦/WTP西暦/WTP
Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture
エイト環: ローカルのMACアーキテクチャのためのCAPWAP機能に関するマッピング
Yang, et al. Informational [Page 20] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [20ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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の機能の大部分がLocal MAC ArchitectureのためにWTPsで実装されるのを示します、ベンダーの中の配布サービスに関するいくつかの小異、802.11eスケジューリング、および802.1X/EAP認証で。 配布サービスの違いは、より早く図7の「802.11データ集合」に関して説明されるそれと一致しています。
Arch7 Arch8 Arch9 Arch10 Arch11
----- ----- ----- ------ ------
Distribution
Service AC AC WTP AC WTP
Arch7 Arch8 Arch9 Arch10 Arch11----- ----- ----- ------ ------ 配布サービス交流交流WTP交流WTP
Integration
Service WTP WTP WTP WTP WTP
統合サービスWTP WTP WTP WTP WTP
Beacon
Generation WTP WTP WTP WTP WTP
標識世代WTP WTP WTP WTP WTP
Probe
Response WTP WTP WTP WTP WTP
応答WTP WTP WTP WTP WTPを調べてください。
Power mgmt
Packet
Buffering WTP WTP WTP WTP WTP
パワー管理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。 Reassociation交流WTP WTP WTP WTP
WME/11e
--------------
classifying AC WTP
WME/11e-------------- AC WTPを分類します。
scheduling WTP AC/WTP WTP WTP WTP
スケジューリングWTP AC/WTP WTP WTP WTP
queuing WTP WTP WTP WTP
WTP WTP WTP WTPを列に並ばせます。
Yang, et al. Informational [Page 21] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [21ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Authentication
and Privacy
--------------
802.1X/EAP AC AC AC/WTP AC AC/WTP
認証とプライバシー-------------- 802.1X/EAP交流交流西暦/WTP交流西暦/WTP
Keys
Management AC AC WTP AC AC
キー管理交流交流WTP交流西暦
802.11
Encryption/
Decryption WTP WTP WTP WTP WTP
802.11 暗号化/復号化WTP WTP WTP WTP WTP
Figure 9: Mapping of 802.11 Functions for Local MAC Architecture
図9: ローカルのMACアーキテクチャのための802.11の機能に関するマッピング
From Figures 7, 8, and 9, it is clear that differences among vendors in the Local MAC Architecture are relatively minor, and most of the functional mapping appears to be common across vendors.
図7、8、および9から、Local MAC Architectureのベンダーの中の違いが比較的小さい方であり、機能的マッピングの大部分がベンダーの向こう側に一般的であるように見えるのは、明確です。
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)に表現されるように、Split MACアーキテクチャの後ろの本旨はWTPsの代わりに集結された西暦に関する802.11MACの機能性の一部を実装することです、WTPデバイスを管理して、モニターするための必要なサービスを提供することに加えて。 通常、802.11MACの機能が西暦によって提供される必要がある決定は考えられたサービスの時間臨界に基づいています。
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.
Split MACアーキテクチャでは、WTPはワイヤレスの物理的なリンクのインフラストラクチャ側面を終えて、ラジオ関連の管理を提供して、また、802.11MACの時間重要な機能性を実装します。 さらに、非リアルタイム管理機能は集結された西暦によって扱われます、より高い平らなサービスと共に、構成や、QoSや、ロードバランシングのための方針や、アクセスコントロールリストなどのように。 Local MACとSplit MACの主要な区別は非リアルタイム機能に関連します: Split MACアーキテクチャでは、西暦は802.11の非リアルタイム機能を終えます、WTPがLocal MACアーキテクチャでは、802.11の非リアルタイム機能を終えて、その結果適切なメッセージを西暦に送りますが。
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
Split MACアプローチを取ることに関するいくつかの動機があります。 1番目はそれぞれのBSSの場所だけに特定の、そして、関連している機能性をWTPへ積み下ろすことです、西暦が多くの'軽量'WTPデバイスに比例するのを許容するために。 そのうえ、リアルタイムでの機能性は、潜在規制を受けることがあって、802.11の制御フレーム(または、他のリアルタイムで情報)のトランスミッションのため複数のホップの上に遅れを許容できません。 そして後者が西暦の間の接続性のための利用可能な選択を制限するだろう。
Yang, et al. Informational [Page 22] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [22ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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サービスを切り離すのに使われます。 別の考慮はそれをできるだけ安く簡単にするWTPのコスト削減です。 最終的に、移行は暗号化のように機能します、そして、西暦への復号化は感染しているWTPから脆弱性を減少させます、ユーザ暗号化キーがもう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のMAC機能が「リアルタイムで」であると考えられる802.11仕様への明確な定義が全くないので、各ベンダーはそれなりにこれを解釈します。 ほとんどのベンダーが、802.11MACの以下のサービスがリアルタイムでサービスの例であるのに同意して、WTPsで実装されるために選ばれています。
o Beacon Generation
o 標識世代
o Probe Response/Transmission
o 応答/トランスミッションを調べてください。
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o 制御フレームの処理: Cf Cf PS RTS/CTS/ACK/投票/終わり/ACK
o Synchronization
o 同期
o Retransmissions
o Retransmissions
o Transmission Rate Adaptation
o 通信速度適合
The following list includes examples of non-realtime MAC functions as interpreted by most vendors:
ほとんどのベンダーによって解釈されるように以下のリストは非リアルタイムMAC機能に関する例を含んでいます:
o Authentication/De-authentication
o 反-認証/認証
o Association/Disassociation/Reassociation/Distribution
o 協会/Disassociation/Reassociation/分配
o Integration Services: Bridging between 802.11 and 802.3
o 統合サービス: 802.11〜802.3をブリッジします。
o Privacy: 802.11 Encryption/Decryption
o プライバシー: 802.11暗号化/復号化
o Fragmentation/Defragmentation
o 断片化/デフラグメンテーション
However, some vendors may choose to classify some of the above "non- realtime" functions as realtime functions in order to support specific applications with strict QoS requirements. For example, Reassociation is sometimes implemented as a "realtime" function to support VoIP applications.
しかしながら、いくつかのベンダーが、リアルタイムが厳しいQoS要件で特定のアプリケーションをサポートするために機能するとき上の「非リアルタイム」機能のいくつかを分類するのを選ぶかもしれません。 例えば、Reassociationは、VoIPにアプリケーションをサポートするために「リアルタイムで」機能として時々実装されます。
Yang, et al. Informational [Page 23] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [23ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.11MACの非リアルタイム局面は西暦によって802.11個の生の管理フレーム(MACを分割する)の処理で扱われます。 図10の以下のマトリクスはアーキテクチャ問題に関するSplit MACデザインに従う6つのベンダーによってされたデザイン選択の表表現を提供します。 ほとんどのベンダーが、L3がWTPsとACsの間の接続性であるとサポートしている間、或るものはネットワークの向こう側に2つの物理的実体でMACを分割するのからの、よりきつい遅れ規制の結果になるのによる切り換えられた接続をL2にサポートすることができるだけです。 図7では、WTPがSplit MACとLocal MACの両方で802.11の制御フレームを処理するのは、明確です。 2の違いが802.11個の管理フレームへの終了ポイントにあります。 少なくともいくつかである、地方のMACはWTPの802.11個の管理フレームを終えて、802.11では、管理フレームはSplit MAC Architectureのための西暦で終えられます。 WTPデバイスがアドレス可能なIP、多くの場合ダイレクト接続のいずれでもあるので、セクション1.2のL2によって切り換えられたか、L3によって発送された接続を使用できます。 イーサネットカプセル化だけが実行されるなら(例えば、Architecture4のように)、ダイレクト接続とL2によって切り換えられた接続だけがサポートされます。
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
WTP-AC
connectivity L3 L3 L3 L2 L3 L3
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6----- ----- ----- ----- ----- ----- WTP-交流の接続性L3 L3 L3 L2 L3 L3
802.11 mgmt
termination AC AC AC AC AC/WTP AC
802.11 管理終了交流交流交流交流西暦/WTP AC
802.11 control
termination WTP WTP WTP WTP WTP WTP
802.11 コントロール終了WTP WTP WTP WTP WTP WTP
802.11 data
aggregation AC AC AC AC AC AC
802.11 データ集合交流交流交流交流交流西暦
Figure 10: Architecture Considerations for Split MAC Architecture
図10: 分裂MACアーキテクチャのためのアーキテクチャ問題
Yang, et al. Informational [Page 24] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [24ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
Local MAC Architectureと同様です、図11のマトリクスはCAPWAPコントロール機能の大部分が西暦で実装されるのを示します。 例外は構成をモニターして何らかのケースRF構成のRFです。(それは、WTPsで局所的に実行されます)。
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ----- ----- -----
RF
Monitoring WTP WTP WTP WTP WTP WTP
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6----- ----- ----- ----- ----- ----- rfのモニターしているWTP WTP WTP WTP WTP WTP
RF
Config. AC/WTP AC/WTP AC AC AC
rfコンフィグ西暦/WTP西暦/WTP交流交流西暦
WTP config. AC AC AC AC AC
WTPコンフィグ交流交流交流交流西暦
WTP
Firmware AC AC AC AC AC
WTPファームウェア交流交流交流交流西暦
STA state
info
database AC AC AC AC AC
STA州のインフォメーションデータベース交流交流交流交流西暦
AC/WTP
mutual
authent. AC/WTP AC/WTP AC/WTP AC/WTP
西暦/WTPの互いのauthent。 西暦/WTP西暦/WTP西暦/WTP西暦/WTP
Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture
図11: 分裂MACアーキテクチャのためのCAPWAP機能に関するマッピング
Yang, et al. Informational [Page 25] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [25ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
Split MAC Architectureに、最もおもしろいマトリクスは802.11の機能のためのFunctional Distributionマトリクスです、図12に以下に示されるように。 ベンダーはある規則性でWTPsと西暦に機能を写像します。 例えば、すべてのベンダーが、802.1X/EAP認証と重要管理に伴う西暦でDistribution、Integration Serviceを実装するのを選びます。 また、すべてのベンダーが、WTPsで標識世代を実装するのを選びます。 他方では、ベンダーは、時々他の機能の多くを異なって写像するのを選びます。 したがって、Split MAC ArchitecturesはMACが分割される正確な方法に関して一貫していません。
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6
----- ----- ----- ------ ----- -----
Distribution
Service AC AC AC AC AC AC
Arch1 Arch2 Arch3 Arch4 Arch5 Arch6----- ----- ----- ------ ----- ----- 配布サービス交流交流交流交流交流西暦
Integration
Service AC AC AC AC AC AC
統合サービス交流交流交流交流交流西暦
Beacon
Generation WTP WTP WTP WTP WTP WTP
標識世代WTP WTP WTP WTP WTP WTP
Probe
Response WTP AC/WTP WTP WTP WTP WTP
応答WTP西暦/WTP WTP WTP WTP WTPを調べてください。
Power mgmt
Packet
Buffering WTP WTP WTP AC AC/WTP WTP
パワー管理Packet Buffering WTP WTP WTP交流西暦/WTP WTP
Fragmentation
Defragment. WTP WTP AC AC AC
断片化はデフラグメントします。 WTP WTP交流交流西暦
Association
Disassoc.
Reassociation AC AC AC AC WTP AC
協会Disassoc。 Reassociation交流交流交流交流WTP西暦
WME/11e
--------------
classifying AC AC AC AC
WME/11e-------------- 交流交流交流西暦を分類します。
scheduling WTP/AC AC WTP AC AC WTP/AC
スケジューリングWTP/AC AC WTP AC AC WTP/西暦
queuing WTP/AC WTP WTP AC WTP WTP
WTP/AC WTP WTP AC WTP WTPを列に並ばせます。
Yang, et al. Informational [Page 26] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [26ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Authentication
and Privacy
--------------
認証とプライバシー--------------
802.1X/EAP AC AC AC AC AC AC
802.1X/EAP交流交流交流交流交流西暦
Keys
Management AC AC AC AC AC AC
キー管理交流交流交流交流交流西暦
802.11
Encryption/
Decryption WTP AC WTP AC AC AC
802.11 暗号化/復号化WTP交流WTP交流交流西暦
Figure 12: Mapping of 802.11 Functions for Split MAC Architecture
図12: 分裂MACアーキテクチャのための802.11の機能に関するマッピング
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.
Remote MAC Architectureに関する主な動機の1つはWTPsができるだけ軽い重さであることを保つことです、Access ControllerへWTPsにラジオインタフェースしか持たないで、802.11のMAC機能の全体のセットを積み下ろすことによって(遅れ敏感なものを含んでいます)。 これはMACと他のCAPWAPコントロール機能のすべての複雑さを集結されたコントローラに任せます。
The WTP acts only as a pass-through between the Wireless LAN clients (STA) and the AC, though they may have an additional feature to convert the frames from one format (802.11) to the other (i.e., Ethernet, TR, Fiber). The centralized controller provides network monitoring, management and control, an entire set of 802.11 AP services, security features, resource management, channel selection features, and guarantees Quality of Service to the users. Because the MAC is separated from the PHY, we call this the "Remote MAC Architecture". Typically, such architecture is deployed with special attention to the connectivity between the WTPs and AC so that the delay is minimized. The Radio over Fiber (RoF) from Architecture 5 is an example of Remote MAC Architecture.
WTPは単にWireless LANクライアント(STA)と西暦の間を通じて通るとして機能します、彼らには、1つの形式(802.11)からもう片方(すなわち、イーサネット、TR、Fiber)までフレームを変換する追加特徴があるかもしれませんが。 集結されたコントローラはネットワーク監視と管理とコントロール、Serviceの802.11のAPサービス、セキュリティ機能、資源管理、経路選択機能、および保証Qualityの全体のセットをユーザに提供します。 MACがPHYと切り離されるので、私たちは、これを「リモートMACアーキテクチャ」と呼びます。 通常、そのようなアーキテクチャがWTPsと西暦の間の接続性に関する特別な注意で配布されるので、遅れは最小にされます。 Architecture5からのFiber(RoF)の上のRadioはRemote MAC Architectureに関する例です。
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:
すべての3Centralized Architectures(地方のMAC、Split MAC、およびRemote MAC)の向こう側の2つの共通点は以下の通りです。
o Most of the CAPWAP functions related to network control and
configuration reside on the AC.
o ネットワーク制御と構成に関連するCAPWAP機能の大部分は西暦に住んでいます。
o IEEE 802.11 PHY resides on the WTP.
o IEEE802.11PHYはWTPに住んでいます。
Yang, et al. Informational [Page 27] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [27ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
Remote MACと他の2Centralized Architectures(すなわち、Local MACとSplit MAC)の間には、明確な違いがあります、802.11MACがPHYと前者で完全に切り離されるとき他の2は保たれますが、MACの何らかの一部がPHYと共にWTPsで機能します。 PHYとMAC分離の含意は厳しくWTPsとACsの間のインタコネクトの種類を制限するということです、802.11のタイミング規制が満たされているように。 より早く指摘されるように、通常、これはRemote MAC ArchitectureのためのWTPと西暦の間のインタコネクトの上で、よりきつい規制をもたらします。 Remote MAC Architectureの利点はある展開シナリオのために可能な限り軽い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.
Local MACとSplit MACの共通点と違いは、図7を図10にたとえることによって、最も明確に見られます。 共通点は802.11の制御フレームがどちらの場合もWTPsで終えられるということです。 Local MACとSplit MACの主な違いはWTPがSplit MACの802.11の制御フレームだけを終えるということです、WTPがLocal MACのすべての802.11個のフレームを終えるかもしれませんが。 この違いのおもしろい結果はIntegration Service(本質的には802.11〜802.3個のフレームをブリッジするのを示す)がSplit MACの西暦、Local MACのWTPによって実装されるということです、図9と12にそれぞれ示されるように。
As a second note, the Distribution Service, although usually provided by the AC, can also be implemented at the WTP in some Local MAC architectures. This approach is meant to increase performance in delivering STAs data traffic by avoiding tunneling it to the AC, and relaxing the dependency of the WTP from the AC. Therefore, it is possible for the data and control planes to be separated in the Local MAC Architecture.
2番目の注意として、西暦で通常提供しますが、また、WTPでいくつかのLocal MACアーキテクチャでDistribution Serviceを実装することができます。 このアプローチは、西暦にそれにトンネルを堀って、西暦からWTPの依存を弛緩するのを避けることによってデータ通信量をSTAsに提供しながら、性能を増やすことになっています。 したがって、データと制御飛行機が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).
すべての802.11トラフィックがSplit MAC Architectureの場合におけるACsで集められますが、複数のACsを使うことによって、まだデータと制御飛行機を切り離すことができます。 例えば、西暦1年はCAPWAP機能(制御飛行機)の大部分を実装することができます、(データ飛行機)をブリッジする802.11個のフレームに他のACsを使用できますが。
Each of the three architectural variants may be advantageous for certain deployment scenarios. While the Local MAC retains most of the STA's state information at the local WTPs, Remote MAC centralizes most of the state into the back-end AC. Split MAC sits somewhat in the middle of this spectrum, keeping some state information locally at the WTPs, and the rest centrally at the AC. Many factors should be taken into account to determine the exact balance desired between the centralized and decentralized state. The impact of such balance on network manageability is currently a matter of dispute within the technical community.
ある展開シナリオに、それぞれの3つの建築異形が有利であるかもしれません。 Local MACが地方のWTPsでSTAの州の情報の大部分を保有している間、Remote MACは状態の大部分をバックエンド西暦に集結します。 分裂MACはいくらかこのスペクトルの中央に座っています、西暦に中心にWTPs、および残りで局所的に何らかの州の情報を保って。 多くの要素が、集結されて分散している状態の間で必要な正確なバランスを決定するために考慮に入れられるべきです。 現在、ネットワークの管理可能性のそのようなバランスの影響は技術的な共同体の中の論争の問題です。
Yang, et al. Informational [Page 28] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [28ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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:
WTPは、西暦、WTPの間でどんなメッセージも交換できる前に、最初に、西暦を認証して、ともに記名して、次に、ファームウェアをダウンロードして、西暦で制御チャンネルを確立するように発見する必要があります。 コントロールと構成のためのWTPと西暦の間の交換処理はその後に起こることができます。 以下のリストは彼らの典型的なオーダーにおけるWTPと西暦の間で通常実行される基本的な操作について概説します:
1. Discovery: The WTPs discover the AC with which they will be bound
to and controlled by. The discovery procedure can employ either
static or dynamic configuration. In the latter case, a protocol
is used in order for the WTP to discover candidate AC(s).
1. 発見: 彼らがどれによって縛られて、制御されるかでWTPsは西暦を発見します。 発見手順は静電気か動的設定のどちらかを使うことができます。 後者の場合では、プロトコルはWTPが候補西暦を発見する命令で使用されます。
2. Authentication: After discovery, the WTP device authenticates
itself with the AC. However, mutual authentication, in which the
WTP also authenticates the AC, is not always supported since some
vendors strive for zero-configuration on the WTP side. This is
not necessarily secure as it leaves the possible vulnerability of
the WTP being attached to a rogue AC.
2. 認証: 発見の後に、WTPデバイスは西暦でそれ自体を認証します。 しかしながら、いくつかのベンダーがWTP側での無構成を求めて努力するので、互いの認証(また、WTPは西暦を認証する)はいつもサポートされるというわけではありません。 WTPの可能な脆弱性が凶暴な西暦に付けられているままにするとき、これは必ず安全であるというわけではありません。
3. WTP Association: After successful authentication, a WTP registers
with the AC in order to start receiving management and
configuration messages.
3. WTP協会: うまくいっている認証の後に、WTPは、管理と構成メッセージを受け取り始めるために西暦とともに記名します。
4. Firmware Download: After successful association, the WTP may
pull, or the AC may push, the WTPs firmware, which may be
protected in some manner, such as digital signatures.
4. ファームウェアダウンロード: うまくいっている協会、WTPが引くかもしれないか、または西暦が押されたかもしれない後にデジタル化した署名などの何らかの方法で保護されるかもしれないWTPsファームウェアです。
5. Control Channel Establishment: The WTP establishes either an IP-
tunnel or performs Ethernet encapsulation with the AC in order to
transfer data traffic and management frames.
5. チャンネル設立を制御してください: WTPは、IPトンネルを確立するか、またはデータ通信量と管理フレームを移すために西暦でイーサネットカプセル化を実行します。
6. Configuration Download: Following the control channel
establishment process, the AC may push configuration parameters
to the WTPs.
6. 構成ダウンロード: コントロールチャンネル設立プロセスに続いて、西暦は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.
Centralized Architectureのための機能性の様々な分配を考えて、付加的なネットワーク結合がWTPと西暦の間で作成されるのは、セクション4.3で調査されるように明白です。 これは新しくてユニークな安全保障問題とその後の要件をもたらします。
Yang, et al. Informational [Page 29] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [29ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
調査は、WTPか西暦で「空気」802.11暗号化[4]のための終了ポイントを実装することができるのを明確に示します。 その上、802.1X/EAP[6]機能性は多くの場合、西暦が802.1X交換における固有識別文字として必要な機能を実行するWTPと西暦の間に分配されます。
If the STA and AC are the parties in the 4-way handshake (defined in [4]), and 802.11i traffic encryption terminates at the WTP, then the Pairwise Transient Key (PTK) has to be transferred from the AC to the WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material.
パーティーはSTAと西暦であるなら4ウェイ握手中です。(トラフィック暗号化がWTPで終える[4])、および802.11iで定義されています、次に、西暦からWTPまでPairwise Transient Key(PTK)を移さなければなりません。 合わせることの材料がコントロールの一部とWTPsの食糧を供給することであるので、制御フレームへの安全な暗号化されたトンネルは合わせることの材料を輸送するのに使われます。
The centralized model encourages AC implementations to use one PMK for many different WTPs. This practice facilitates speedy transition by an STA from one WTP to another that is connected to the same AC without establishing a separate PMK. However, this leaves the STA in a difficult position, as the STA cannot distinguish between a compromised PMK and one that is intentionally being shared. This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for this resolution is to be determined by the IEEE 802 and IETF liaisons.
集結されたモデルは、交流実装が多くの異なったWTPsに1PMKを使用するよう奨励します。 この習慣は1WTPからWTPまで別々のPMKを設立しないで同じ西暦に接続される別STAによる迅速な変遷を容易にします。 しかしながら、これは難しい立場にSTAを残します、STAが感染しているPMKと故意に共有されているものを見分けることができないとき。 この問題を解決しなければなりませんが、解決はCAPWAPワーキンググループの範囲を超えています。 この解決のための開催地はIEEE802と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.
802.11i暗号化/復号化が西暦で実行されるとき、主要な交換と状態遷移は西暦、STAの間に起こります。 したがって、どんな暗号の材料も西暦、WTPの間に移す必要は全くありません。
Regardless of where the 802.11i termination point occurs, the Centralized WLAN Architecture records two practices for "over the wire" client data security. In some cases there is an encrypted tunnel (IPsec or SSL) between the WTP and AC, which assumes that the security boundary is in the AC. In other cases, an end-to-end mutually authenticated secure VPN tunnel is assumed between the client and AC, other security gateway, or end host entity.
にかかわらず、802.11i終了ポイントが起こるところでは、Centralized WLAN Architectureは「ワイヤ」クライアントデータ機密保護のために2つの習慣を記録します。 いくつかの場合、WTPと西暦の間には、暗号化されたトンネル(IPsecかSSL)があります。西暦はセキュリティ境界が西暦にあると仮定します。 他の場合では、互いに安全な状態で認証された終わりから端へのVPNトンネルはクライアントと西暦か、他のセキュリティゲートウェイか、終わりのホスト実体の間で想定されます。
5.8.2. Security of Control Channel between the WTP and AC
5.8.2. WTPと西暦の間の制御チャンネルのセキュリティ
In order for the CAPWAP functions to be implemented in the Centralized WLAN Architecture, a control channel is necessary between the WTP and AC.
Centralized WLAN Architectureで実装されるCAPWAP機能において整然とします、制御チャンネルがWTPと西暦の間で必要です。
Yang, et al. Informational [Page 30] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [30ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
To address potential security threats against the control channel, existing implementations feature one or more of the following security mechanisms:
制御チャンネルに対して潜在的セキュリティが脅威であると扱うために、既存の実装は以下のセキュリティー対策の1つ以上を特集します:
1. Secure discovery of WTP and AC.
1. WTPと西暦の発見を保証してください。
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.
3. コントロールの秘密性、保全、および反復操作による保護はフレームにチャネルを開設します。
4. Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets and state.
4. しっかりと秘密と状態を設定して、リセットするためのメカニズムを含むWTPsとACsの管理を保証してください。
Discovery and authentication of WTPs are addressed in the submissions by implementing authentication mechanisms that range from X.509 certificates, AAA authentication to pre-shared credential authentication. In all cases, confidentiality, integrity, and protection against man-in-the-middle attacks of the control frames are addressed by a secure encrypted tunnel between the WTP and AC(s), utilizing keys derived from the authentication methods mentioned previously. Finally, one of the motivations for the Centralized WLAN Architecture is to minimize the storage of cryptographic and security sensitive information, in addition to operational configuration parameters within the WTPs. It is for that reason that the majority of the submissions under the Centralized Architecture category have employed a post WTP authenticated discovery phase of configuration provisioning, which in turn protects against the theft of WTPs.
X.509証明書(あらかじめ共有された資格証明認証へのAAA認証)から認証機構がその範囲であると実装することによって、WTPsの発見と認証は差出で扱われます。 全部で、制御フレームの介入者攻撃に対するケース、秘密性、保全、および保護はWTPと西暦の間の安全な暗号化されたトンネルによって扱われます、以前に言及された認証方法から得られたキーを利用して。 最終的に、Centralized WLAN Architectureに関する動機の1つは暗号とセキュリティ機密情報のストレージを最小にすることです、WTPsの中の操作上の設定パラメータに加えて。 それはCentralized Architectureカテゴリの下における差出の大部分がポストWTPを使ったその理由が順番に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.
包括的なラジオ適用範囲を提供するために、WTPsはしばしば物理的に機密保護するのが難しい位置にインストールされます。 物理的に西暦を機密保護するのは比較的簡単です。 RADIUS共有秘密キーなどの高値の秘密がWTPsの代わりに西暦に保存されるなら、WTPの物理的な損失はこれらの秘密に感染しません。 したがって、Centralized Architectureは盗まれたWTPのセキュリティ結果を減少させるかもしれません。 他方では、1つの場所ですべての高値の秘密を集結すると、西暦は秘密を保護するために厳しい物理的で、手続き上的、そして、技術的なコントロールを必要とする魅力的な目標にします。
Yang, et al. Informational [Page 31] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [31ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
6. Distributed Mesh Architecture
6. 分配されたメッシュアーキテクチャ
Out of the sixteen architecture survey submissions, three belong to the Distributed Mesh Architecture family. An example of the Distributed Mesh Architecture is shown in Figure 13, and reflects some of the common characteristics found in these three submissions.
16アーキテクチャから、差出について調査してください、そして、3はDistributed Mesh Architectureファミリーのものです。 Distributed Mesh Architectureに関する例は、図13に示されて、これらの3つの差出で見つけられた共通する特徴のいくつかを反映します。
+-----------------+ +-----------------+
| 802.11 BSS 1 | | 802.11 BSS 2 |
| ... | | ... |
| +---------+ | | +---------+ |
+----|mesh node|--+ +----|mesh node|--+
+-+---+---+ +-+-+-----+
| | | |
| | | | +----------+
| +-----------------------+ | Ethernet | Ethernet |
| 802.11 wireless links | +--------+ Switch |
| +-----------------------+ | | | |
| | | | | +----------+
+-+---+---+ +-+--+----+
+----|mesh node|--+ +----|mesh node|--+
| +---------+ | | +---------+ |
| ... | | ... |
| 802.11 BSS 4 | | 802.11 BSS 3 |
+-----------------+ +-----------------+
+-----------------+ +-----------------+ | 802.11 BSS1| | 802.11 BSS2| | ... | | ... | | +---------+ | | +---------+ | +----|メッシュノード|--+ +----|メッシュノード|--+ +-+---+---+ +-+-+-----+ | | | | | | | | +----------+ | +-----------------------+ | イーサネット| イーサネット| | 802.11 ワイヤレスのリンク| +--------+ スイッチ| | +-----------------------+ | | | | | | | | | +----------+ +-+---+---+ +-+--+----+ +----|メッシュノード|--+ +----|メッシュノード|--+ | +---------+ | | +---------+ | | ... | | ... | | 802.11 BSS4| | 802.11 BSS3| +-----------------+ +-----------------+
Figure 13: Example of Distributed Mesh Architecture
図13: 分配されたメッシュアーキテクチャに関する例
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.
より広いワイヤレスの適用範囲を提供するために、ネットワークにおけるメッシュノードはAPsとしてそれらのそれぞれのBSSでクライアントステーションに機能するかもしれません、隣接しているメッシュノードへの802.11個のワイヤレスのリンクを通したトラフィックリレーと同様に。 また、ネットワークにおけるいくつかのメッシュノードがどんなクライアントステーションにも単にワイヤレスのトラフィックが他のメッシュのためにノードをリレーするように役立ちますが、APsとして役立つというわけではないのも可能です。 あらゆるAPにイーサネットケーブル接続を引くことの代わりに、ワイヤレスの網目状ネットワークは逆送トラフィックをリレーすることへの魅力的な代替手段を提供します。
Mesh nodes can also keep track of the state of their neighboring nodes, or even nodes beyond their immediate neighborhood by exchanging information periodically amongst them; this way, mesh nodes can be fully aware of the dynamic network topology and RF conditions around them. Such peer-to-peer communication model allows mesh nodes to actively coordinate among themselves to achieve self- configuration and self-healing. This is the major distinction between this Distributed Architecture family and the Centralized Architecture -- much of the CAPWAP functions can be implemented
また、メッシュノードはそれらの即座の地域を超えてそれらの中で定期的に情報交換することによって、彼らの隣接しているノード、またはノードさえの事情の動向をおさえることができます。 このように、メッシュノードはそれらの周りでダイナミックなネットワーク形態とRF状態を百も承知している場合があります。 そのようなピアツーピアコミュニケーションモデルは、自己構成と自己回復を達成するために自分たちの中でメッシュノードを活発に調整させます。 これはこのDistributed ArchitectureファミリーとCentralized Architectureの主要な区別です--CAPWAP機能の多くを実装することができます。
Yang, et al. Informational [Page 32] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [32ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
across the mesh nodes in a distributed fashion, without a centralized entity making all the control decisions.
集結された実体がすべてのコントロール決定をすることのない分配されたファッションによるメッシュノードの向こう側に。
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.
網目状ネットワークが必ず集中制御の使用を排除するというわけではないと指摘する価値があります。 集結されることの組み合わせと分散制御が網目状ネットワークで共存するのは、可能です。 何らかのフォームのAccess Controller(西暦)が網目状ネットワークで存在しているなら連携ファッションでいくらかのグローバルな構成か政策変更が役立たれるほうがよい、(Centralized WLAN Architectureで定義されるような西暦の花盛りのバージョンでない 例えば、あらゆるメッシュノードのデフォルト設定をアップデートするのに集中的管理実体を使用できます。 また、ある機能を残すのも、より望ましいかもしれません、ただ一つの集結されたエンドポイント(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個の標準のワイヤレスのリンクの上の独占メッシュ技術を使用しています。 したがって、異なったベンダーからのメッシュノードの中に相互運用性が全くありません。 IEEE802.11WGは、最近、802.11のメッシュ規格を定義するために、新しいTask Group(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.
また、クライアントデータセキュリティのためのセクション5.8.1で説明される同様の安全上の配慮はDistributed Mesh Architectureに適用されます。 さらに、1つの網目状ネットワークに、重要な警備上の配慮はメッシュノードが同じ管理ドメインの中で互いを認証しなければならないということです。 層3で保証されないかもしれないユーザと管理データを保護するために、秘密性、保全、および反復操作による保護の層の2メカニズムは隣接しているノードの中のデータ伝送を保証するべきです。
7. Summary and Conclusions
7. 概要と結論
We requested existing WLAN vendors and other interested parties to submit a short description of existing or desired WLAN access network architectures to define a taxonomy of possible WLAN access network architectures. The information from the 16 submissions was condensed and summarized in this document.
私たちは、存在する短い記述を提出するよう既存のWLANベンダーと他の利害関係者に要求したか、またはWLANアクセスネットワークアーキテクチャが可能なWLANアクセスネットワークアーキテクチャの分類学を定義することを望んでいました。 16差出からの情報は、本書では凝縮して、まとめられました。
New terminology has been defined wherever existing terminology was found to be either insufficient or ambiguous in describing the WLAN architectures and supporting functions listed in the document. For
既存の用語がどこでWLANアーキテクチャについて説明して、ドキュメントに記載された機能をサポートするのにおいて不十分であるか、またはあいまいであることがわかったとしても、新しい用語は定義されました。 for
Yang, et al. Informational [Page 33] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [33ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
例、広いセットのAccess Point機能は2つのカテゴリに分割されました: 802.11の機能。(その機能はIEEEが必要であることで、そうするものを含んでいる802.11の規格、およびCAPWAP機能はIEEE802.11は必要でないということですが、802.11のWLANアクセスネットワークのコントロール、構成、および経営に不可欠であると考えられるものを含んでいます)。 かなりのあいまいさを引き起こした別の用語は通常アンテナを持っている物理的な箱を反映しましたが、差出の向こう側に一定の外部的に一貫した動きを持っていなかった「アクセスポイント」です。 802.11とCAPWAPのセットが機能するとき、このあいまいさを取り除くために、私たちはAPを再定義しました、802.11PHYを終える物理的な箱はWireless Termination Pointと呼ばれますが。
Based on the submissions during the architecture survey phase, we have classified the existing WLAN architectures into three broad classes:
アーキテクチャ調査段階の間の差出に基づいて、私たちは既存のWLANアーキテクチャを3つの広いクラスに分類しました:
1. Autonomous WLAN Architecture: Indicates a family of architectures
in which all the 802.11 functions and, where applicable, CAPWAP
functions are implemented in the WTPs.
1. 自治のWLANアーキテクチャ: すべての802.11に、機能と適切であるところでのCAPWAP機能がWTPsで実装されるアーキテクチャのファミリーを示します。
2. Centralized WLAN Architecture: Indicates a family of architectures
in which the AP functions are split between the WTPs and the AC,
with the AC acting as a centralized control point for multiple
WTPs.
2. 集結されたWLANアーキテクチャ: 西暦が複数のWTPsのための集中制御ポイントとして機能する状態で、AP機能が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.
3. 分配されたWLANアーキテクチャ: コントロール機能の一部が同輩実体の分配されたネットワークの向こう側に実装されるアーキテクチャのファミリーを示します。
Within the Centralized WLAN Architecture, there are a few visible sub-categories that depend on how one maps the MAC functions (at a high-level), between the WTP and the AC. Three prominent sub- categories emerged from the information in the submissions:
Centralized WLAN Architectureの中に、1つがどう、MAC機能(aでハイレベルの)を写像するかによるいくつかの目に見えるサブカテゴリがあります、WTPと西暦の間で。 3つの際立ったサブカテゴリが差出における情報から出て来ました:
1. Split MAC Architecture: The 802.11 MAC functions are split between
the WTP and the AC. This subgroup includes all architectures that
split the 802.11 MAC functions even though individual submissions
differed on the specifics of the split.
1. MACアーキテクチャを分けてください: 802.11のMAC機能がWTPと西暦の間で分けられます。 このサブグループは個々の差出が分裂の詳細について異なる意見をもちましたが、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機能の全体のセットは西暦で実装されます。
Yang, et al. Informational [Page 34] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [34ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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 |
+----------------+
+----------------+ |自治| +---------->|アーキテクチャ| | |ファミリー| | +----------------+ | +--------------+ | |ローカル| | +---->|Mac| | | |アーキテクチャ| | | +--------------+ | | | +----------------+ | +--------------+ | |集結されます。| | |分けられます。| +---------->|アーキテクチャ|--+---->|Mac| | |ファミリー| | |アーキテクチャ| | +----------------+ | +--------------+ | | | | +--------------+ | | |リモート| | +---->|Mac| | |アーキテクチャ| | +--------------+ | +----------------+ | |分配されたメッシュ| +---------->|アーキテクチャ| |ファミリー| +----------------+
A majority of the submitted WLAN access network architectures (twelve out of sixteen) followed the Centralized WLAN Architecture. All but one of the Centralized WLAN Architecture submissions were grouped into either a Split MAC Architecture or a Local MAC Architecture. One submission followed the Autonomous WLAN Architecture, and three followed the Distributed WLAN Architecture.
提出されたWLANアクセスネットワークアーキテクチャ(16のうちの12)の大部分がCentralized WLAN Architectureに続きました。 Centralized WLAN Architecture差出の1つ以外のすべてがSplit MAC ArchitectureかLocal MAC Architectureのどちらかに分類されました。 1つの服従がAutonomous WLAN Architectureに続きました、そして、3はDistributed WLAN Architectureに続きました。
The WLAN access network architectures in the submissions indicated that the connectivity assumptions were:
差出におけるWLANアクセスネットワークアーキテクチャは、接続性仮定は以下の通りであることを示しました。
o Direct connection between the WTP and the AC.
o WTPと西暦との接続を指示してください。
o L2 switched connection between the WTP and the AC.
o L2はWTPと西暦の間に接続を切り換えました。
o L3 routed connection between the WTP and the AC.
o L3はWTPと西暦の間に接続を発送しました。
Yang, et al. Informational [Page 35] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [35ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
o Wireless connection between the mesh nodes in the distributed mesh
architecture.
o 分配されたメッシュアーキテクチャのメッシュノードの間の無線接続。
Interoperability between equipment from different vendors is one of the fundamental problems in the WLAN market today. To achieve interoperability via open standard development, the following steps are suggested for IETF and IEEE 802.11.
異なったベンダーからの設備の間の相互運用性は今日のWLAN市場の基本的な問題の1つです。 オープンスタンダード開発で相互運用性を達成するために、以下のステップはIETFとIEEE802.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.
この分類学を使用して、Access Pointの機能論的モデルは最近IEEE802.11の中で形成された新しい研究グループによって定義されるべきです。 機能論的モデルは複数のネットワーク要素の向こう側に分かれながら原子であって、すなわち、促進するためになることがないと考えられる802.11Access Pointの機能要素を定義するのから成るでしょう。 そのような機能論的モデルは存在がこの分類学で概説されているWLANアーキテクチャと、グループかIEEE802.11グループの外であらゆるさらなるアーキテクチャ開発であるとサポートする一般的な基礎として役立つべきです。 それが可能であって、お勧めでさえある、また、機能論的モデル定義に対するその仕事はWTPか西暦のどちらかにおける各機能要素を実装するインパクト解析を含むかもしれません。
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.
機能論的モデル定義の一部として、これらの機能要素の間の基関数とインタフェースを定義しなければなりません。 それらの間でインタフェースを定義する1組の機能要素が2つの異なったネットワーク実体で実装されているなら、1組のそのようなネットワーク要素の間のプロトコル仕様定義は、必要であり、IETFによって開発されるはずです。
8. Security Considerations
8. セキュリティ問題
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.
概要では、Autonomous Architectureの主なセキュリティ関心はWTPとワイヤードな(イーサネット)インフラストラクチャ設備の間の互いの認証です。 また、WTPsが秘密の情報を含んでいるので、WTPsの物理的なセキュリティはネットワークセキュリティ関心です、そして、これらのデバイスの窃盗は潜在的に有線ネットワークにさえ感染するかもしれません。
Yang, et al. Informational [Page 36] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [36ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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.
Centralized Architectureに、新しいネットワークによるいくつかの新しいWTPと西暦の間で拘束力がある安全上の配慮があります。 以下の安全上の配慮はこのアーキテクチャファミリーのために上げられます: モバイルクライアントトラフィックのために材料を合わせるのは、西暦からWTPまでしっかりと輸送される必要があるかもしれません。 WTPと西暦の安全な発見がWTPsと西暦の間の互いの認証と同様に必要です。 中央のコントロールに対する攻撃が埋め込まれた秘密の抽出のために中でコントロールチャンネルフレーム、およびWTPsの窃盗のWTPと、西暦、秘密性と、保全と反復操作による保護の間でチャネルを開設する男性。 この広いアーキテクチャカテゴリのためのそれぞれの調査結果は、これらの安全保障問題を扱うためにメカニズムを提示しました。
The new security issue in the Distributed Mesh Architecture is the need for mesh nodes to authenticate each other before forming a secure mesh network. Encrypted communication between mesh nodes is recommended to protect both control and user data.
Distributed Mesh Architectureの新しい安全保障問題は安全な網目状ネットワークを形成する前にメッシュノードが互いを認証する必要性です。 メッシュノードの暗号化通信がコントロールと利用者データの両方を保護することが勧められます。
9. Acknowledgements
9. 承認
This taxonomy is truly a collaborative effort with contributions from a large group of people. First, we want to thank all the CAPWAP Architecture Design Team members who have spent many hours in the teleconference calls, over e-mails, and in writing and reviewing the document. The full Design Team is listed here:
本当に、人々の大きいグループからの貢献でこの分類学は共同努力です。 まず最初に、だれが何時間も電子会議で過ごしたかがメールの上と、そして、ドキュメントを書いて、再検討することで呼ぶのをすべてのCAPWAP Architecture Design Teamメンバーに感謝申し上げます。 完全なDesign Teamはここに記載されています:
o Peyush Agarwal
STMicroelectronics
Plot# 18, Sector 16A
Noida, U.P 201301
India
Phone: +91-120-2512021
EMail: peyush.agarwal@st.com
o Peyush Agarwal STMicroelectronics陰謀#18、セクター16A Noida、U.P201301インドは以下に電話をします。 +91-120-2512021はメールされます: peyush.agarwal@st.com
o Dave Hetherington
Roving Planet
4750 Walnut St., Suite 106
Boulder, CO 80027
United States
Phone: +1-303-996-7560
EMail: Dave.Hetherington@RovingPlanet.com
o 惑星4750Walnut通りを流浪させるデーヴ・ヘザーリントン、スイート106ボウルダー、合衆国が電話をする共同80027: +1-303-996-7560 メールしてください: Dave.Hetherington@RovingPlanet.com
o Matt Holdrege
Strix Systems
26610 Agoura Road
Calabasas, CA 91302
Phone: +1 818-251-1058
EMail: matt@strixsystems.com
o カラバサス、カリフォルニア 91302が電話をするマットHoldrege Strix Systems26610Agoura道路: +1 818-251-1058 メールしてください: matt@strixsystems.com
Yang, et al. Informational [Page 37] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [37ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
o Victor Lin
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
Phone: +1 408-579-3383
EMail: vlin@extremenetworks.com
o ビクタリンExtremeはサンタクララ、カリフォルニア 95051が電話をする3585モンロー通りをネットワークでつなぎます: +1 408-579-3383 メールしてください: vlin@extremenetworks.com
o James M. Murphy
Trapeze Networks
5753 W. Las Positas Blvd.
Pleasanton, CA 94588
Phone: +1 925-474-2233
EMail: jmurphy@trapezenetworks.com
o ジェームスM.マーフィーぶらんこは5753w.Las Positas Blvd.をネットワークでつなぎます。 プレザントン、カリフォルニア 94588は以下に電話をします。 +1 925-474-2233 メールしてください: jmurphy@trapezenetworks.com
o Partha Narasimhan
Aruba Wireless Networks
180 Great Oaks Blvd
San Jose, CA 95119
Phone: +1 408-754-3018
EMail: partha@arubanetworks.com
o Blvdサンノゼ、Parthaナラシマンアルーバワイヤレス・ネットワーク180のすばらしいOaksカリフォルニア 95119は以下に電話をします。 +1 408-754-3018 メールしてください: partha@arubanetworks.com
o Bob O'Hara
Airespace
110 Nortech Parkway
San Jose, CA 95134
Phone: +1 408-635-2025
EMail: bob@airespace.com
o サンノゼ、カリフォルニア 95134が電話をするボブオハラAirespace110Nortech公園道路: +1 408-635-2025 メールしてください: bob@airespace.com
o Emek Sadot (see Authors' Addresses)
o Emek Sadot(作者のアドレスを見ます)
o Ajit Sanzgiri
Cisco Systems
170 W Tasman Drive
San Jose, CA 95134
Phone: +1 408-527-4252
EMail: sanzgiri@cisco.com
o サンノゼ、カリフォルニア 95134が電話をするAjit Sanzgiriシスコシステムズの170Wタスマンのドライブ: +1 408-527-4252 メールしてください: sanzgiri@cisco.com
o Singh
Chantry Networks
1900 Minnesota Court
Mississauga, Ontario L5N 3C9
Canada
Phone: +1 905-567-6900
EMail: isingh@chantrynetworks.com
o ミネソタ法廷オンタリオL5N 3C9ミシソーガ(カナダ)が電話をするシン寄進ネットワーク1900: +1 905-567-6900 メールしてください: isingh@chantrynetworks.com
o L. Lily Yang (Editor, see Authors' Addresses)
o L。 ユリ陽(エディタはAuthorsのAddressesを見てください)
o Petros Zerfos (see Authors' Addresses)
o ペトロスZerfos(作者のアドレスを見ます)
Yang, et al. Informational [Page 38] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [38ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
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、チェンHong、Saravanan Govindan、ボブビーチ、デニスVolpano、シャンカルNarayanaswamy、サイモン・バーバー、SrinivasaラオAddepalli、Subhashini A.Venkataramanan、Kueウォン、ケビン・ディック、テッド・クウ、およびTyan-shu Jou。 私たちに提供したと大きい代表しているデータポイントのないこの分類学に書くのは単に不可能です。 また、彼らのいつも変わらない支持について私たちのCAPWAP WG共同議長(Mahalingamマニとドロシー・ゲラート)と私たちのAreaディレクター(バートWijnen)に感謝申し上げます。
10. Normative References
10. 引用規格
[1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE
802.11-99>.
[1] 「IEEE WLAN MACとPHYは仕様を層にする」1999年8月、<IEEE802.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)問題声明にアクセスします」、RFC3990、2005年2月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] "IEEE Std 802.11i: Medium Access Control (MAC) Security
Enhancements", April 2004.
[4]、「IEEE Std 802.11i:」 2004年4月の「媒体アクセス制御(MAC)セキュリティ増進。」
[5] "IEEE Std 802.11h: Spectrum and Transmit Power Management
Extensions in the 5 GHz Band in Europe", October 2003.
[5]、「IEEE Std 802.11h:」 「スペクトル、ヨーロッパの5ギガヘルツバンドでパワーマネージメント拡大を伝えてください、」、10月2003日
[6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.
[6]、「IEEE Std 802.1X:」 2001年6月の「ポートベースのネットワークアクセスコントロール。」
Yang, et al. Informational [Page 39] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [39ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Authors' Addresses
作者のアドレス
L. Lily Yang Intel Corp. MS JF3 206, 2111 NE 25th Avenue Hillsboro, OR 97124
第25L.ユリ陽のインテル社MS JF3 206、2111Ne Avenueヒースボロー、または97124
Phone: +1 503-264-8813 EMail: lily.l.yang@intel.com
以下に電話をしてください。 +1 503-264-8813 メールしてください: lily.l.yang@intel.com
Petros Zerfos UCLA - Computer Science Department 4403 Boelter Hall Los Angeles, CA 90095
ペトロスZerfos UCLA--コンピュータ理学部4403Boelter Hallロサンゼルス、カリフォルニア 90095
Phone: +1 310-206-3091 EMail: pzerfos@cs.ucla.edu
以下に電話をしてください。 +1 310-206-3091 メールしてください: pzerfos@cs.ucla.edu
Emek Sadot Avaya Atidim Technology Park, Building #3 Tel-Aviv 61131 Israel
Emek Sadot Avaya Atidim技術公園、ビル#3テルアビブ61131イスラエル
Phone: +972-3-645-7591 EMail: esadot@avaya.com
以下に電話をしてください。 +972-3-645-7591 メールしてください: esadot@avaya.com
Yang, et al. Informational [Page 40] RFC 4118 CAPWAP Architecture Taxonomy June 2005
陽、他 [40ページ]情報のRFC4118CAPWAPアーキテクチャ分類学2005年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Yang, et al. Informational [Page 41]
陽、他 情報[41ページ]
一覧
スポンサーリンク
