Network Working Group S. Govindan, Ed.
Request for Comments: 4564 H. Cheng
Category: Informational Panasonic
ZH. Yao
Huawei
WH. Zhou
China Mobile
L. Yang
Intel
July 2006
Objectives for
Control and Provisioning of Wireless Access Points (CAPWAP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs.
この文書では、ワイヤレスアクセスポイント（CAPWAP）の管理とプロビジョニングのための相互運用可能なプロトコルのための目標を提示しています。文書は、CAPWAPプロトコルの開発と評価のための焦点を当てた一連の要件を確立することを目指しています。目的は、ワイヤレスローカルエリアネットワーク（WLAN）の代替設計のデバイス間の相互運用性を実現するために必要なアーキテクチャ、操作、セキュリティ、およびネットワーク事業者の要件に対応しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements Notation ...........................................4
4. Objectives Overview .............................................4
5. Objectives ......................................................5
5.1. Mandatory and Accepted Objectives ..........................5
5.1.1. Logical Groups ......................................5
5.1.2. Support for Traffic Separation ......................6
5.1.3. Wireless Terminal Transparency ......................8
5.1.4. Configuration Consistency ...........................8
5.1.5. Firmware Trigger ....................................9
5.1.6. Monitoring and Exchange of System-wide
Resource State .....................................10
5.1.7. Resource Control Objective .........................11
5.1.8. CAPWAP Protocol Security ...........................12
5.1.9. System-wide Security ...............................14
5.1.10. IEEE 802.11i Considerations .......................15
5.1.11. Interoperability Objective .......................17
5.1.12. Protocol Specifications ..........................18
5.1.13. Vendor Independence ..............................19
5.1.14. Vendor Flexibility ...............................19
5.1.15. NAT Traversal ....................................20
5.2. Desirable Objectives ......................................21
5.2.1. Multiple Authentication Mechanisms .................21
5.2.2. Support for Future Wireless Technologies ...........21
5.2.3. Support for New IEEE Requirements ..................22
5.2.4. Interconnection Objective ..........................23
5.2.5. Access Control ....................................24
5.3. Non-Objectives ............................................25
5.3.1. Support for Non-CAPWAP WTPs ........................25
5.3.2. Technical Specifications ...........................26
5.4. Operator Requirements .....................................27
5.4.1. AP Fast Handoff ....................................27
6. Summary and Conclusion .........................................27
7. Security Considerations ........................................28
8. Acknowledgements ...............................................29
9. Normative References ...........................................29
10. Informative References ........................................29
The growth in large-scale Wireless Local Area Network (WLAN) deployments has brought into focus a number of technical challenges. Among them is the complexity of managing large numbers of Wireless Termination Points (WTPs), which is further exacerbated by variations in their design. Another challenge is the maintenance of consistent configurations among the numerous WTPs of a system. The dynamic nature of the wireless medium is also a concern together with WLAN security. The challenges affecting large-scale WLAN deployments have been highlighted in [RFC3990].
大規模なワイヤレスローカルエリアネットワーク（WLAN）展開で成長が焦点に多くの技術的課題をもたらしています。その中でも、さらにその設計の変動によって悪化するワイヤレスターミネーションポイント（WTPs）、多数の管理の複雑さです。もう一つの課題は、システムの多数のWTPsの間で一貫性のある構成の維持です。無線媒体の動的な性質はまた、WLANのセキュリティと一緒に懸念されます。大規模なWLANの展開に影響を与える課題は[RFC3990]で強調表示されています。
Many vendors have addressed these challenges by developing new architectures and solutions. A survey of the various developments was conducted to better understand the context of these challenges. This survey is a first step towards designing interoperability among the solutions. The Architecture Taxonomy [RFC4118] is a result of this survey in which major WLAN architecture families are classified. Broadly, these are the autonomous, centralized WLAN, and distributed mesh architectures.
多くのベンダーは、新しいアーキテクチャおよびソリューションを開発することによって、これらの課題に対処しています。様々な開発の調査はより良いこれらの課題の背景を理解するために実施しました。この調査では、ソリューション間の相互運用性を設計に向けた最初のステップです。アーキテクチャの分類[RFC4118]は、主要なWLANアーキテクチャの家族が分類されている。この調査の結果です。大まかに言えば、これらは自律的、集中型のWLAN、および分散型メッシュ・アーキテクチャです。
The Architecture Taxonomy identified the centralized WLAN architecture as one in which portions of the wireless medium access control (MAC) operations are centralized in a WLAN controller. This centralized WLAN architecture is further classified into remote-MAC, split-MAC, and local-MAC designs. Each differs in the degree of separation of wireless MAC layer capabilities between WTPs and WLAN controller.
アーキテクチャ分類操作はWLANコントローラに集中している無線媒体アクセス制御（MAC）の部分たとして集中型WLANアーキテクチャを同定しました。この中央集中型WLANアーキテクチャは、さらに、リモートMAC、スプリット-MAC、およびローカル-MACのデザインに分類されます。それぞれがWTPsとWLANコントローラ間の無線MAC層機能の分離の程度が異なります。
This document puts forward critical objectives for achieving interoperability in the CAPWAP framework. It presents requirements that address the challenges of controlling and provisioning large-scale WLAN deployments. The realization of these objectives in a CAPWAP protocol will ensure that WLAN equipment of major design types may be integrally deployed and managed.
この文書では、CAPWAPの枠組みの中での相互運用性を実現するために、前方の重要な目標を置きます。これは、大規模なWLANの展開を制御およびプロビジョニングの課題に対応する要件を提示します。 CAPWAPプロトコルにおけるこれらの目的の実現は、主要な設計タイプの無線LAN機器を一体的に展開し、管理することができることを保証します。
This document uses terminology defined in [RFC4118], [802.11], [802.11i], and [802.11e]. Additionally, the following terms are defined.
このドキュメントは[RFC4118]で定義される用語、[802.11]、[802.11iの]、および[の802.11e]を使用します。また、以下の用語が定義されています。
Centralized WLAN: A WLAN based on the centralized WLAN Architecture [RFC4118].
中央集中型WLAN：中央集中型WLANアーキテクチャ[RFC4118]に基づくWLAN。
Switching Segment: Those aspects of a centralized WLAN that primarily deal with switching or routing of control and data information between Wireless Termination Points (WTPs) and the WLAN controller.
スイッチングセグメント：主スイッチングまたは無線ターミネーションポイント（WTPs）とWLANコントローラ間の制御及びデータ情報のルーティングを扱う集中型WLANのそれらの局面。
Wireless Medium Segment: Those aspects of a centralized WLAN that primarily deal with the wireless interface between WTPs and wireless terminals. The Wireless Medium Segment is specific to layer 2 wireless technology, such as IEEE 802.11.
無線媒体セグメント：主WTPsと無線端末間の無線インタフェースを扱う集中型WLANのそれらの局面。無線媒体セグメントは、レイヤ2無線技術、IEEE802.11などに特異的です。
CAPWAP Framework: A term that covers the local-MAC and split-MAC designs of the Centralized WLAN Architecture. Standardization efforts are focused on these designs.
CAPWAPフレームワーク：ローカル-MACおよび中央集中型WLANアーキテクチャのスプリットMACのデザインをカバー用語。標準化への取り組みは、これらの設計に焦点を当てています。
CAPWAP Protocol: The protocol between WLAN controller and WTPs in the CAPWAP framework. It facilitates control, management, and provisioning of WTPs in an interoperable manner.
CAPWAPプロトコル：CAPWAPフレームワークにおけるWLANコントローラとWTPs間のプロトコル。なお、制御、管理、相互運用可能な方法でWTPsのプロビジョニングを容易にします。
Logical Group: A logical separation of a physical WTP is termed logical group. So a single physical WTP will operate a number of logical groups. Virtual access points (APs) are examples of logical groups. Here, each Basic Service Set Identifier (BSSID) and constituent wireless terminals' radios are denoted as distinct logical groups of a physical WTP. Logical groups are maintained without conflicting with the CAPWAP objectives, particularly the 'Wireless Terminal Transparency' objective.
論理グループ：物理的WTPの論理的な分離は、論理的なグループと呼ばれています。だから、単一の物理WTPは、論理グループの数を動作します。仮想アクセスポイント（AP）論理グループの例です。ここで、各基本サービスセット識別子（BSSID）と成分無線端末の無線機は、物理WTPの別個の論理グループとして示されています。論理グループはCAPWAP目標、特に「ワイヤレスターミナル透明性」目的と競合することなく維持されています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The objectives for CAPWAP have been broadly classified to address architecture, operation, and security requirements of managing large-scale WLAN deployments.
CAPWAPのための目的は広くアーキテクチャ、操作、および大規模なWLAN展開を管理するセキュリティ要件に対処するために分類されています。
Architecture objectives deal with system-level aspects of the CAPWAP protocol. They address issues of protocol extensibility, diversity in network deployments and architecture designs, and differences in transport technologies.
アーキテクチャの目的は、CAPWAPプロトコルのシステム・レベルの側面を扱います。彼らは、ネットワークの展開とアーキテクチャの設計、およびトランスポート技術の違いで、プロトコル拡張性、多様性の問題に対処します。
Operational objectives address the control and management features of the CAPWAP protocol. They deal with operations relating to WLAN monitoring, resource management, Quality of Service (QoS), and access control.
運用目標はCAPWAPプロトコルの制御および管理機能に対応しています。彼らは、WLANの監視、リソース管理、サービスの品質（QoS）、およびアクセス制御に関する業務を扱います。
Security objectives address potential threats to WLANs and their containment. In the CAPWAP context, security requirements cover the protocol between the WLAN controller and WTPs and also the WLAN system as a whole.
セキュリティの目的は、WLANおよびその封じ込めへの潜在的な脅威に対処します。 CAPWAPコンテキストでは、セキュリティ要件は、WLANコントローラとWTPs、また全体としてのWLANシステムとの間のプロトコルを覆います。
Additionally, a general classification is used for objectives relating to the overall impact of the CAPWAP protocol specifications.
また、一般的な分類は、CAPWAPプロトコル仕様の全体的な影響に関連する目的のために使用されます。
The objectives described in this document have been prioritized based on their immediate significance in the development and evaluation of a control and provisioning protocol for large-scale WLAN deployments. The priorities are:
この文書で説明する目的は、大規模なWLAN展開のための制御およびプロビジョニングプロトコルの開発と評価における彼らの即時意義に基づいて優先順位付けされています。優先順位は以下のとおりです。
i. Mandatory and Accepted Objectives ii. Desirable Objectives iii. Non-Objectives
私。必須と認められた目標II。望ましい目的III。非目標
The priorities have been assigned to individual objectives in accordance with working group discussions.
優先順位は、ワーキンググループの議論に基づいて、個々の目的に割り当てられています。
Furthermore, a distinct category of objectives is provided based on requirements gathered from network service operators. These are specific needs that arise from operators' experiences in deploying and managing large-scale WLANs.
さらに、目的の明確なカテゴリは、ネットワークサービス事業者から集められた要件に基づいて提供されます。これらは、大規模なWLANを展開し、管理する上でのオペレータの経験から発生する特定のニーズです。
a. Operator Requirements
A。オペレータの要件
Objectives prioritized as mandatory and accepted have been deemed crucial for the control and provisioning of WTPs. They directly address the challenges of large-scale WLAN deployments and MUST be realized by a CAPWAP protocol.
必須と優先順位と受け入れ目的WTPsの制御およびプロビジョニングのために重要であるとみなされてきました。彼らは、直接大規模なWLAN展開の課題に対処し、CAPWAPプロトコルによって実現されなければなりません。
Classification: Architecture
分類：建築
Description:
説明：
Large WLAN deployments are complex and expensive. Furthermore, enterprises deploying such networks are under pressure to improve the efficiency of their expenditures.
大規模なWLAN展開は、複雑かつ高価です。さらに、そのようなネットワークを展開する企業は、彼らの支出の効率を向上させるために圧力下にあります。
Shared WLAN deployments, where a single physical WLAN infrastructure supports a number of logical networks, are increasingly used to address these two issues of large-scale WLANs. These are popular as they allow deployment and management costs to be spread across businesses.
単一の物理的なWLANインフラストラクチャは、論理ネットワークの数をサポートして共有WLANの展開は、ますます大規模なWLANのこれらの2つの問題に対処するために使用されています。彼らは導入と管理コストは、企業全体に広がることを可能にするように、これらは人気があります。
In traditional WLANs, each physical WTP represents one complete subset of a larger WLAN system. Shared WLANs differ in that each physical WTP represents a number of logical subsets of possibly a number of larger WLAN systems. Each logical division of a physical WTP is referred to as a logical group (see definition in Section 2). So WLANs are managed in terms of logical groups instead of physical WTPs. Logical groups are based on BSSIDs and other types of virtual APs.
従来のWLANにおいて、各物理WTPは、より大きいWLANシステムの一つの完全なサブセットを表します。共有WLANは、各物理WTPが大きくWLANシステムの可能性の数の論理サブセットの数を表すという点で異なります。物理WTPの各論理分割は、論理グループ（第2節での定義を参照）と呼ばれます。だから、WLANのではなく、物理WTPsの論理グループの観点で管理されています。論理グループは、BSSIDと、仮想APの他のタイプに基づいています。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups.
CAPWAPプロトコルは、BSSIDベースのグループを含む論理グループの点で物理的WTPsを制御および管理することができなければなりません。
For all operating modes, including those in which the WTP performs local bridging and those in which the Access Controller (AC) performs centralized bridging, the protocol MUST provide provisions for configuring logical groups at the WTP.
WTPは、ローカルブリッジングを実行するものと、アクセスコントローラ（AC）が集中ブリッジングを実行するものを含むすべての動作モードについては、プロトコルは、WTPの論理グループを構成するための規定を提供しなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
Commercial realities necessitate that WLANs be manageable in terms of their logical groups. This allows separation of logical services and underlying infrastructure management. A protocol that realizes this need ensures simpler and cost-effective WLANs, which directly address the requirements of network service operators.
商業現実は、WLANはその論理グループの観点で管理可能であること必要とします。これは、論理的なサービスと基盤となるインフラストラクチャの管理を分離することができます。このニーズを実現プロトコルは、直接ネットワークサービス事業者の要件に対処する簡単かつ費用対効果の高いWLANを、保証します。
Relation to Problem Statement:
問題文との関係：
This objective addresses the problem of management complexity in terms of costs. Cost complexity is reduced by sharing WLAN deployments. Consequently, deployment and management cost-efficiencies are realized.
この目的は、コスト面での管理の複雑さの問題に対処します。コスト複雑さは、WLANの展開を共有することによって削減されます。その結果、導入と管理のコスト効率が実現されます。
Classification: Operations
分類：オペレーション
Description:
説明：
The centralized WLAN architecture simplifies complexity associated with large-scale deployments by consolidating portions of wireless MAC functionality at a central WLAN controller and distributing the remaining across WTPs. As a result, WTPs and WLAN controller exchange control and data information between them. This objective states that control and data aspects of the exchanges be mutually separated for further simplicity. This will allow solutions for each type of exchange to be independently optimized.
中央集中型WLANアーキテクチャは、中央WLANコントローラで無線MAC機能の一部を統合し、WTPs横切っ残り分散することによって、大規模な展開に伴う複雑さを単純化します。それらの間の結果として、WTPsとWLANコントローラ交換制御及びデータ情報。制御及び交換のデータ局面この目的の状態が互いにさらに簡単にするために分離します。これは、独立して最適化するための交流の各タイプのためのソリューションをできるようになります。
Furthermore, in the context of shared WLAN deployments, the mutual separation of control and data also addresses security concerns. In particular, given the likelihood of different logical groups, such as those established by different virtual APs, being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups.
さらに、共有WLAN展開の文脈の中で、制御とデータの相互分離は、セキュリティ上の懸念に対処しています。特に、そのような異なる仮想APによって確立されたものと異なる論理グループの可能性を考えると、異なる管理者によって管理され、制御及びデータの分離は、個別の論理グループを含み、固定への第一歩です。
It is also important to ensure that traffic from each logical group is mutually separated to maintain the integrity and independence of the logical groups.
各論理グループからのトラフィックは、論理グループの完全性と独立性を維持するために相互に分離されていることを確実にするためにも重要です。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST define transport control messages such that the transport of control messages is separate from the transport of data messages.
CAPWAPプロトコルは、制御メッセージのトランスポートは、データメッセージのトランスポートとは別であるように、トランスポート制御メッセージを定義しなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The aim of separating data and control aspects of the protocol is to simplify the protocol. It also allows for the flexibility of addressing each type of traffic in the most appropriate manner.
プロトコルのデータと制御の側面を分離する目的は、プロトコルを簡素化することです。また、最も適切な方法でトラフィックの各タイプに対処する柔軟性を実現しています。
Furthermore, this requirement will help remotely located WTPs to handle data traffic in alternative ways without the need for forwarding them across a wide network to the WLAN controller.
さらに、この要件は、WLANコントローラに広いネットワーク上で転送を必要とせずに別の方法でデータトラフィックを処理するために、遠隔地に位置WTPsをするのに役立ちます。
Separation of WTP control and data also aids in the secure realization of shared WLAN deployments.
WTPの制御とデータの分離は、共有WLAN展開の安全な実現に役立ちます。
Relation to Problem Statement:
問題文との関係：
Broadly, this objective relates to the challenge of managing complexity in large-scale WLANs. The requirement for traffic separation simplifies control as this is separated from the task of data transport.
大まかに言えば、この目的は、大規模な無線LANにおける複雑性を管理するという課題に関するものです。これは、データ転送のタスクから分離されるように、トラフィック分離のための要件は、制御を簡素化します。
Classification: Operations
分類：オペレーション
Description:
説明：
The CAPWAP protocol is applicable between a centralized WLAN controller and a number of WTPs; i.e., it affects only the switching segment of the centralized WLAN architecture. Its operations should therefore be independent of the wireless terminal. Wireless terminals should not be required to be aware of the existence of the CAPWAP protocol.
CAPWAPプロトコルは、集中型WLANコントローラとWTPsの数との間に適用可能です。すなわち、それは、集中型WLANアーキテクチャの唯一のスイッチングセグメントに影響を与えます。同社の事業は、したがって、無線端末の独立していなければなりません。無線端末は、CAPWAPプロトコルの存在を意識する必要がないようにしてください。
Protocol Requirement:
プロトコル要件：
Wireless terminals MUST NOT be required to recognize or be aware of the CAPWAP protocol.
無線端末が認識またはCAPWAPプロトコルを意識するために必須ではありません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
IEEE 802.11-based wireless terminals are mature and widely available. It would be beneficial for CAPWAP not to impose new requirements on these wireless terminals. In effect, this requirement ensures that the setup cost of the protocol is reduced as the numerous existing wireless terminals need not be altered.
IEEE 802.11ベースの無線端末は、成熟したと広く利用可能です。 CAPWAPは、これらの無線端末に新たな要件を課すことはないことは有益であろう。実際には、この要件は、多くの既存の無線端末を変更する必要がないようなプロトコルのセットアップコストが低減されることを保証します。
Relation to Problem Statement:
問題文との関係：
The Problem Statement highlights the challenges faced by large WLANs consisting of many WTPs. It does not refer to the operations of wireless terminals and this objective emphasizes the independence.
問題文は、多くのWTPsからなる大型のWLANが直面する課題を強調しています。これは、無線端末の操作を参照していないと、この目的は、独立性を強調しています。
Classification: Operations
分類：オペレーション
Description:
説明：
WLANs in the CAPWAP framework contain numerous WTPs, each of them needing to be configured and managed in a consistent manner. The main concern in ensuring consistency is availability of appropriate information corresponding to WTP configuration states. So configuration consistency can be achieved by providing the centralized WLAN controller with regular updates on the state of WTP operations. The centralized WLAN controller can in turn apply information from the regular updates to ensure consistently among the WTPs.
CAPWAPフレームワーク内のWLANは、それらの各々は一貫した方法で構成および管理する必要が、多数WTPsを含みます。一貫性を確保する上で主な関心事は、WTPの構成状態に応じた適切な情報の利用可能性です。そう構成の整合性は、WTP動作の状態に関する定期的な更新と集中型WLANコントローラを提供することによって達成することができます。中央集中型WLANコントローラは、次にWTPs間で一貫して確実にするために定期的な更新からの情報を適用することができます。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST include support for regular exchanges of state information between WTPs and the WLAN controller. Examples of state information include WTP processing load and memory utilization.
CAPWAPプロトコルはWTPsとWLANコントローラ間の状態情報の定期的な交換のためのサポートを含まなければなりません。状態情報の例は、WTP処理負荷やメモリ使用率を含みます。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
A protocol that provides access to regular state information can in turn be used to enhance WLAN configuration and performance. The CAPWAP protocol will be better equipped to address configuration-related problems with the regularly available state information. So with greater state information, control and management operations can be improved.
通常の状態情報へのアクセスを提供するプロトコルは、順番にWLANの設定とパフォーマンスを向上させるために使用することができます。 CAPWAPプロトコルは、より良い、定期的に利用可能な状態情報を持つ構成に関連する問題に対処するために装備されます。そう大きい状態情報、制御及び管理動作を向上させることができます。
Relation to Problem Statement:
問題文との関係：
One of the major challenges described in the Problem Statement is that of maintaining consistent configuration across the numerous WTPs of a WLAN. This objective addresses the fundamental issue behind this -- availability of timely state information.
問題文に記述の主要な課題の一つは、WLANの数々WTPs一貫した設定を維持することです。タイムリーな状態情報の可用性 - この目的は、この背後にある根本的な問題に対処しています。
Classification: Operations
分類：オペレーション
Description:
説明：
One specific aspect of configuration consistency is the firmware used by various WTPs. The scale of large WLANs introduces possibilities for variations in the firmware used among WTPs. This objective highlights the need for the CAPWAP protocol to trigger the delivery of appropriate versions of firmware to WTPs. The actual delivery of firmware need not be inclusive to the protocol.
コンフィグレーションの一貫性のある特定の局面では、種々のWTPsによって使用されるファームウェアです。大WLANの規模はWTPs間使用されているファームウェアの変化の可能性を導入します。この目的は、WTPsへのファームウェアの適切なバージョンの配信をトリガするCAPWAPプロトコルの必要性を強調しています。ファームウェアの実際の配信は、プロトコルに包括的である必要はありません。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST support a trigger for delivery of firmware updates.
CAPWAPプロトコルは、ファームウェアのアップデートの配信のためのトリガをサポートしなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The CAPWAP protocol interfaces many WTPs to a centralized WLAN controller. Firmware distribution allows these interfaces to be compatible. This in turn results in consistent configuration and simplified management. So the protocol benefits by including triggers for the distribution of firmware updates.
CAPWAPプロトコルインターフェイス集中型WLANコントローラに多くWTPs。ファームウェア配信は、これらのインターフェイスは互換性を可能にします。この一貫性のある設定と管理の簡素化でターン結果インチだから、ファームウェアアップデートの配布のためのトリガーを含めることによって、プロトコルの利点は。
Relation to Problem Statement:
問題文との関係：
Inconsistencies in the configuration of WTPs have been identified as a major challenge for large-scale WTPs. This objective helps overcome the challenge by providing a way for the CAPWAP protocol to initiate delivery of firmware updates that are compatible among all WTPs.
WTPsの構成の不一致は、大規模WTPsのための大きな課題として同定されています。この目的は、すべてのWTPsの間で互換性のあるファームウェアのアップデートの配信を開始するためのCAPWAPプロトコルのための方法を提供することで、課題を克服するのに役立ちます。
Classification: Operations
分類：オペレーション
Description:
説明：
The centralized WLAN architecture is made up of a switching segment and wireless medium segment. In the switching segment, network congestion, WTP status, and firmware information have to be monitored. In the wireless medium segment, the dynamic nature of the medium itself has to be monitored. Overall, there are also various statistics that need to be considered for efficient WLAN operation.
中央集中型WLANアーキテクチャは、スイッチングセグメントと無線媒体セグメントから構成されています。スイッチングセグメント、ネットワークの輻輳、WTP状態、およびファームウェア情報で監視されなければなりません。無線媒体セグメントにおいて、媒体自体の動的な性質は、監視されなければなりません。全体的に、効率的なWLAN動作のために考慮する必要があるさまざまな統計もあります。
The CAPWAP protocol should be capable of monitoring the various information sources and deliver the resulting information to the relevant WLAN devices -- either WTPs or the WLAN controller. Moreover, given the relationship among information sources, the CAPWAP protocol should combine state information from them. For example, statistics information and status signals from WTPs may be merged before being exchanged.
CAPWAPプロトコルは、様々な情報源を監視することができるよう、関連するWLANデバイスに得られた情報を提供すべきである - WTPsまたはWLANコントローラのどちらか。また、情報源の関係を考えると、CAPWAPプロトコルはそれらから状態情報を組み合わせるべきです。例えば、WTPsから統計情報とステータス信号が交換される前にマージされてもよいです。
Examples of statistics information that the CAPWAP protocol should monitor and exchange include congestion state, interference levels, loss rates, and various delay factors.
CAPWAPプロトコルを監視し、交換する必要があり、統計情報としては、例えば、輻輳状態、干渉レベル、損失率、および様々な遅延因子を含みます。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST allow for the exchange of statistics, congestion, and other WLAN state information.
CAPWAPプロトコルは統計、輻輳、および他のWLAN状態情報の交換を可能にしなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The effectiveness of a protocol is based on the relevance of information on which it operates. This requirement for resource monitoring and exchange can provide the appropriate information to the CAPWAP protocol.
プロトコルの有効性は、それが操作する情報の関連性に基づいています。リソース監視及び交換のためのこの要件はCAPWAPプロトコルに適切な情報を提供することができます。
Relation to Problem Statement:
問題文との関係：
The Problem Statement highlights the challenge of dealing with large numbers of WTPs and the dynamic nature of the wireless medium. Information on the state of WTPs and the medium is important to deal with them effectively. So this objective relates to the problem of managing consistency in large WLANs.
問題文はWTPsの大きな数字と無線媒体の動的な性質を扱うの挑戦を強調しています。 WTPsと媒体の状態に関する情報は、効果的にそれらに対処することが重要です。したがって、この目的は、大規模な無線LANの一貫性を管理する問題に関するものです。
Classification: Operations
分類：オペレーション
Description:
説明：
Integral to the success of any wireless network system is the performance and quality it can offer its subscribers. Since CAPWAP-based WLANs combine a switching segment and a wireless medium segment, performance and quality need to be coordinated across both of these segments. So QoS performance must be enforced system-wide.
任意の無線ネットワークシステムの成功に不可欠な、それはその加入者に提供することができ、性能と品質です。 CAPWAPに基づくWLANは、スイッチングセグメントと無線媒体のセグメントを結合するので、性能と品質は、これらのセグメントの両方を横切って調整する必要があります。だから、QoSの性能は、システム全体施行しなければなりません。
This objective highlights QoS over the entire WLAN system, which includes the switching segment and the wireless medium segment. Given the fundamental differences between the two, it is likely that there are alternate QoS mechanisms between WTPs and wireless service subscribers and between WTPs and WLAN controllers. For instance, the former will be based on IEEE 802.11e, whereas the latter will be an alternative. So resources need to be adjusted in a coordinated fashion over both segments. The CAPWAP protocol should ensure that these adjustments are appropriately exchanged between WLAN controllers and WTPs.
この目的は、スイッチングセグメントと無線媒体セグメントを含む全体WLANシステム上のQoSを強調する。両者の間に根本的な違いを考えると、WTPsやワイヤレスサービス加入者間とWTPsとWLANコントローラ間の代替のQoSメカニズムがある可能性が高いです。後者の代替となり、一方、例えば、前者は、IEEE 802.11eのに基づいて説明します。だから、リソースは両方のセグメントにわたる協調に調整する必要があります。 CAPWAPプロトコルは、これらの調整が適切にWLANコントローラとWTPs間で交換されることを保証しなければなりません。
In addition to IEEE 802.11e, there are a number of other IEEE 802.11 task groups that may affect network resources. These include IEEE 802.11 TGk, TGu, and TGv, which are currently in progress. CAPWAP should therefore not be restricted to IEEE 802.11e-based mapping.
IEEE 802.11eのに加えて、ネットワークリソースに影響を与える可能性があり、他のIEEE 802.11のタスクグループがいくつかあります。これらは、現在進行中であるIEEE 802.11 TGK、TGU、およびTGVが含まれます。 CAPWAPは、したがって、IEEE 802.11eのベースのマッピングに限定されるものではありません。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to equivalent QoS priorities across the switching and wireless medium segments.
CAPWAPプロトコルは、スイッチング横切る等価QoSプライオリティ及び無線媒体セグメントにIEEE 802.11eのQoSプライオリティをマップする必要があります。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
A protocol that addresses QoS aspects of WLAN systems will deliver high performance thereby being beneficial for subscribers and for resource utilization efficiency. Since CAPWAP deals with WTPs directly and with the wireless medium indirectly, both of these must be considered for performance.
WLANシステムのQoSの側面を扱うプロトコルは、それによって、加入者のためとリソース利用効率のために有益であること、高いパフォーマンスを提供します。間接的WTPsとCAPWAPお得な情報を直接および無線媒体とするので、これらの両方は、パフォーマンスのために考慮しなければなりません。
For the wireless medium segment, QoS aspects in the protocol enable high-quality communications within the domain of a WLAN controller. Since each domain generally covers an enterprise or a group of service providers, such protocol performance has wide-ranging effects.
無線媒体セグメントに対して、プロトコルにおけるQoSの態様は、WLANコントローラのドメイン内で高品質な通信を可能にします。各ドメインは、一般的に、企業またはサービスプロバイダのグループをカバーしているので、そのようなプロトコルの性能は、広範囲の効果を有します。
Within the switching segment of CAPWAP, a QoS-enabled protocol minimizes the adverse effects of dynamic traffic characteristics so as to ensure system-wide performance.
システム全体の性能を確保するためにCAPWAPのスイッチングセグメント内に、QoS対応のプロトコルは、動的なトラフィック特性の悪影響を最小限に抑えます。
Relation to Problem Statement:
問題文との関係：
QoS control is critical to large WLANs and relates to a number of aspects. In particular, this objective can help address the problem of managing dynamic conditions of the wireless medium.
QoS制御は、大規模な無線LANに重要であり、側面の数に関係します。特に、この目的は、無線媒体の動的条件を管理する問題に対処することができます。
Furthermore, traffic characteristics in large-scale WLANs are constantly varying. So network utilization becomes inefficient, and user experience is unpredictable.
さらに、大規模な無線LANにおけるトラフィック特性は絶えず変化しています。だから、ネットワーク使用率が非効率的になり、ユーザーエクスペリエンスが予測不可能です。
The interaction and coordination between the two aspects of system-wide QoS are therefore critical for performance.
システム全体のQoSの二つの側面の間の相互作用との連携は、パフォーマンスのためにきわめて重要です。
Classification: Security
分類：セキュリティ
Description:
説明：
This objective addresses the security of the CAPWAP protocol.
この目的は、CAPWAPプロトコルのセキュリティに対応しています。
The CAPWAP protocol MUST first provide for the participating entities -- the WLAN controller and WTPs -- to be explicitly mutually authenticated. This is to ensure that rogue elements do not gain access to the WLAN system. Rogue WTPs should not be allowed to breach legitimate WLANs, and at the same time rogue WLAN controllers should not be allowed to gain control of legitimate WTPs. For example, WTPs may need to regularly renew their authentication state with the WLAN controller and similarly for WLAN controllers.
明示的相互認証される - WLANコントローラとWTPs - CAPWAPプロトコルが最初の参加エンティティに提供しなければなりません。これは、不正な要素がWLANシステムへのアクセス権を取得していないことを確実にするためです。ローグWTPsは、正当なWLANを侵害することは許されないと同時に、不正なWLANコントローラは、正当なWTPsの制御を得ることが許されるべきではありません。例えば、WTPsは定期的にWLANコントローラのWLANコントローラと同様に自分の認証状態を更新する必要があるかもしれません。
If authentication is performed via an authenticated key exchange, future knowledge of derived keys is not sufficient for authentication.
認証は、認証鍵交換を介して行われる場合は、派生鍵の将来の知識は、認証のために十分ではありません。
Any session keys used between the WLAN controller and WTPs MUST be mutually derived using entropy contributed by both parties. This ensures that no one party has control over the resulting session keys.
WLANコントローラとWTPs間で使用される任意のセッション鍵は、相互双方が寄与するエントロピーを用いて導出されなければなりません。これは何の一方の当事者が結果のセッション・キーを制御していないことを保証します。
Once WTPs and the WLAN controller have been mutually authenticated, information exchanges between them must be secured against various security threats. So the CAPWAP protocol MUST provide integrity protection and replay protection. The protocol SHOULD provide confidentiality through encryption. This should cover illegitimate modifications to protocol exchanges, eavesdropping, and Denial of Service (DoS) attacks, among other potential compromises. So the protocol must provide confidentiality, integrity, and authenticity for those exchanges.
WTPsとWLANコントローラが相互に認証されると、それらの間の情報交換は、さまざまなセキュリティ上の脅威から保護されなければなりません。だから、CAPWAPプロトコルが完全性保護と再生保護を提供しなければなりません。プロトコルは、暗号化によって機密性を提供する必要があります。これは、他の潜在的な妥協の間でプロトコル交換、盗聴、及びサービス拒否（DoS）攻撃に対する不正な変更をカバーすべきです。だから、このプロトコルは、これらの交換の機密性、完全性、および信頼性を提供しなければなりません。
As a result of realizing this objective, it should not be possible for individual WTP breaches to affect the security of the WLAN as a whole. So WTP misuse will be protected against.
個々のWTPの侵害が全体としてWLANのセキュリティに影響するため、この目標を実現した結果、それが可能であってはなりません。だから、WTPの誤用を保護することになります。
Additionally, the key establishment protocol for authentication and securing CAPWAP exchanges must be designed to minimize the possibility of future compromises after the keys are established.
キーが確立された後、さらに、認証およびCAPWAP交換を確保するための鍵確立プロトコルは、将来の妥協の可能性を最小にするように設計されなければなりません。
CAPWAP MUST NOT prevent the use of asymmetric authentication. The security considerations of such asymmetric authentication are described in the Security Considerations section.
CAPWAPは非対称認証の使用を妨げてはなりません。そのような非対称認証のセキュリティの考慮事項は、セキュリティの考慮事項の項に記載されています。
If the CAPWAP protocol meets the criteria to require automated key management per BCP 107 [RFC4107], then mutual authentication MUST be accomplished via an authenticated key exchange.
CAPWAPプロトコルはBCP 107 [RFC4107]あたりの自動化された鍵管理を必要とする条件を満たしている場合、相互認証は、認証鍵交換を介して達成されなければなりません。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller. It also MUST ensure that information exchanges are integrity protected and SHOULD ensure confidentiality through encryption.
CAPWAPプロトコルはWTPsの相互認証および集中コントローラをサポートしなければなりません。また、情報交換が完全性保護され、暗号化によって機密性を確保すべきであることを保証しなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
WLANs are increasingly deployed in critical aspects of enterprise and consumer networks. In these contexts, protocol security is crucial to ensure the privacy and integrity expected from network administrators and end-users. So securing the CAPWAP protocol has direct benefits in addressing these concerns.
WLANはますます、企業と消費者のネットワークの重要な側面で展開されています。これらの状況では、プロトコルのセキュリティは、ネットワーク管理者やエンドユーザーから期待されるプライバシーと整合性を確保することが重要です。だから、CAPWAPプロトコルを確保することは、これらの懸念に対処する上で直接的なメリットがあります。
In many cases, the network path between a WTP and WLAN controller contains untrusted links. Such links could be leveraged by rogue WTPs to gain access to the WLAN system. They could also be used by rogue WLAN controllers to gain control of legitimate WTPs and their associated terminals to either redirect or compromise terminal traffic. These security concerns can be mitigated with this objective.
多くの場合、WTPとWLANコントローラ間のネットワークパスは、信頼できないリンクが含まれています。このようなリンクは、WLANシステムへのアクセスを得るために、不正なWTPsで活用することができます。彼らはまた、端末のトラフィックをリダイレクトするか、妥協するか、正当なWTPsとそれに関連する端末の制御を獲得するために、不正なWLANコントローラで使用することができます。これらのセキュリティ上の懸念は、この目的を緩和することができます。
Relation to Problem Statement:
問題文との関係：
Security problems in large-scale WLANs are detailed in the Problem Statement. These include complications arising from rogue WTPs and compromised interfaces between WTPs and the WLAN controller. The requirement for protocol security addresses these problems and highlights the importance of protecting against them.
大規模な無線LANにおけるセキュリティ上の問題は、問題文で詳述されています。これらは、不正WTPsから生じる合併症およびWTPsとWLANコントローラ間の妥協インタフェースを含みます。プロトコルセキュリティのための要件は、これらの問題に対処し、それらに対して保護の重要性を強調しています。
Classification: Security
分類：セキュリティ
Description:
説明：
The emphasis of this objective is on the security threats external to the centralized CAPWAP segment of a WLAN system. The focus is therefore on rogue wireless clients and other illegitimate wireless interferences. There are a number of specific external threats that need to be addressed within the CAPWAP framework.
この目的の重点は、WLANシステムの集中CAPWAPセグメントに外部のセキュリティ上の脅威です。焦点は、不正な無線クライアントおよびその他の違法な無線の干渉にことです。 CAPWAPの枠組みの中で対処する必要があり、特定の外部からの脅威の数があります。
i. PMK Sharing
私。 PMKの共有
One aspect of this objective relates to recent discussions on Pairwise Master Key (PMK) sharing in the CAPWAP framework. This objective highlights the need to prevent exploitation of this ambiguity by rogue wireless clients. It is to ensure that any ambiguities arising from the CAPWAP framework are not cause for security breaches.
この目的の一の態様は、CAPWAPの枠組みの中でペアワイズマスターキー（PMK）共有に関する最近の議論に関するものです。この目的は、不正な無線クライアントにより、この曖昧さの悪用を防ぐための必要性を強調しています。これは、CAPWAPのフレームワークから生じるあいまいさは、セキュリティ侵害のために引き起こされていないことを確認することです。
Protocol Requirement:
プロトコル要件：
The design of the CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by external entities.
CAPWAPプロトコルの設計は、外部エンティティによってWLANシステムへの妥協のために許してはなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The external threats to the centralized WLAN architecture become increasingly crucial given the low cost of wireless clients. Since it is relatively inexpensive for rogue individuals to mount attacks, it is important that WLAN systems are protected against them. Adequate mechanisms to thwart such external threats will be of tremendous benefit to the WLAN systems controlled and managed with the CAPWAP protocol.
中央集中型WLANアーキテクチャへの外部からの脅威は、無線クライアントの低コスト与えられ、ますます重要になって。不正な個人が攻撃をマウントすることは比較的安価であるので、WLANシステムがそれらに対して保護されていることが重要です。そのような外部の脅威を阻止するための適切なメカニズムは、CAPWAPプロトコルで制御され、管理WLANシステムに多大な利益をもたらすだろう。
Relation to Problem Statement:
問題文との関係：
This objective is based on the security needs highlighted in the Problem Statement. Specifically, the Problem Statement discusses the effects of the shared wireless medium. This represents the external aspects of the CAPWAP framework from which certain threats can arise. The system-wide security objective addresses such threats in relation to the Problem Statement.
この目的は、問題文で強調表示セキュリティニーズに基づいています。具体的には、問題文は、共有無線媒体の効果について説明します。これは、特定の脅威が発生する可能性があり、そこからCAPWAPのフレームワークの外部側面を表しています。システム全体のセキュリティ対策方針のアドレス問題文との関係で、このような脅威。
Classification: Operations
分類：オペレーション
Description:
説明：
The CAPWAP protocol must support authentication in the centralized WLAN architecture in which the authenticator and encryption points can be located on distinct entities, i.e., WLAN controller or WTP. The Architecture Taxonomy illustrates a number of variants, in both local-MAC and split-MAC designs, in which the authenticator is located at the WLAN controller and the encryption points are at the WTPs. The CAPWAP protocol must be applicable to these variants and allow authentication mechanisms and their constituent processes to be operable in these cases.
CAPWAPプロトコルは、認証および暗号化のポイントは別個のエンティティ、すなわち、WLANコントローラまたはWTP上に配置することができる集中型WLANアーキテクチャで認証をサポートしなければなりません。アーキテクチャ分類は、オーセンティケータは、WLANコントローラに配置され、暗号化ポイントがWTPsにされたローカルMACおよびスプリットMAC両方の設計において、変異体の数を示します。 CAPWAPプロトコルは、これらの変異体に適用可能と認証メカニズムとその構成プロセスはこれらのケースで動作可能であることを可能にしなければなりません。
An important issue to consider in this case is the exchange of key information when authenticator and encryption points are located on distinct entities. For example, consider the case where IEEE 802.11i is used in a WLAN in which the WLAN controller realizes the authenticator, some WTPs realize encryption (possibly local-MAC WTPs), and other WTPs rely on the WLAN controller for encryption (possibly split-MAC WTPs).
オーセンティケータと暗号化のポイントは、個別のエンティティ上に配置されている場合、この場合に考慮すべき重要な問題は、キー情報の交換です。例えば、おそらくスプリット（暗号化のためのWLANコントローラに依存している場合IEEE 802.11i規格は、WLANコントローラは、オーセンティケータを実現するWLANで使用される場合、いくつかのWTPsは（おそらくローカルMAC WTPs）暗号化を実現し、他のWTPsを検討MAC WTPs）。
Here, CAPWAP will first need to identify the location of the authenticator and encryption points between each WLAN controller-WTP pair. This will likely be part of the initial WTP configuration. Subsequently, the WTPs that realize encryption will need CAPWAP to exchange key information with the authenticator at the WLAN controller. For the WTPs that do not realize encryption, CAPWAP needs to adapt its control to bypass the key exchange phase.
ここで、CAPWAPは、まず、各WLANコントローラWTPペア間オーセンティケータと暗号化の点の位置を特定する必要があります。これはおそらく、最初のWTPの構成の一部になります。その後、暗号化を実現WTPsは、WLANコントローラでオーセンティケータとキー情報を交換するCAPWAPが必要になります。暗号化を実現していないWTPsについて、CAPWAPは、鍵交換フェーズを回避するために、その制御を適応させる必要があります。
Clearly, the centralized WLAN architecture presents a different platform for authentication mechanisms compared to legacy WLANs in which a WTP realized both authenticator and encryption roles. So this objective highlights the need for CAPWAP to support authentication and key management in the centralized WLAN architecture.
明らかに、中央集中型WLANアーキテクチャは、WTPが両方のオーセンティケータと暗号化の役割を実現するレガシーWLANに比べ認証メカニズムのための異なるプラットフォームを提示します。したがって、この目的は、中央集中型WLANアーキテクチャでの認証と鍵管理をサポートするためのCAPWAPの必要性を強調しています。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished.
CAPWAPプロトコルは、認証がサポートする必要のある集中型WLANアーキテクチャの正確な構造、すなわち、主要な認証コンポーネントの位置を決定しなければなりません。これは、主要な機能が区別されてWTPの初期化中に達成することができます。
The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities.
プロトコルは、認証と暗号化の役割が明確な実体に配置されているキー情報の交換を許容しなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The immediate focus of CAPWAP is on supporting IEEE 802.11-based WLANs. As such, it is necessary for the protocol to recognize the major distinction in WLAN design with respect to IEEE 802.11i authenticator and encryption points. This represents a significant variation that has been highlighted in the Architecture Taxonomy. The CAPWAP protocol benefits by accommodating such a major consideration from IEEE 802.11i.
CAPWAPの即時の焦点は、IEEE 802.11ベースのWLANをサポートすることにあります。プロトコルはIEEE 802.11iの認証と暗号化の点でWLAN設計における主な違いを認識するためのような、それが必要です。これは、アーキテクチャの分類で強調表示された重要な変化を表しています。 IEEE 802.11i規格から、このような重要な考慮事項を収納することにより、CAPWAPプロトコルの利点。
These requirements will be common for all authentication mechanisms over the centralized WLAN architecture. So they are applicable to IEEE 802.11i, Universal Access Method (UAM), and other mechanisms.
これらの要件は、中央集中型WLANアーキテクチャ上のすべての認証メカニズムのために共通になります。そこで彼らは、IEEE 802.11i規格、ユニバーサルアクセス方法（UAM）、および他のメカニズムにも適用可能です。
Relation to Problem Statement:
問題文との関係：
The Problem Statement highlights the availability of different WTP designs and the need to ensure interoperability among them. In this regard, operational changes occurring due to the separation of the IEEE 802.11i authenticator and encryption points need to be accommodated within the CAPWAP protocol.
問題文は異なるWTPのデザインの可用性およびそれらの間の相互運用性を確保する必要性を強調しています。この点に関しては、IEEE 802.11iの認証と暗号化のポイントとの分離に起因して発生した動作上の変更は、CAPWAPプロトコル内に収容する必要があります。
Classification: Architecture
分類：建築
Description:
説明：
Two major designs of the centralized WLAN architecture are local-MAC and split-MAC. With the focusing of standardization efforts on these two designs, it is crucial to ensure mutual interoperation among them.
中央集中型WLANアーキテクチャの二つの主要なデザインは、ローカルMACおよびスプリット-MACです。これら2つの設計上の標準化活動の中心で、それらの間の相互の相互運用性を確保することが重要です。
This objective for the CAPWAP protocol is to ensure that WTPs of both local-MAC and split-MAC architecture designs are capable of interoperation within a single WLAN. Consequently, a single WLAN controller will be capable of controlling both types of WTPs using a single CAPWAP protocol. Integral support for these designs comprises a number of protocol aspects.
CAPWAPプロトコルのこの目的は、両方のローカルMACおよびスプリットMACアーキテクチャ設計のWTPsが単一のWLAN内で相互運用可能であることを保証することです。したがって、単一のWLANコントローラは、単一のCAPWAPプロトコルを使用WTPs両方のタイプを制御することができるであろう。これらの設計のための不可欠なサポートは、プロトコルの側面の数を含みます。
i. Capability negotiations between WLAN controller and WTPs
私。 WLANコントローラとWTPs間の能力交渉
WTP designs differ in the degree of IEEE 802.11 MAC functionalities that each type of WTP realizes. The major distinctions, split-MAC and local-MAC, differ in the processing of IEEE 802.11 MAC frames. In this regard, the CAPWAP protocol should include functionality that allows for negotiations of significant capabilities between WTPs and the WLAN controller.
WTP設計はWTPの各タイプが実現するIEEE 802.11 MAC機能性の程度が異なります。主要な相違、スプリットMACとローカルMACは、IEEE 802.11 MACフレームの処理が異なります。この点で、CAPWAPプロトコルはWTPsとWLANコントローラとの間の重要な機能の交渉を可能にする機能を含むべきです。
As a first step, such negotiations could cover the type of WTP, split-MAC or local-MAC, as this provides substantial information on their respective capabilities.
これは、それぞれの機能に実質的な情報を提供するように、第1のステップとして、このような交渉は、WTP、スプリットMACまたはローカルMACのタイプをカバーできます。
ii. Establishment of alternative interfaces
II。代替インタフェースの確立
The capability differences among different WTPs essentially equate to alternative interfaces with a WLAN controller. So the CAPWAP protocol should be capable of adapting its operations to the major different interfaces. In a first case, this would include accommodating capability differences between local-MAC and split-MAC WTPs.
異なるWTPs間の能力差は、本質的にWLANコントローラと別のインターフェイスに等しいです。そうCAPWAPプロトコルは主要な異なるインターフェイスにその動作を適応させることができなければなりません。最初のケースでは、これはローカルMACとのスプリットMAC WTPs間の収容能力の差が含まれるであろう。
The definition of these interfaces in terms of finer granularity of functionalities will be based on AP functionality documents produced by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee.
機能性のより細かい粒度の点で、これらのインタフェースの定義は、IEEE 802.11 AP機能（APF）アドホック委員会によって生成AP機能のドキュメントに基づいて説明します。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST include sufficient capabilities negotiations to distinguish between major types of WTPs.
CAPWAPプロトコルはWTPsの主要なタイプを区別するために十分な能力交渉を含まなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The benefits of realizing this architecture objective are both technical and practical. First, there are substantial overlaps in the control operations of local-MAC and split-MAC architecture designs. The Architecture Taxonomy tabulates major common features of the two designs. As a result, it is technically practical to devise a single protocol that manages both types of devices.
このアーキテクチャの目的を実現することの利点は、技術的かつ実用的です。まず、ローカルMACおよびスプリットMACアーキテクチャ設計の制御動作に実質的な重複があります。アーキテクチャ分類は、2つの設計の主要な共通の特徴を表にしたものです。その結果、装置の両方のタイプを管理する単一のプロトコルを考案することは技術的に実用的です。
Next, the ability to operate a CAPWAP protocol for both types of architectural designs enhances its practical prospects as it will have wider appeal.
それは、より広い魅力を持っているだろうと次に、建築デザインの両方のタイプのCAPWAPプロトコルを動作する能力は、その実用的な見通しを強化します。
Furthermore, the additional complexity resulting from such alternative interfaces is marginal. Consequently, the benefits of this objective will far outweigh any cost of realizing it.
さらに、そのような代替的なインターフェイスから生じる追加の複雑さが限界です。したがって、この目的の利点は、はるかにそれを実現することのいずれかのコストを上回るだろう。
Relation to Problem Statement:
問題文との関係：
The objective for supporting both local-MAC and split-MAC WTPs is fundamental to addressing the Problem Statement. It forms the basis for those problems to be uniformly addressed across the major WLAN architectures. This is the ultimate aim of standardization efforts. The realization of this objective will ensure the development of a comprehensive set of mechanisms that address the challenges of large-scale WLAN deployments.
ローカル-MACとのスプリットMAC WTPsの両方をサポートするための目的は、問題文に対処する基本です。これは、これらの問題は、一様に、主要なWLANアーキテクチャ全体に対処するための基礎を形成します。これは、標準化活動の究極の目的です。この目的の実現は、大規模なWLAN展開の課題に対処メカニズムの包括的なセットの開発を保証します。
Classification: General
分類：一般
Description:
説明：
WLAN equipment vendors require sufficient details from protocol specifications so that implementing them will allow for compatibility with other equipment that runs the same protocol. In this light, it is important for the CAPWAP protocol specifications to be reasonably complete for realization.
それらを実装すると、同じプロトコルを実行し、他の機器との互換性を可能にするように、WLAN機器ベンダーは、プロトコル仕様から十分な詳細を必要としています。 CAPWAPプロトコル仕様を実現するために合理的に完全であるために、この光の中で、それが重要です。
Protocol Requirement:
プロトコル要件：
Any WTP or WLAN controller vendor or any person MUST be able to implement the CAPWAP protocol from the specification itself and by that it is required that all such implementations do interoperate.
任意WTPまたはWLANコントローラベンダまたは任意の人は、明細書自体から、すべてのそのような実装が相互運用ないことが必要であることにより、CAPWAPプロトコルを実装することができなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
It is beneficial for WLAN equipment vendors to refer to a single set of specifications while implementing the CAPWAP protocol. This helps to ease and quicken the development process.
CAPWAPプロトコルを実装しながら、WLAN機器ベンダーが仕様の単一のセットを参照することが有益です。このことは、容易にし、開発プロセスを迅速化するのに役立ちます。
Relation to Problem Statement:
問題文との関係：
This requirement is based on WG discussions that have been determined to be important for CAPWAP.
この要件は、CAPWAPのために重要であると決定されたWGの議論に基づいています。
Classification: General
分類：一般
Description:
説明：
Rapid developments in WLAN technologies result in equipment vendors constantly modifying their devices. In many cases, developments are independently made for WLAN controllers and WTPs. The CAPWAP protocol should not affect the independence of device modifications.
WLAN技術の急速な発展は、絶えず自分のデバイスを変更する機器ベンダーにつながります。多くの場合、開発は独立してWLANコントローラとWTPsのために作られています。 CAPWAPプロトコルは、デバイス変更の独立性に影響を与えるべきではありません。
Protocol Requirement:
プロトコル要件：
A WTP vendor SHOULD be able to make modifications to hardware without any WLAN controller vendor involvement.
WTPベンダーは、任意のWLANコントローラベンダーの関与なしにハードウェアの変更を行うことができるべきです。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
Independence in the type of hardware for WLAN equipment ensures that new developments do not hamper protocol operation.
WLAN機器のハードウェアの種類の独立は、新たな展開がプロトコルの動作を妨げないことを保証します。
Relation to Problem Statement:
問題文との関係：
This requirement is based on WG discussions that have been determined to be important for CAPWAP.
この要件は、CAPWAPのために重要であると決定されたWGの議論に基づいています。
Classification: General
分類：一般
Description:
説明：
The CAPWAP protocol must not be specified for a particular type of wireless MAC design. It should be compatible with both local-MAC and split-MAC WTPs.
CAPWAPプロトコルは、無線MAC設計の特定のタイプのために指定することはできません。これは、ローカルMACとのスプリットMAC WTPsの両方と互換性があります。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST NOT limit WTP vendors in their choice of local-MAC or split-MAC WTPs. It MUST be compatible with both types of WTPs.
CAPWAPプロトコルは、ローカルMACまたは分割-MAC WTPsの彼らの選択にWTPベンダーを制限してはなりません。それはWTPsの両方のタイプと互換性がなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
This requirement is to ensure that WTP vendors have sufficient flexibility in selecting the type of wireless MAC design that they consider best for deployments.
この要件は、WTPのベンダーは、彼らが展開するための最良の考慮する無線MACデザインの種類を選択する上で十分な柔軟性を持っていることを確認することです。
Relation to Problem Statement:
問題文との関係：
This requirement is based on WG discussions that have been determined to be important for CAPWAP.
この要件は、CAPWAPのために重要であると決定されたWGの議論に基づいています。
Classification: General
分類：一般
Description:
説明：
WLAN deployments may involve WTPs and the WLAN controller communicating across Network Address Translators (NATs). The CAPWAP protocol must be capable of operating across topologies that contain known NAT configurations. It requires appropriate discovery and identification mechanisms for NAT traversal.
WLANの展開はWTPsを含んでいてもよいし、ネットワークを介して通信を行うWLANコントローラは、翻訳器（NAT）のアドレス。 CAPWAPプロトコルが知られているNATの設定が含まれているトポロジ全体での動作が可能でなければなりません。それは、NATトラバーサルのための適切な検出と識別メカニズムが必要です。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST NOT prevent the operation of established methods of NAT traversal.
CAPWAPプロトコルは、NATトラバーサルの確立された方法の動作を妨げてはなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The widespread adoption of WLANs raises the possibility for WLAN topologies containing NATs. It is important for the CAPWAP protocol to be applicable within such topologies. This requirement aims to make the CAPWAP protocol relevant for NAT traversal.
無線LANの普及には、NATをを含むWLANトポロジの可能性を高めます。 CAPWAPプロトコルは、このようなトポロジ内で適用されることが重要です。この要件は、NATトラバーサルに関連するCAPWAPプロトコルを作ることを目指しています。
Relation to Problem Statement:
問題文との関係：
This requirement is based on WG discussions that have been determined to be important for CAPWAP.
この要件は、CAPWAPのために重要であると決定されたWGの議論に基づいています。
These objectives have been determined to be desirable for a CAPWAP protocol but not mandatory. Realizing these objectives may help improve control of WLANs but need not necessarily be required for all networks or scenarios.
これらの目的は、CAPWAPプロトコルのために望ましいが、必須ではないことが決定されています。これらの目的を実現するためにWLANの制御を改善するが、必ずしもすべてのネットワークやシナリオに必要とされる必要がないに役立つことがあります。
Classification: Architecture
分類：建築
Description:
説明：
Shared WLAN infrastructure raises the issue of multiple authentication mechanisms. This is because each logical group is likely to be associated with different service providers or WLAN domains. As a result, the authentication needs within them will be different. Although CAPWAP is required to support IEEE 802.11i, it is also necessary for it to support other authentication mechanisms. For example, one logical group may use IEEE 802.11i, whereas another may use web authentication. CAPWAP must be able to operate in such shared WLANs.
共有WLANインフラストラクチャは、複数の認証メカニズムの問題を提起します。各論理グループは、異なるサービスプロバイダまたはWLANドメインに関連付けされる可能性があるためです。その結果、それらの中の認証のニーズが異なることになります。 CAPWAPは、IEEE 802.11i規格をサポートするために必要であるが、それは他の認証メカニズムをサポートすることも必要です。別のWeb認証を使用することができるのに対し、例えば、一つの論理グループは、IEEE 802.11i規格を使用してもよいです。 CAPWAPは、共有のWLANで動作することができなければなりません。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST support different authentication mechanisms in addition to IEEE 802.11i.
CAPWAPプロトコルはIEEE 802.11i規格に加えて、異なる認証メカニズムをサポートしなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The benefit of supporting various authentication mechanisms is that the protocol then becomes flexible for use in various deployments. The protocol will therefore not mandate the use of any particular mechanisms that may not be appropriate for a particular deployment.
様々な認証メカニズムをサポートすることの利点は、プロトコルは、その後、様々な展開で使用するための柔軟になることです。プロトコルは、したがって、特定のデプロイメントのために適切ではないかもしれない任意の特定の機構の使用を強制しないであろう。
Relation to Problem Statement:
問題文との関係：
This objective relates to the problem of management complexity. Shared WLAN deployments simplify management of large networks.
この目的は、管理の複雑さの問題に関するものです。共有WLANの展開は、大規模ネットワークの管理を簡素化。
Classification: Architecture
分類：建築
Description:
説明：
The rapid pace of technology developments means that new advances need to be catered to in current analyses. Among these is the support for new wireless technologies within the CAPWAP protocol, such as IEEE 802.16. The protocol should therefore not rely on specifics of IEEE 802.11 technology.
技術開発の急速なペースで新たな進歩は、現在分析中に仕出し料理する必要があることを意味します。これらの中には、IEEE 802.16などCAPWAPプロトコル内の新しい無線技術のためのサポートです。プロトコルは、したがって、IEEE 802.11技術の仕様に依存すべきではありません。
In all cases where the CAPWAP protocol messages contain specific layer 2 information elements, the definition of the protocol needs to provide for extensibility so that these elements can be defined for specific layer 2 wireless protocols. This may entail assigning a layer 2 wireless protocol type and version field to the message PDU. Examples of other wireless protocols that might be supported include but are not limited to 802.16e, 802.15.x, etc.
CAPWAPプロトコルメッセージが特定のレイヤ2情報要素を含むすべての場合において、プロトコルの定義は、これらの要素は、特定のレイヤ2無線プロトコルのために定義することができるように拡張性を提供する必要があります。これは、メッセージPDUをレイヤ2無線プロトコルのタイプとバージョン・フィールドを割り当てる必要とすることができます。サポートされるかもしれない他の無線プロトコルの例としては、等の802.16e、802.15.x、これらに限定されません
Protocol Requirement:
プロトコル要件：
CAPWAP protocol messages MUST be designed to be extensible for specific layer 2 wireless technologies. It should not be limited to the transport of elements relating to IEEE 802.11.
CAPWAPプロトコル・メッセージは、特定のレイヤ2無線技術のために拡張できるように設計されなければなりません。これは、IEEE 802.11に関連する要素の輸送に限定されるべきではありません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
There are many benefits to an extensible protocol. It allows for application in different networks and provides greater scope. Furthermore, service providers require WLAN solutions that will be able to meet current and future market requirements.
拡張可能なプロトコルには多くの利点があります。これは、異なるネットワークにおけるアプリケーションを可能にし、より大きな範囲を提供します。さらに、サービスプロバイダは、現在および将来の市場要件を満たすことができるようになりますWLANソリューションを必要としています。
Relation to Problem Statement:
問題文との関係：
The Problem Statement describes some of the advances taking place in other standards bodies like the IEEE. It is important for the CAPWAP protocol to reflect the advances and provide a framework in which they can be supported.
問題文は、IEEEのような他の標準化団体で行われているの進歩のいくつかを説明します。 CAPWAPプロトコルが進歩を反映し、彼らがサポートすることが可能なフレームワークを提供することが重要です。
Classification: Architecture
分類：建築
Description:
説明：
The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11 functionality and has made more thorough definitions for the new requirements. The CAPWAP protocol must be able to incorporate these definitions with minimal change. Furthermore, a number of extensions for IEEE 802.11 are currently being standardized. The CAPWAP protocol must also be able to incorporate these new extensions with minimal change.
IEEE 802.11 APFアドホック委員会は、IEEE 802.11の機能を検討しており、新たな要件のために、より徹底した定義がなされています。 CAPWAPプロトコルは、最小限の変更で、これらの定義を組み込むことができなければなりません。さらに、IEEE 802.11のための拡張機能の数は、現在標準化されています。 CAPWAPプロトコルはまた、最小限の変更でこれらの新しい拡張機能を組み込むことができなければなりません。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST be openly designed to support new IEEE 802.11 definitions and extensions.
CAPWAPプロトコルは、公然と新しいIEEE 802.11の定義および拡張をサポートするように設計されなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
There are a number of advances being made within the IEEE regarding the functionality of IEEE 802.11 technology. Since this represents one of the major wireless technologies in use today, it will be beneficial for CAPWAP to incorporate the relevant new extensions.
IEEE 802.11テクノロジーの機能に関するIEEE以内になされているの進歩の数があります。これは、使用中の主要な無線技術の一つ、今日を表すので、それが関連する新しい拡張機能を組み込むためにCAPWAPのために有益になります。
Relation to Problem Statement:
問題文との関係：
The Problem Statement presents an overview of the task of the IEEE 802.11 working group. This group is focused on defining the functional architecture of WTPs and new extensions for it. It is necessary for the CAPWAP protocol to reflect these definitions and extensions.
問題文は、IEEE 802.11ワーキンググループのタスクの概要を説明します。このグループはWTPsとそれのための新しい拡張機能の機能アーキテクチャを明確にすることに集中しています。 CAPWAPプロトコルはこれらの定義および拡張を反映することが必要です。
Classification: Architecture
分類：建築
Description:
説明：
Large-scale WLAN deployments are likely to use a variety of interconnection technologies between different devices of the network. It should therefore be possible for the CAPWAP protocol to operate over various interconnection technologies.
大規模なWLANの展開は、ネットワークの異なるデバイス間の相互接続技術のさまざまなを使用する可能性があります。 CAPWAPプロトコルは、様々な相互接続技術で動作することがことが可能でなければなりません。
As a result of realizing this objective, the protocol will be capable of operation over both IPv4 and IPv6. It will also be designed such that it can operate within tightly administered networks, such as enterprise networks, or on open, public access networks. For example, VLAN tunnels can be used across different types of networks over which CAPWAP will operate.
この目的を実現した結果として、プロトコルは、IPv4とIPv6の両方にわたって動作することができるであろう。それはまた、このような企業ネットワークとしてしっかり投与ネットワーク内、またはオープン、パブリックアクセスネットワーク上で動作できるように設計されます。例えば、VLANトンネルはCAPWAPが動作する上に異なる種類のネットワークにまたがって使用することができます。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST NOT be constrained to specific underlying transport mechanisms.
CAPWAPプロトコルは、特定の基本的な輸送機構に拘束されてはいけません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
The main aim of the CAPWAP protocol is to achieve interoperability among various WTPs and WLAN controllers. As such, the motivation for this requirement is for the protocol to be operable independent of underlying interconnection technologies.
CAPWAPプロトコルの主な目的は、様々なWTPsとWLANコントローラ間での相互運用性を達成することです。このように、この要求のための動機は、下にある相互接続技術の動作可能な独立するプロトコルのためのものです。
Relation to Problem Statement:
問題文との関係：
The Problem Statement discusses the complexity of configuring large WLANs. The selection of available interconnection technologies for large-scale deployments further intensifies this complexity. This requirement avoids part of the complexity by advocating independence of the operational aspects of the protocol from underlying transport.
問題文は、大規模なWLANを設定の複雑さを説明します。大規模な展開に利用可能な相互接続技術の選択は、さらに、この複雑性を強めます。この要件は、基礎となるトランスポートプロトコルからの運用面の独立性を主張することにより、複雑の一部を回避することができます。
Classification: Operations
分類：オペレーション
Description:
説明：
This objective focuses on the informational needs of WLAN access control and specifically the role of the CAPWAP protocol in transporting this information between WTPs and their WLAN controller.
この目的は、WLANアクセス制御、具体的にWTPsとそのWLANコントローラ間の情報の輸送にCAPWAPプロトコルの役割の情報のニーズに焦点を当てています。
The following are some specific information aspects that need to be transported by the CAPWAP protocol:
以下のCAPWAPプロトコルによって搬送する必要があるいくつかの特定の情報の側面は、次のとおりです。
i. IEEE 802.11 association and authentication
私。 IEEE 802.11アソシエーションと認証
The association of wireless clients is distinct for initial and roaming cases. As a result, access control mechanisms require specific contextual information regarding each case. Additionally, load balancing, QoS, security, and congestion information in both wireless medium segments and switching segments need to be considered.
ワイヤレスクライアントの関連付けは、初期およびローミングの場合のために別個のものです。その結果、アクセス制御メカニズムは、それぞれの場合について、具体的なコンテキスト情報を必要とします。また、ロードバランシングは、QoSは、セキュリティ、および輻輳の両方無線媒体のセグメント内の情報およびスイッチングセグメントを考慮する必要があります。
ii. WTP Access Control
II。 WTPのアクセス制御
In addition to controlling access for wireless clients, it is also necessary to control admission of new WTPs. Given the threat of rogue WTPs, it is important for CAPWAP to relay appropriate authentication information between new WTPs and the WLAN controller.
無線クライアントのアクセスを制御することに加えて、新しいWTPsの入場を制御することも必要です。 CAPWAPは新しいWTPsとWLANコントローラ間の適切な認証情報を中継するため、不正なWTPsの脅威を考えると、それは重要です。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol MUST be capable of exchanging information required for access control of WTPs and wireless terminals.
CAPWAPプロトコルはWTPs及び無線端末のアクセス制御に必要な情報を交換することができなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
Due to the scale of deployments in which CAPWAP will be employed, comprehensive access control is crucial. The effectiveness of access control in turn is affected by the information on which such control is based. As a result, this objective has critical relevance to a CAPWAP protocol.
原因CAPWAPが採用されている展開のスケールに、総合的なアクセス制御が不可欠です。次にアクセス制御の有効性は、このような制御が基づいている情報に影響されます。その結果、この目的は、CAPWAPプロトコルに重要な関連性を持っています。
Relation to Problem Statement:
問題文との関係：
This objective addresses the issue of access control in large WLANs. Broadly, it relates the problem of managing the complexity scale of such networks. With collective information of both switching and wireless medium segments, realizing this objective will help control and manage complexity.
この目的は、大規模な無線LANにおけるアクセス制御の問題を解決します。大まかに言えば、それはこのようなネットワークの複雑さの規模を管理する問題に関する。スイッチングおよび無線媒体セグメントの両方の集合情報を、この目的を実現する制御を支援し、複雑さを管理します。
The following objectives have been prioritized as non-objectives during the course of working group consultations. They have been prioritized so in the context of CAPWAP and its considerations. They may, however, be applicable in alternative contexts.
次の目標は、ワーキンググループの協議の過程で非目的として優先順位付けされています。彼らはCAPWAPとその考察の文脈でそう優先順位付けされています。彼らは、しかし、代替コンテキストに適用することができます。
Classification: Architecture
分類：建築
Description:
説明：
The CAPWAP protocol should provide an engine-mechanism to spring WTP auto-configuration and/or software version updates and should support integration with existing network management system. WLAN controller as a management agent is optional.
CAPWAPプロトコルはWTP自動コンフィギュレーションおよび/またはソフトウェアのバージョン更新を春にエンジンメカニズムを提供するべきであり、既存のネットワーク管理システムとの統合をサポートしなければなりません。管理エージェントとしてWLANコントローラはオプションです。
If entities other than WLAN controllers manage some aspects of WTPs, such as software downloads, the CAPWAP protocol may be used for WTPs to notify WLAN controllers of any changes made by the other entities.
WLANコントローラ以外のエンティティは、そのようなソフトウェアのダウンロードなどWTPsのいくつかの側面を、管理する場合は、CAPWAPプロトコルは、他のエンティティによって行われた変更のWLANコントローラに通知するWTPsのために使用することができます。
Protocol Requirement:
プロトコル要件：
The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and existing network management systems.
CAPWAPプロトコルは、ネットワーク管理システムをレガシーWTPsを認識し、既存のできるものでなければなりません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
It is expected that in many cases, the centralized WLAN architecture will be deployed incrementally with legacy systems. In this regard, it is necessary for the protocol to be used in scenarios with mixed WLAN devices.
多くの場合、中央集中型WLANアーキテクチャは、レガシーシステムと、増分展開されることが期待されます。プロトコルは、混合WLANデバイスとのシナリオで使用するためにこの点で、それが必要です。
Relation to Problem Statement:
問題文との関係：
The Problem Statement highlights management complexity as a major issue with large WLANs. One part of this complexity can be related to the incremental deployment of centralized WLAN devices for which this objective is applicable.
問題文は、大規模な無線LANとの大きな問題として、管理の複雑さを強調しています。この複雑さの一部は、この目的が適用されるための集中WLANデバイスの増分の展開に関連することができます。
Classification: General
分類：一般
Description:
説明：
The CAPWAP protocol must not require AC and WTP vendors to share technical specifications to establish compatibility. The protocol specifications alone must be sufficient for compatibility.
CAPWAPプロトコルは、互換性を確立するための技術仕様を共有するためにACとWTPのベンダーを要求してはなりません。単独のプロトコル仕様は、互換性のために十分なものでなければなりません。
Protocol Requirement:
プロトコル要件：
WTP vendors SHOULD NOT have to share technical specifications for hardware and software to AC vendors in order for interoperability to be achieved.
WTPのベンダーは、相互運用性を達成することがためにACベンダーにハードウェアとソフトウェアの技術仕様を共有する必要はありません。
Motivation and Protocol Benefits:
動機とプロトコルの利点：
It is beneficial for WLAN equipment vendors to refer to a single set of specifications while implementing the CAPWAP protocol. This helps to ease and quicken the development process.
CAPWAPプロトコルを実装しながら、WLAN機器ベンダーが仕様の単一のセットを参照することが有益です。このことは、容易にし、開発プロセスを迅速化するのに役立ちます。
Relation to Problem Statement:
問題文との関係：
This requirement is based on WG discussions that have been determined to be important for CAPWAP.
この要件は、CAPWAPのために重要であると決定されたWGの議論に基づいています。
This objective has been prioritized as a non-objective as it is a duplicate of the Protocol Specifications objective (Section 5.1.12).
それはプロトコル仕様の目的（セクション5.1.12）の複製であるとして、この目的は、非目的として、優先順位付けされています。
The following objectives have been provided by network service operators. They represent the requirements from those ultimately deploying the CAPWAP protocol in their WLANs.
次の目標は、ネットワークサービス事業者によって提供されています。彼らは最終的には無線LANでのCAPWAPプロトコルを展開し、それらからの要求を表しています。
Classification: Operations
分類：オペレーション
Description:
説明：
Network service operators consider handoffs crucial because of the mobile nature of their customers. In this regard, the CAPWAP protocol should not adversely affect AP fast-handoff procedures. The protocol may support optimizations for fast handoff procedures so as to allow better support for real-time services during handoffs.
ネットワークサービス事業者は、その顧客の携帯自然のハンドオフが重要考えます。この点で、CAPWAPプロトコルは悪AP高速ハンドオフ手順に影響を与えるべきではありません。ハンドオフ時のリアルタイムサービスのためのより良いサポートを可能にするように、プロトコルは、高速ハンドオフ手順の最適化をサポートすることができます。
Protocol Requirement:
プロトコル要件：
CAPWAP protocol operations MUST NOT impede or obstruct the efficacy of AP fast-handoff procedures.
CAPWAPプロトコル操作はAP高速ハンドオフ手順の有効性を妨げたり妨害してはなりません。
The objectives presented in this document address three main aspects of the CAPWAP protocol, namely:
目的はつまり、この文書アドレスCAPWAPプロトコルの三つの主要な側面で提示します：
i. Architecture ii. Operations iii. Security
私。アーキテクチャII。操作III。セキュリティ
These requirements are aimed at focusing standardization efforts on a simple, interoperable protocol for managing large-scale WLANs. The architecture requirements specify the structural features of the protocol such as those relating to WTP types (local-MAC and split-MAC) and WTP structures (logical groups). The operations requirements address the functional aspects dealing with WTP configuration and management. Finally, the security requirements cover authentication and integrity aspects of protocol exchanges.
これらの要件は、大規模なWLANを管理するためのシンプルな、相互運用可能なプロトコルに標準化の努力を集中することを目的としています。アーキテクチャ要件は、WTPの種類（ローカルMACおよびスプリットMAC）とWTP構造（論理グループ）に関連するものなどのプロトコルの構造的特徴を指定します。業務要件は、WTPの設定と管理を扱う機能的側面を扱います。最後に、セキュリティ要件は、プロトコル交換の認証と完全性の側面をカバーしています。
The objectives have additionally been prioritized to reflect their immediate significance to the development and evaluation of an interoperable CAPWAP protocol. The priorities are Mandatory and Accepted, Desirable, and Non-Objectives. They reflect working group consensus on the effectiveness of the requirements in the context of protocol design.
目標は、さらに相互運用可能CAPWAPプロトコルの開発と評価への直接の重要性を反映するために、優先順位付けされています。優先順位は必須と認められた、望ましい、および非目標です。彼らは、プロトコル設計の文脈における要件の有効性に関するワーキンググループの総意を反映しています。
Additionally, this document includes requirements from network service operators that have been derived based on their experience in operating large-scale WLANs.
また、この文書では動作し、大規模な無線LANでの経験に基づいて導出されたネットワークサービス事業者からの要件が含まれています。
The resulting requirements from this document will be used in conjunction with the CAPWAP Problem Statement [RFC3990] and CAPWAP Architecture Taxonomy [RFC4118] to develop and evaluate an interoperable protocol for the control and provisioning of WTPs in large-scale WLANs.
この文書から得られた要件は、大規模な無線LANにおけるWTPsの制御およびプロビジョニングのための相互運用可能なプロトコルを開発し、評価するためにCAPWAP問題ステートメント[RFC3990]とCAPWAPアーキテクチャ分類[RFC4118]と組み合わせて使用されるであろう。
The CAPWAP framework highlights support for both local-MAC and split-MAC WTPs. In deployments where both types of WTPs are used, it is crucial to ensure that each be secured in consideration of its capabilities. The Architecture Taxonomy illustrates how different WTPs incorporate varying levels of functionalities. Development of the CAPWAP protocol should ensure that the deployment of both local-MAC and split-MAC WTPs within a single WLAN do not present loopholes for security compromises.
CAPWAPのフレームワークのハイライトは、ローカルMACとのスプリットMAC WTPsの両方に対応しています。 WTPs両方のタイプを使用する展開では、それぞれがその機能を考慮して確保することを確実にするために重要です。アーキテクチャ分類はWTPsは、機能のさまざまなレベルを組み込む方法を異なる示します。 CAPWAPプロトコルの開発は、単一のWLAN内のローカル-MACとのスプリットMAC WTPs両方の展開は、セキュリティの妥協のために本抜け穴していないことを確認する必要があります。
In shared WLAN deployments made of a number of logical groups, traffic from each group needs to be mutually separated. So in addition to protocol-related exchanges, data traffic from wireless terminals should also be segregated with respect to the logical groups to which they belong. It should not be possible for data or control traffic from one logical group to stray to or influence another logical group.
論理グループの数からなる共有WLANの展開では、各グループからのトラフィックは、相互に分離される必要があります。そうプロトコル関連の交換に加えて、無線端末からのデータトラフィックは、それらが属する論理グループに対して分離されるべきです。一つの論理グループからのデータまたは制御トラフィックがに逸脱したり、別の論理グループに影響を与えることが可能にすべきではありません。
The use of IEEE 802.11i over the centralized WLAN architecture allows for implementations in which the PMK is shared across WTPs. This raises the ambiguity between legitimate sharing and illegitimate copies. Wireless terminals may unknowingly fall prey to or exploit this ambiguity. The resolution of this issue is currently being evaluated by the IEEE 802 and IETF liaisons.
中央集中型WLANアーキテクチャ上IEEE 802.11i規格の使用は、PMKをWTPs間で共有された実装を可能にします。これは、合法的な共有や違法なコピー間のあいまいさを上げます。無線端末は、無意識のうちに餌食になるか、この曖昧さを利用することができます。この問題の解決は、現在、IEEE 802とIETFリエゾンによって評価されています。
The low cost of launching attacks on WLANs makes the CAPWAP protocol a target. A first step in securing against any form of attacks is to continuously monitor the WLAN for conditions of potential threats from rogue WTPs or wireless terminals. For example, profiles for DoS and replay attacks need to be considered for the CAPWAP protocol to effectively monitor security conditions.
無線LANへの攻撃を開始する低コストはCAPWAPプロトコル対象になります。攻撃の任意の形式に対して固定するための最初のステップは、連続的に不正WTPs又は無線端末からの潜在的な脅威の条件のためにWLANを監視することです。たとえば、DoS攻撃やリプレイ攻撃のためのプロファイルは、効果的なセキュリティの状態を監視するためのCAPWAPプロトコルのために考慮する必要があります。
The open environment of many WLAN deployments makes physical security breaches highly probable. Compromises resulting from theft and physical damage must be considered during protocol development. For instance, it should not be possible for a single compromised WTP to affect the WLAN as a whole.
多くのWLAN展開のオープンな環境は、物理的なセキュリティ侵害が可能性が高いことができます。盗難や物理的な損傷に起因する妥協は、プロトコルの開発中に考慮しなければなりません。単一妥協WTPは、全体としてWLANに影響を与えるようにするために例えば、それは可能ではありません。
Considering asymmetric, non-mutual authentication between WTPs and the WLAN controller, there is a risk of a rogue participant exploiting such an arrangement. It is preferable to avoid non-mutual authentication. In some cases, the legitimacy of the protocol exchange participants may be verified externally, for example, by means of physical containment within a close environment. Asymmetric authentication may be appropriate here without risk of security compromises.
WTPsとWLANコントローラ間の非対称、非相互認証を考慮すると、このような構成を利用する不正な参加者の危険性があります。非相互認証を避けることが好ましいです。いくつかのケースでは、プロトコル交換の参加者の正当性は近い環境内の物理的封じ込めの手段によって、例えば、外部から確認することができます。非対称認証はセキュリティ上の妥協のリスクなしに、ここで適切であるかもしれません。
The authors would like to thank the working group chairs, Dorothy Gellert and Mahalingam Mani, for their support and patience with this document. We would also like to thank participants of the working group who have helped shape the objectives. In particular, the authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan Harkins, T. Sridhar, Charles Clancy, and Emek Sadot for their invaluable inputs. We also extend our gratitude to the IEEE 802.11 Ad-Hoc Committee for its evaluation of the document. The authors also acknowledge the contributions from Meimei Dang, Satoshi Iino, Mikihito Sugiura, and Dong Wang.
著者は、この文書で彼らのサポートと忍耐のために、ワーキンググループチェア、ドロシーゲッレールトとMahalingamマニに感謝したいと思います。我々はまた、目標を形作る助けたワーキンググループの参加者に感謝したいと思います。特に、著者は彼らの貴重な入力のためにジェームス・ケンプ、パットカルフーン、Inderpreetシン、ダンハーキンズ、T.シュリダール、チャールズ・クランシー、およびエメックSadotに感謝します。また、文書のその評価のためのIEEE 802.11アドホック委員会に感謝の意を拡張します。著者らはまたMeimeiダン、聡飯野、幹人杉浦、そしてドン王からの貢献を認めます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[RFC3990]オハラ、B.、カルフーン、P.、およびJ.ケンフ、 "ワイヤレスアクセスポイント（CAPWAP）問題文の構成およびプロビジョニング"、RFC 3990、2005年2月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]ヤン、L.、Zerfos、P.、およびE. Sadot、RFC 4118、2005年6月の "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のためのアーキテクチャ分類学"。
[802.11] IEEE Standard 802.11, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", June 2003.
[802.11] IEEE規格802.11、 "無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、2003年6月。
[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC) Security Enhancements", July 2004.
[802.11i規格] IEEE規格802.11i規格、 "メディアアクセス制御（MAC）セキュリティ強化"、2004年7月。
[802.11e] IEEE Standard 802.11e, "Medium Access Control (MAC) Quality of Service Enhancements", November 2005.
[802.11eの] IEEE標準802.11eの、 "サービスの機能強化の媒体アクセス制御（MAC）品質"、2005年11月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
Authors' Addresses
著者のアドレス
Saravanan Govindan Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore
Saravananゴヴィンダンパナソニックシンガポール研究所ブロック1022、タイセン工業団地の＃06から3530まで、タイセンアベニューシンガポール534 415シンガポール
Phone: +65 6550 5441 EMail: saravanan.govindan@sg.panasonic.com
電話：+65 6550 5441 Eメール：saravanan.govindan@sg.panasonic.com
Zhonghui Yao Huawei Longgang Production Base Shenzhen 518 129 P. R. China
Zレッド屋ああUAは本当に非常に長い生産拠点だけで518 129 P. R.中国です
Phone: +86 755 2878 0808 EMail: yaoth@huawei.com
電話：+86 755 2878 0808 Eメール：yaoth@huawei.com
Wenhui Zhou China Mobile 53A, Xibianmen Ave, Xuanwu District Beijing 100 053 P. R. China
WEN意志周、中国の携帯電話53A、ξ改札AVああ、X UA N地区北京100 053 P. R.中国なし
Phone: +86 10 6600 6688 ext.3061 EMail: zhouwenhui@chinamobile.com
電話：+86 10 6600 6688 ext.3061 Eメール：zhouwenhui@chinamobile.com
L. Lily Yang Intel Corp. JF3-206, 2111 NE 25th Ave. Hilsboro, OR 97124 USA
L.リリーヤンインテル社JF3-206、2111 NE 25日アベニュー。ヒルズボロ、OR 97124 USA
Phone: +1 503 264 8813 EMail: lily.l.yang@intel.com
電話：+1 503 264 8813 Eメール：lily.l.yang@intel.com
Hong Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore
香港チェンパナソニックシンガポール研究所ブロック1022、タイセン工業団地の＃06から3530まで、タイセンアベニューシンガポール534 415シンガポール
Phone: +65 6550 5447 EMail: hong.cheng@sg.panasonic.com
電話：+65 6550 5447 Eメール：hong.cheng@sg.panasonic.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。