[要約] RFC 4564は、CAPWAP(Control and Provisioning of Wireless Access Points)の目的と要件を定義しています。CAPWAPは、無線アクセスポイントの制御と設定を効率的に行うためのプロトコルです。このRFCの目的は、CAPWAPの機能と要件を明確にし、無線ネットワークの管理を簡素化することです。

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)

ワイヤレスアクセスポイントの制御とプロビジョニングの目的(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).

Copyright(c)The Internet Society(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
        
1. Introduction
1. はじめに

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)を管理する複雑さがあります。これは、設計の変動によってさらに悪化しています。もう1つの課題は、システムの多数のwtps間の一貫した構成のメンテナンスです。ワイヤレスメディアの動的な性質も、WLANセキュリティとともに懸念事項です。[RFC3990]では、大規模なWLAN展開に影響を与える課題が強調されています。

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プロトコルでのこれらの目的の実現により、主要な設計タイプのWLAN機器が統合的に展開および管理されることが保証されます。

2. Terminology
2. 用語

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の側面。ワイヤレスメディアセグメントは、IEEE 802.11などのレイヤー2ワイヤレステクノロジーに固有です。

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フレームワーク:集中型WLANアーキテクチャのローカルMACおよびスプリット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間のプロトコル。相互運用可能な方法でWTPの制御、管理、およびプロビジョニングを促進します。

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が多くの論理グループを動作させます。仮想アクセスポイント(APS)は、論理グループの例です。ここでは、各基本サービスセット識別子(BSSID)および構成ワイヤレス端子のラジオは、物理WTPの異なる論理グループとして示されます。論理グループは、CAPWAPの目的、特に「ワイヤレスターミナル透明性」目標と矛盾することなく維持されます。

3. Requirements Notation
3. 要件表記

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

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

4. Objectives Overview
4. 目的の概要

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プロトコル仕様の全体的な影響に関連する目的に一般的な分類が使用されます。

5. Objectives
5. 目的

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

i. 必須および受け入れられた目標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. オペレーターの要件

5.1. Mandatory and Accepted Objectives
5.1. 必須および受け入れられた目標

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.

必須および受け入れられたものとして優先される目標は、WTPの制御とプロビジョニングに重要であるとみなされています。彼らは、大規模なWLAN展開の課題に直接対処し、CapWapプロトコルによって実現する必要があります。

5.1.1. Logical Groups
5.1.1. 論理グループ

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展開は、これらの2つの大規模WLANの問題に対処するためにますます使用されています。これらは、展開と管理コストを企業全体に広めることを許可するため、人気があります。

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システムの1つの完全なサブセットを表します。共有WLANは、各物理WTPが、おそらく多数のより大きなWLANシステムの多くの論理サブセットを表しているという点で異なります。物理WTPの各論理分割は、論理グループと呼ばれます(セクション2の定義を参照)。したがって、WLANは、物理WTPの代わりに論理グループの観点から管理されます。論理グループは、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ベースのグループを含む論理グループの観点から物理WTPを制御および管理できる必要があります。

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の展開を共有することで削減されます。その結果、展開と管理の費用効果が実現されます。

5.1.2. Support for Traffic Separation
5.1.2. 交通分離のサポート

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.

さらに、この要件は、リモートに配置されたWTPSが、WLANコントローラーに幅広いネットワークを越えて転送する必要なく、代替方法でデータトラフィックを処理するのに役立ちます。

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.

概して、この目的は、大規模なWLANの複雑さを管理するという課題に関連しています。トラフィック分離の要件は、これがデータ輸送のタスクから分離されているため、制御を簡素化します。

5.1.3. Wireless Terminal Transparency
5.1.3. ワイヤレス端子透明性

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.

問題のステートメントは、多くのWTPで構成される大きなWLANが直面する課題を強調しています。それはワイヤレスターミナルの操作を指すのではなく、この目的は独立性を強調しています。

5.1.4. Configuration Consistency
5.1.4. 構成の一貫性

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には多数のWTPが含まれており、それぞれが一貫した方法で構成および管理する必要があります。一貫性を確保する上での主な関心事は、WTP構成状態に対応する適切な情報の可用性です。したがって、集中型WLANコントローラーにWTP操作の状態に関する定期的な更新を提供することにより、構成の一貫性を実現できます。集中化された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.

問題のステートメントで説明されている主要な課題の1つは、WLANの多数のWTP全体で一貫した構成を維持することです。この目的は、この背後にある基本的な問題、つまりタイムリーな状態情報の可用性に対処しています。

5.1.5. Firmware Trigger
5.1.5. ファームウェアトリガー

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.

構成一貫性の特定の側面の1つは、さまざまなWTPで使用されるファームウェアです。大規模なWLANのスケールは、WTPS間で使用されるファームウェアのバリエーションの可能性を導入します。この目的は、CAPWAPプロトコルが適切なバージョンのファームウェアのWTPSへの配信をトリガーする必要性を強調しています。ファームウェアの実際の配信は、プロトコルに包括的である必要はありません。

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コントローラーに多くのWTPをインターフェースします。ファームウェアの配布により、これらのインターフェイスが互換性があります。これにより、一貫した構成と簡素化された管理が得られます。したがって、プロトコルは、ファームウェアの更新の配布のためのトリガーを含めることによる利点があります。

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.

WTPの構成における不一致は、大規模なWTPの主要な課題として特定されています。この目的は、CAPWAPプロトコルがすべてのWTP間で互換性のあるファームウェアアップデートの提供を開始する方法を提供することにより、課題を克服するのに役立ちます。

5.1.6. Monitoring and Exchange of System-wide Resource State
5.1.6. システム全体のリソース状態の監視と交換

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とワイヤレスメディアの動的な性質を扱うという課題を強調しています。WTPと媒体の状態に関する情報は、効果的にそれらに対処するために重要です。したがって、この目的は、大規模なWLANの一貫性を管理する問題に関連しています。

5.1.7. Resource Control Objective
5.1.7. リソース制御の目的

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を強調しています。2つの間に根本的な違いを考えると、WTPSとワイヤレスサービス加入者とWTPSとWLANコントローラーの間に代替のQoSメカニズムがある可能性があります。たとえば、前者はIEEE 802.11eに基づいていますが、後者は代替品になります。そのため、リソースは両方のセグメントで調整された方法で調整する必要があります。CAPWAPプロトコルは、これらの調整がWLANコントローラーとWTP間で適切に交換されるようにする必要があります。

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プロトコルは、IEEE 802.11e QoS優先順位を、スイッチングおよびワイヤレス中程度のセグメント全体で同等の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アスペクトに対処するプロトコルは、高性能を提供し、サブスクライバーやリソース利用効率に有益です。CapWapはWTPSを直接扱っており、ワイヤレスメディアを間接的に扱うため、これらは両方ともパフォーマンスを検討する必要があります。

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制御は大規模なWLANにとって重要であり、多くの側面に関連しています。特に、この目的は、ワイヤレス媒体の動的条件を管理する問題に対処するのに役立ちます。

Furthermore, traffic characteristics in large-scale WLANs are constantly varying. So network utilization becomes inefficient, and user experience is unpredictable.

さらに、大規模なWLANのトラフィック特性は絶えず変化しています。したがって、ネットワークの使用率は非効率的になり、ユーザーエクスペリエンスは予測できません。

The interaction and coordination between the two aspects of system-wide QoS are therefore critical for performance.

したがって、システム全体のQoSの2つの側面間の相互作用と調整は、パフォーマンスにとって重要です。

5.1.8. CAPWAP Protocol Security
5.1.8. CAPWAPプロトコルセキュリティ

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.

CAPWAPプロトコルは、最初に参加エンティティ(WLANコントローラーとWTPS)を明示的に相互に認証するために提供する必要があります。これは、不正な要素がWLANシステムにアクセスできないことを確認するためです。Rogue WTPSが正当なWLANに違反することを許可されるべきではなく、同時にRogue WLANコントローラーが正当なWTPの制御を獲得することを許可されるべきではありません。たとえば、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プロトコルは、WTPと集中コントローラーの相互認証をサポートする必要があります。また、情報交換が整合性保護されていることを確認し、暗号化を通じて機密性を確保する必要があります。

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システムにアクセスするためにRogue WTPSによって活用される可能性があります。また、Rogue WLANコントローラーによって使用されて、合法的なWTPとそれに関連する端子の制御を獲得して、端子トラフィックをリダイレクトまたは妥協することもできます。これらのセキュリティの懸念は、この目的で軽減できます。

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.

大規模なWLANのセキュリティ問題は、問題ステートメントで詳しく説明されています。これらには、不正なWTPSから生じる合併症やWTPSとWLANコントローラーの間の侵害された界面が含まれます。プロトコルセキュリティの要件はこれらの問題に対処し、それらから保護することの重要性を強調しています。

5.1.9. System-wide Security
5.1.9. システム全体のセキュリティ

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セグメントの外部にあるセキュリティの脅威にあります。したがって、焦点は、Rogue Wireless Clientsやその他の非合法的なワイヤレス干渉にあります。CapWapフレームワーク内で対処する必要がある特定の外部の脅威がいくつかあります。

i. PMK Sharing

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

この目的の1つの側面は、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フレームワークの外部側面を表しています。システム全体のセキュリティ目標は、問題の声明に関連してそのような脅威に対処しています。

5.1.10. IEEE 802.11i Considerations
5.1.10. IEEE 802.11i考慮事項

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アーキテクチャの認証をサポートする必要があります。アーキテクチャの分類法は、ローカルMACとスプリットMACデザインの両方で多くのバリアントを示しています。ここでは、認証器がWLANコントローラーにあり、暗号化ポイントがWTPSにあります。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).

この場合に考慮すべき重要な問題は、認証機と暗号化ポイントが異なるエンティティに配置されている場合の重要な情報の交換です。たとえば、IEEE 802.11iがWLANコントローラーが認証器を実現するWLANで使用され、一部のWTPが暗号化(おそらくローカルMAC WTPS)を実現し、他のWTPが暗号化のためにWLANコントローラーに依存している場合を考えてみましょう(おそらく分割 - 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構成の一部になるでしょう。その後、暗号化を実現するWTPは、WLANコントローラーの認証者とキー情報を交換するためにCapWapが必要になります。暗号化を実現しないWTPの場合、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と比較して、認証メカニズムのための異なるプラットフォームを提示します。したがって、この目的は、CapWapが集中化されたWLANアーキテクチャの認証と主要な管理をサポートする必要性を強調しています。

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、Universal Access Method(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プロトコル内で対応する必要があります。

5.1.11. Interoperability Objective
5.1.11. 相互運用性の目的

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アーキテクチャの2つの主要な設計は、ローカル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アーキテクチャ設計の両方のWTPが単一のWLAN内で相互運用できるようにすることです。その結果、単一のWLANコントローラーは、単一のCapWapプロトコルを使用して両方のタイプのWTPを制御できます。これらの設計の積分サポートは、多くのプロトコルの側面を含みます。

i. Capability negotiations between WLAN controller and WTPs

i. 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機能の程度が異なります。Split-MacとLocal-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.

最初のステップとして、このような交渉は、それぞれの機能に関する実質的な情報を提供するため、WTP、Split-MAC、またはLocal-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.

異なるWTP間の機能の違いは、本質的に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プロトコルには、主要なタイプのWTPを区別するのに十分な機能交渉を含める必要があります。

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展開の課題に対処する包括的なメカニズムセットの開発が保証されます。

5.1.12. Protocol Specifications
5.1.12. プロトコル仕様

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.

WLAN機器ベンダーがCAPWAPプロトコルの実装中に単一の仕様を参照することが有益です。これにより、開発プロセスを容易にし、迅速化するのに役立ちます。

Relation to Problem Statement:

問題の声明との関係:

This requirement is based on WG discussions that have been determined to be important for CAPWAP.

この要件は、CapWapにとって重要であると判断されたWGの議論に基づいています。

5.1.13. Vendor Independence
5.1.13. ベンダー独立

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コントローラーとWTPの開発は独立して行われます。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の議論に基づいています。

5.1.14. Vendor Flexibility
5.1.14. ベンダーの柔軟性

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ベンダーを制限してはなりません。両方のタイプのWTPと互換性がなければなりません。

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の議論に基づいています。

5.1.15. NAT Traversal
5.1.15. ナットトラバーサル

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と、ネットワークアドレス翻訳者(NAT)を介して通信するWLANコントローラーが含まれる場合があります。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.

WLANの広範な採用は、NATを含むWLANトポロジの可能性を高めます。CAPWAPプロトコルがこのようなトポロジ内に適用できることが重要です。この要件は、CapWapプロトコルをNATトラバーサルに関連させることを目的としています。

Relation to Problem Statement:

問題の声明との関係:

This requirement is based on WG discussions that have been determined to be important for CAPWAP.

この要件は、CapWapにとって重要であると判断されたWGの議論に基づいています。

5.2. Desirable Objectives
5.2. 望ましい目的

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の制御を改善するのに役立つかもしれませんが、すべてのネットワークやシナリオに必ずしも必要ではありません。

5.2.1. Multiple Authentication Mechanisms
5.2.1. 複数の認証メカニズム

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をサポートする必要がありますが、他の認証メカニズムをサポートすることも必要です。たとえば、1つの論理グループはIEEE 802.11iを使用する場合がありますが、別の論理グループはWeb認証を使用できます。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展開は、大規模なネットワークの管理を簡素化します。

5.2.2. Support for Future Wireless Technologies
5.2.2. 将来のワイヤレステクノロジーのサポート

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プロトコルが進歩を反映し、それらをサポートできるフレームワークを提供することが重要です。

5.2.3. Support for New IEEE Requirements
5.2.3. 新しいIEEE要件のサポート

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 Ad-Hoc委員会は、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内で多くの進歩があります。これは、今日使用されている主要なワイヤレステクノロジーの1つであるため、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プロトコルがこれらの定義と拡張機能を反映する必要があります。

5.2.4. Interconnection Objective
5.2.4. 相互接続の目的

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プロトコルの主な目的は、さまざまなWTPおよび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を構成する複雑さについて説明しています。大規模な展開に利用可能な相互接続技術の選択は、この複雑さをさらに強化します。この要件は、基礎となる輸送からのプロトコルの運用上の側面の独立性を提唱することにより、複雑さの一部を回避します。

5.2.5. Access Control
5.2.5. アクセス制御

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

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

ワイヤレスクライアントのアクセスを制御することに加えて、新しいWTPの入場を制御することも必要です。Rogue WTPSの脅威を考えると、CAPWAPが新しいWTPSとWLANコントローラーの間で適切な認証情報を中継することが重要です。

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.

この目的は、大規模なWLANのアクセス制御の問題に対処します。概して、このようなネットワークの複雑さスケールを管理する問題に関連しています。切り替えとワイヤレス中程度のセグメントの両方の集合的な情報により、この目的を実現することは、複雑さを制御および管理するのに役立ちます。

5.3. Non-Objectives
5.3. 非目的

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とその考慮事項の文脈で優先順位を付けられています。ただし、代替コンテキストで適用できる場合があります。

5.3.1. Support for Non-CAPWAP WTPs
5.3.1. 非capwap wtpsのサポート

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コントローラーに他のエンティティによって行われた変更を通知する場合があります。

Protocol Requirement:

プロトコル要件:

The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and existing network management systems.

CAPWAPプロトコルは、レガシーWTPおよび既存のネットワーク管理システムを認識できる必要があります。

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.

問題ステートメントは、大規模なWLANの主要な問題として、管理の複雑さを強調しています。この複雑さの一部は、この目的が適用される集中WLANデバイスの増分展開に関連する可能性があります。

5.3.2. Technical Specifications
5.3.2. 技術仕様

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.

WLAN機器ベンダーがCAPWAPプロトコルの実装中に単一の仕様を参照することが有益です。これにより、開発プロセスを容易にし、迅速化するのに役立ちます。

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

5.4. Operator Requirements
5.4. オペレーターの要件

The following objectives have been provided by network service operators. They represent the requirements from those ultimately deploying the CAPWAP protocol in their WLANs.

次の目的は、ネットワークサービスオペレーターによって提供されています。それらは、最終的にWLANにCapWapプロトコルを展開する人々からの要件を表しています。

5.4.1. AP Fast Handoff
5.4.1. AP高速ハンドオフ

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ファーストハンドオフ手順の有効性を妨害または妨害してはなりません。

6. Summary and Conclusion
6. 要約と結論

The objectives presented in this document address three main aspects of the CAPWAP protocol, namely:

このドキュメントに示されている目的は、CapWapプロトコルの3つの主要な側面を扱っています。

i. Architecture ii. Operations iii. Security

i. アーキテクチャ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.

さらに、このドキュメントには、大規模なWLANの運用経験に基づいて導出されたネットワークサービスオペレーターからの要件が含まれています。

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.

このドキュメントからの結果の要件は、CAPWAP問題ステートメント[RFC3990]およびCAPWAPアーキテクチャ分類法[RFC4118]と組み合わせて使用され、大規模なWLANでのWTPの制御と提供のための相互運用可能なプロトコルを開発および評価します。

7. Security Considerations
7. セキュリティに関する考慮事項

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 WTPの両方のサポートを強調しています。両方のタイプのWTPが使用される展開では、それぞれがその機能を考慮して保護されることを保証することが重要です。アーキテクチャ分類法は、さまざまなWTPがさまざまなレベルの機能をどのように組み込むかを示しています。CAPWAPプロトコルの開発では、単一のWLAN内のローカルMACとスプリットMAC WTPの両方の展開が、セキュリティ妥協のために抜け穴を提示しないようにする必要があります。

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がWTPで共有される実装が可能になります。これにより、合法的な共有と違法なコピーの間の曖昧さが高まります。ワイヤレスターミナルは、この曖昧さの餌食または悪用されることを知らずに落下する可能性があります。この問題の解決は、現在、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.

WLANで攻撃を開始する低コストにより、CapWapプロトコルはターゲットになります。あらゆる形態の攻撃に対して確保する最初のステップは、Rogue WTPSまたはワイヤレス端子からの潜在的な脅威の条件についてWLANを継続的に監視することです。たとえば、セキュリティ条件を効果的に監視するために、CAPWAPプロトコルのDOSおよびリプレイ攻撃のプロファイルを考慮する必要があります。

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コントローラーの間の非対称の非単位認証を考慮すると、そのような取り決めを悪用する不正な参加者のリスクがあります。非自然な認証を避けることが望ましいです。場合によっては、プロトコル交換参加者の正当性は、たとえば、密接な環境内での物理的封じ込めによって、外部から検証される場合があります。ここでは、セキュリティの妥協のリスクなしに、非対称認証が適切かもしれません。

8. Acknowledgements
8. 謝辞

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.

著者は、この文書への支援と忍耐について、ワーキンググループの椅子であるドロシー・ゲラートとマハリンガム・マニに感謝したいと思います。また、目的の形成を支援してくれたワーキンググループの参加者に感謝したいと思います。特に、著者は、James Kempf、Pat Calhoun、Inderpreet Singh、Dan Harkins、T。Sridhar、Charles Clancy、Emek Sadotの貴重な入力に感謝します。また、文書の評価にIEEE 802.11アドホック委員会に感謝します。著者はまた、Meimei Dang、Satoshi Iino、Mikihito Sugiura、およびDong Wangからの貢献を認めています。

9. Normative References
9. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] O'Hara、B.、Calhoun、P。、およびJ. Kempf、「ワイヤレスアクセスポイント(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] Yang、L.、Zerfos、P。、およびE. Sadot、「ワイヤレスアクセスポイント(CAPWAP)の制御とプロビジョニングのためのアーキテクチャ分類法」、RFC 4118、2005年6月。

10. Informative References
10. 参考引用

[802.11] IEEE Standard 802.11, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", June 2003.

[802.11] IEEE Standard 802.11、「ワイヤレスLANメディアアクセス制御(MAC)および物理層(PHY)仕様」、2003年6月。

[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC) Security Enhancements", July 2004.

[802.11i] IEEE Standard 802.11i、「Medium Access Control(Mac)セキュリティ強化」、2004年7月。

[802.11e] IEEE Standard 802.11e, "Medium Access Control (MAC) Quality of Service Enhancements", November 2005.

[802.11e] IEEE Standard 802.11e、「Medium Access Control(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 Govindan Panasonic Singapore Laboratories Block 1022、Tai Seng Industrial Estate#06-3530、Tai Seng Avenue Singapore 534 415シンガポール

   Phone: +65 6550 5441
   EMail: saravanan.govindan@sg.panasonic.com
        

Zhonghui Yao Huawei Longgang Production Base Shenzhen 518 129 P. R. China

Zhonghui Yao Huawei Longgang Production Base Shenzhen 518 129 P. R. China

   Phone: +86 755 2878 0808
   EMail: yaoth@huawei.com
        

Wenhui Zhou China Mobile 53A, Xibianmen Ave, Xuanwu District Beijing 100 053 P. R. China

Wenhui Zhou China Mobile 53a、Xibianmen Ave、Xuanwu District Beijing 100 053 P. R. China

   Phone: +86 10 6600 6688 ext.3061
   EMail: zhouwenhui@chinamobile.com
        

L. Lily Yang Intel Corp. JF3-206, 2111 NE 25th Ave. Hilsboro, OR 97124 USA

L. Lily Yang Intel Corp. JF3-206、2111 Ne 25th Ave. Hillsboro、または97124 USA

Phone: +1 503 264 8813 EMail: 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

電話:1 503 264 8813メール:lily.L.Yang@intel.com Hong Cheng Panasonic Singapore Laboratories Block 1022、Tai Seng Industrial Estate#06-3530、Tai Seng Avenue Singapore 534 415シンガポール

   Phone: +65 6550 5447
   EMail: hong.cheng@sg.panasonic.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2006).

Copyright(c)The Internet Society(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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポートアクティビティ(IASA)によって提供されます。