RFC4564 日本語訳
4564 Objectives for Control and Provisioning of Wireless Access Points(CAPWAP). S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. July 2006. (Format: TXT=64576 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループS.Govindan、エドをネットワークでつないでください。コメントのために以下を要求してください。 4564時間チェンCategory: 情報のパナソニックZH。 八尾Huawei WH。 L.陽のインテル2006年7月のモバイルの中国の周
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)インターネット協会(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.
このドキュメントはWireless Access Points(CAPWAP)のControlとProvisioningにおいて、共同利用できるプロトコルのために目的を提示します。 ドキュメントは、開発のための1セットの集中している要件とCAPWAPプロトコルの評価を確立することを目指します。 目的は設計代案のWirelessローカル・エリア・ネットワーク(WLAN)デバイスの中で相互運用性を可能にするのに必要な要件をアーキテクチャ、操作、セキュリティ、およびネットワーク・オペレータに扱います。
Govindan, et al. Informational [Page 1] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [1ページ]情報のRFC4564CAPWAP目的2006年7月
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. 序論…3 2. 用語…3 3. 要件記法…4 4. 目的概要…4 5. 目的…5 5.1. 義務的で受け入れられた目的…5 5.1.1. 論理的なグループ…5 5.1.2. トラフィックには、分離をサポートしてください…6 5.1.3. ワイヤレスの端末の透明…8 5.1.4. 構成の一貫性…8 5.1.5. ファームウェア引き金…9 5.1.6. システム全体のリソース状態のモニターと交換…10 5.1.7. リソースコントロール目標…11 5.1.8. CAPWAPはセキュリティについて議定書の中で述べます…12 5.1.9. システム全体のセキュリティ…14 5.1.10. IEEE 802.11i問題…15 5.1.11. 相互運用性目的…17 5.1.12. 仕様を議定書の中で述べてください…18 5.1.13. ベンダー独立…19 5.1.14. ベンダーの柔軟性…19 5.1.15. NAT縦断…20 5.2. 望ましい目的…21 5.2.1. 複数の認証メカニズム…21 5.2.2. 将来の無線技術のために、サポートします。21 5.2.3. 新しいIEEEには、要件をサポートしてください…22 5.2.4. インタコネクト目的…23 5.2.5. コントロールにアクセスしてください…24 5.3. 非目的…25 5.3.1. 非CAPWAP WTPsのために、サポートします。25 5.3.2. 技術的な仕様…26 5.4. オペレータ要件…27 5.4.1. APの速い移管…27 6. 概要と結論…27 7. セキュリティ問題…28 8. 承認…29 9. 標準の参照…29 10. 有益な参照…29
Govindan, et al. Informational [Page 2] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [2ページ]情報のRFC4564CAPWAP目的2006年7月
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].
大規模なWirelessローカル・エリア・ネットワーク(WLAN)展開における成長は多くの技術的難関を焦点にもたらしました。 それらの中に、それらのデザインの変化によってさらに悪化させられる多くのWireless Termination Points(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.
多くのベンダーが展開している新しいアーキテクチャとソリューションでこれらの挑戦を扱いました。 様々な開発の調査は、これらの文脈が挑戦するのをより理解するために指導されました。 ソリューションの中で相互運用性を設計することに向かったこの調査は第一歩です。 Architecture Taxonomy[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.
Architecture Taxonomyは、集結された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は集結されたWLAN Architectureを基礎づけました[RFC4118]。
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.
セグメントを切り換えます: 主としてWireless Termination Points(WTPs)とWLANコントローラの間のコントロールとデータ情報の切り換えかルーティングに対処する集結されたWLANのそれらの局面。
Govindan, et al. Informational [Page 3] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [3ページ]情報のRFC4564CAPWAP目的2006年7月
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.
ワイヤレスの中型のセグメント: 主としてワイヤレスに対処する集結されたWLANのそれらの局面がWTPsとワイヤレスの端末の間で連結します。 Wireless Medium Segmentは、IEEE802.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フレームワーク: Centralized WLAN Architectureの地方の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の間のプロトコル。 それは共同利用できる方法における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は多くの論理的なグループを経営するでしょう。 仮想のアクセスポイント(APs)は論理的なグループに関する例です。 ここで、各Basic Service Set Identifier(BSSID)と構成しているワイヤレスの端末のラジオは物理的なWTPの異なった論理的なグループとして指示されます。 CAPWAP目的、特に'ワイヤレスのTerminal Transparency'目的と衝突しないで、論理的なグループは維持されます。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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モニターに関連する操作、資源管理、Service(QoS)のQuality、およびアクセスコントロールと取り引きします。
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.
セキュリティ目的はWLANsと彼らの封じ込めへの潜在的な脅威を扱います。 CAPWAP文脈では、セキュリティ要件はWLANコントローラとWTPsの間のプロトコルと全体でWLANシステムも含んでいます。
Govindan, et al. Informational [Page 4] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [4ページ]情報のRFC4564CAPWAP目的2006年7月
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。 義務的である、そして、Accepted Objectives ii。 望ましいObjectives 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.
その上、ネットワーク・サービスオペレータから集められた要件に基づいて目的の異なったカテゴリを提供します。 これらは大規模なWLANsを配布して、管理するオペレータの経験から起こる特定の必要性です。
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.
義務的で受け入れられるとして最優先する目的はWTPsのコントロールと食糧を供給するのに重要であると考えられました。 それらを直接大規模な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展開は、大規模なWLANsのこれらの2冊を扱うのにますますただ一つの物理的なWLANインフラストラクチャが多くの論理的なネットワークをサポートするところで使用されます。 彼らが、展開と管理コストがビジネスの向こう側に広げられるのを許すとき、これらはポピュラーです。
Govindan, et al. Informational [Page 5] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [5ページ]情報のRFC4564CAPWAP目的2006年7月
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.
伝統的なWLANsでは、それぞれの物理的なWTPは、より大きいWLANシステムの1つの完全な部分集合を表します。 共有されたWLANsはそれぞれの物理的なWTPが多くのことによると多くの、より大きいWLANシステムの論理的な部分集合を表すという点において異なります。物理的なWTPのそれぞれの論理的な分割は論理的なグループと呼ばれます(セクション2との定義を見てください)。 それで、WLANsは物理的なWTPsの代わりに論理的なグループで管理されます。 論理的なグループは仮想のAPsのBSSIDsと他のタイプに基づいています。
Protocol Requirement:
要件について議定書の中で述べてください:
The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups.
BSSIDを拠点とするグループを含む論理的なグループに関して、物理的なWTPsを制御して、CAPWAPプロトコルは管理できなければなりません。
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が地方のブリッジすることを実行するそれらとAccess Controller(西暦)が働くそれらを含んでいると、ブリッジすることは集中しました、とプロトコルが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.
商業現実はそのWLANsを必要とします。彼らの論理的なグループでは、処理しやすくいてください。 これは論理的なサービスと基本的なインフラ管理の分離を許容します。 この必要性がわかるプロトコルは、より簡単で費用対効果に優れたWLANsを確実にします。(直接、WLANsはネットワーク・サービスオペレータの要件を扱います)。
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
集結されたWLANアーキテクチャは主要なWLANコントローラでのワイヤレスのMACの機能性の部分を統合するのによる大規模な展開とWTPsの向こう側に残りを分配すると関連している複雑さを簡素化します。 その結果、WTPsとWLANコントローラは彼らの間でコントロールとデータ情報を交換します。 この目的
Govindan, et al. Informational [Page 6] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [6ページ]情報のRFC4564CAPWAP目的2006年7月
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.
交換のコントロールとデータ局面がさらなる簡単さのために互いに切り離されると述べます。 これは、それぞれのタイプの交換が独自に最適化されるためにソリューションを許容するでしょう。
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展開の文脈では、コントロールとデータの互いの分離は、セキュリティが関心であると扱います。 異なった管理者によって管理されて、異なった仮想のAPsによって設立されたものなどの異なった論理的なグループの見込みを考えて、個別に論理的なグループを含んでいて、保証することに向かったコントロールとデータの分離は特に、第一歩です。
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.
広く、この目的は大規模なWLANsで管理の挑戦に複雑さを関係づけます。 これがデータ伝送に関するタスクと切り離されるのに応じて、トラフィック分離のための要件はコントロールを簡素化します。
Govindan, et al. Informational [Page 7] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [7ページ]情報のRFC4564CAPWAP目的2006年7月
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.
Problem Statementは多くのWTPsから成る大きいWLANsによって直面されていた難局を強調します。 それはワイヤレスの端末の操作について言及しません、そして、この目的は独立を強調します。
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フレームワークにおけるWLANsは一貫した方法で構成されて、管理されるのが彼らのそれぞれが必要であることである多数のWTPsを含んでいます。 一貫性があることを保証することにおける主な関心事はWTP構成州に対応する適切な情報の有用性です。 それで、WTP操作の状態に関する定期的な最新情報を集結されたWLANコントローラに提供することによって、構成の一貫性を獲得できます。 集結されたWLANコントローラはWTPsの中で一貫して確実にする定期的なアップデートから情報を順番に適用できます。
Govindan, et al. Informational [Page 8] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [8ページ]情報のRFC4564CAPWAP目的2006年7月
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.
Problem Statementで説明された主要な挑戦の1つはWLANの多数のWTPsの向こう側に一貫した構成を維持するものです。 この目的はこれの後ろで基本的な問題を扱います--タイムリーな州の情報の有用性。
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つの特定の局面が様々なWTPsによって使用されたファームウェアです。 大きいWLANsのスケールは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コントローラに多くのインタフェースWTPsについて議定書の中で述べます。 ファームウェア分配は、これらのインタフェースが互換性があるのを許容します。 これは順番に一貫した構成と簡易型の管理をもたらします。 それで、プロトコルは、ファームウェアのアップデートの分配のための引き金を含んでいることによって、利益を得ます。
Govindan, et al. Informational [Page 9] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [9ページ]情報のRFC4564CAPWAP目的2006年7月
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に、主要な挑戦として特定されました。 この目的は、CAPWAPプロトコルがすべてのWTPsの中で互換性があるファームウェアのアップデートの配送を開始する方法を提供することによって挑戦に打ち勝つのを助けます。
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プロトコルに提供できます。
Govindan, et al. Informational [Page 10] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [10ページ]情報のRFC4564CAPWAP目的2006年7月
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.
Problem Statementは多くのWTPsとワイヤレスの媒体のダイナミックな本質に対処する挑戦を強調します。 WTPsと媒体の状態に関する情報は、有効に彼らに対応するために重要です。 それで、この目的は大きいWLANsの一貫性を管理するという問題に関連します。
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のベースのWLANsが切り換えセグメントとワイヤレスの中型のセグメントを結合するので、性能と品質は、これらのセグメントの両方の向こう側に調整される必要があります。 それで、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コントローラと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に加えて、ネットワーク資源に影響するかもしれない多くの他のIEEE802.11任務群があります。 これらは現在進行しているIEEE802.11TGk、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プライオリティを写像しなければなりません。
Govindan, et al. Informational [Page 11] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [11ページ]情報のRFC4564CAPWAP目的2006年7月
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.
QoSがWLANシステムの局面であると扱うプロトコルは、加入者とリソース利用効率に有益であるので、その結果高性能であるのを提供するでしょう。 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コントロールは、大きいWLANsに重要であり、多くの局面に関連します。 特に、この目的は、ワイヤレスの媒体のダイナミックな状態を管理するというその問題を訴えるのを助けることができます。
Furthermore, traffic characteristics in large-scale WLANs are constantly varying. So network utilization becomes inefficient, and user experience is unpredictable.
その上、大規模なWLANsのトラフィックの特性は絶えず異なっています。 それで、ネットワーク利用は効率が悪くなります、そして、ユーザー・エクスペリエンスは予測できません。
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システムへのアクセスを得ないのを保証するためのものです。 凶暴なWTPsは正統のWLANsを破るのを許容するべきでなくて、同じ時間悪党WLANコントローラで正統のWTPsのコントロールを獲得するはずであることができません。 例えば、WTPsは、WLANコントローラのためにWLANコントローラと共に彼らの認証状態を定期的に同様に更新する必要があるかもしれません。
Govindan, et al. Informational [Page 12] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [12ページ]情報のRFC4564CAPWAP目的2006年7月
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の間で使用されるどんなセッションキーも引き出さなければなりません。 これは、いいえ1、パーティーが結果として起こるセッションキーを管理するのを確実にします。
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プロトコルは保全保護と反復操作による保護を提供しなければなりません。 プロトコルSHOULDは暗号化で秘密性を提供します。 これは、他の潜在的感染の中で交換、盗聴、およびサービス妨害(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 MUST NOTは非対称の認証の使用を防ぎます。 そのような非対称の認証のセキュリティ問題はSecurity Considerations部で説明されます。
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プロトコルがBCP107[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の互いの認証と集結されたコントローラを支えなければなりません。 また、それは、情報交換が保護された保全であり、SHOULDが暗号化で秘密性を確実にするのを確実にしなければなりません。
Govindan, et al. Informational [Page 13] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [13ページ]情報のRFC4564CAPWAP目的2006年7月
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.
WLANsはますます企業と消費者ネットワークのきわどい局面で配布されます。 これらの文脈では、プロトコルセキュリティは、ネットワーク管理者とエンドユーザから予想されたプライバシーと保全を確実にするために重要です。 それで、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によって利用されるかもしれません。 また、凶暴なWLANコントローラは、端末のトラフィックに向け直すか、または感染するために正統のWTPsと彼らの関連端末のコントロールを獲得するのにそれらを使用できました。 この目的でこれらの安全上の配慮を緩和できます。
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.
大規模なWLANsの警備上の問題はProblem Statementで詳細です。 これらはWTPsとWLANコントローラの間で凶暴なWTPsから起こって、インタフェースに感染する複雑さを含んでいます。 プロトコルセキュリティのための要件は、これらのその問題を訴えて、それらから守る重要性を強調します。
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セグメントへの外部の軍事的脅威にはこの目的の強調があります。 したがって、凶暴なワイヤレスのクライアントと他の違法なワイヤレスの干渉には焦点があります。 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フレームワークを分担しながら、Pairwise Master Key(PMK)についての最近の議論に関連します。 この目的は凶暴なワイヤレスのクライアントでこのあいまいさの攻略を防ぐ必要性を強調します。 それは、CAPWAPフレームワークから起こるどんなあいまいさも機密保護違反の原因でないことを保証することになっています。
Govindan, et al. Informational [Page 14] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [14ページ]情報のRFC4564CAPWAP目的2006年7月
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.
この目的はProblem Statementで強調された安全要求に基づいています。 明確に、Problem Statementは共有されたワイヤレスの媒体の効果について検討します。 これはある脅威が起こることができるCAPWAPフレームワークの外面を表します。 システム全体のセキュリティ目的はProblem Statementと関連してそのような脅威を扱います。
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コントローラに位置できる集結されたWLANアーキテクチャかWTPで認証をサポートしなければなりません。 Architecture Taxonomyは多くの異形を例証します、ローカルの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).
この場合考える切迫した課題は固有識別文字と暗号化ポイントがいつ別個の物に位置しているかという主要な情報の交換です。 いくつかのWTPsが暗号化(ことによると地方のMAC WTPs)がわかります、そして、例えば、IEEE 802.11iがWLANコントローラが固有識別文字がわかるWLANで使用されるケースを考えてください、そして、他のWTPsは暗号化(ことによると分裂-MAC WTPs)のためにWLANコントローラを当てにします。
Govindan, et al. Informational [Page 15] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [15ページ]情報のRFC4564CAPWAP目的2006年7月
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は、CAPWAPがWLANコントローラで主要な情報を固有識別文字と交換する必要があるでしょう。 暗号化がわからない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.
明確に、WTPが固有識別文字と暗号化の役割の両方がわかったレガシーWLANsと比べて、集結された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ベースのWLANsであるとサポートするところにあります。 そういうものとして、IEEE 802.11i固有識別文字と暗号化ポイントに関してWLANデザインにおける主要な区別を認識するのがプロトコルに必要です。 これはArchitecture Taxonomyで強調された重要な変化を表します。 CAPWAPプロトコルは、IEEE 802.11iからそのような主要な考慮を収容することによって、利益を得ます。
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.
Problem Statementは異なったWTPデザインの有用性とそれらの中で相互運用性を確実にする必要性を目立たせます。 この点で、IEEE 802.11i固有識別文字と暗号化ポイントの分離のため起こる操作上の変化は、CAPWAPプロトコルの中に収容される必要があります。
Govindan, et al. Informational [Page 16] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [16ページ]情報のRFC4564CAPWAP目的2006年7月
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つのデザインへの標準化取り組みの集中によって、それらの中で互いのinteroperationを確実にするのは重要です。
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の中でinteroperationができるのを保証することです。 その結果、独身のWLANコントローラは、ただ一つのCAPWAPプロトコルを使用することでWTPsの両方のタイプを監督することができるでしょう。 これらのデザインの不可欠のサポートは多くのプロトコル局面を包括します。
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デザインはIEEE802.11の度合いにおいて異なります。WTPの各タイプがわかる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.
第一歩として、そのような交渉は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.
機能性の、よりすばらしい粒状に関するこれらのインタフェースの定義はIEEE802.11AP Functionality(APF)アド・ホック委員会によって製作されたAP機能性ドキュメントに基づくでしょう。
Protocol Requirement:
要件について議定書の中で述べてください:
The CAPWAP protocol MUST include sufficient capabilities negotiations to distinguish between major types of WTPs.
CAPWAPプロトコルはWTPsの主要なタイプを見分けることができるくらいの能力交渉を含まなければなりません。
Govindan, et al. Informational [Page 17] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [17ページ]情報のRFC4564CAPWAP目的2006年7月
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アーキテクチャデザインの制御機能にはかなりのオーバラップがあります。 Architecture Taxonomyは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の両方をサポートするための目的はProblem Statementを扱うのに基本的です。 それはそれらの問題が主要な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プロトコルを実装することができなければなりません、そして、それによってそのようなすべての実装が共同利用するのが必要とされます。
Govindan, et al. Informational [Page 18] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [18ページ]情報のRFC4564CAPWAP目的2006年7月
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設備ベンダーが1セットの仕様を示すのは、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コントローラとWTPsのために独自に開発をします。 CAPWAPプロトコルはデバイス変更からの独立に影響するべきではありません。
Protocol Requirement:
要件について議定書の中で述べてください:
A WTP vendor SHOULD be able to make modifications to hardware without any WLAN controller vendor involvement.
WTPベンダーSHOULD、少しも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.
特定のタイプのワイヤレスのMACデザインにCAPWAPプロトコルを指定してはいけません。 それは地方のMACと分裂-MAC WTPsの両方と互換性があるべきです。
Govindan, et al. Informational [Page 19] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [19ページ]情報のRFC4564CAPWAP目的2006年7月
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議論に基づいています。
5.1.15. NAT Traversal
5.1.15. NAT縦断
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とNetwork Address Translators(NATs)の向こう側に交信するWLANコントローラにかかわるかもしれません。 CAPWAPプロトコルは知られているNAT構成を含むtopologiesの向こう側に作動できなければなりません。 それは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.
WLANsの広範囲の採用はNATsを含むWLAN topologiesのために可能性を上げます。 CAPWAPプロトコルがそのようなtopologiesの中で適切であることは、重要です。 この要件は、CAPWAPプロトコルをNAT縦断において関連するようにすることを目指します。
Relation to Problem Statement:
問題声明との関係:
This requirement is based on WG discussions that have been determined to be important for CAPWAP.
この要件はCAPWAPに重要であることを決定しているWG議論に基づいています。
Govindan, et al. Informational [Page 20] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [20ページ]情報のRFC4564CAPWAP目的2006年7月
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プロトコルに望ましいのですが、義務的でないことを決定しています。 これらの目的がわかるのが、WLANsのコントロールを改良するのを助けるかもしれませんが、すべてのネットワークかシナリオに必ず必要でなければならないというわけではありません。
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を使用するかもしれませんが、別のものはウェブ認証を使用するかもしれません。 CAPWAPはそのような共有されたWLANsで作動できなければなりません。
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
技術開発の急速なペースは、新しい進歩が、現在の分析で満たされる必要を意味します。 このうち、あります。
Govindan, et al. Informational [Page 21] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [21ページ]情報のRFC4564CAPWAP目的2006年7月
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.
新しい無線技術のために、IEEE802.16などのCAPWAPプロトコルの中でサポートします。 したがって、プロトコルはIEEE802.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つのワイヤレスのプロトコルが、特定の層のためにこれらの要素を定義できるように伸展性に提供されています。 これは、2のワイヤレスのプロトコルタイプとバージョンがメッセージPDUとしてさばく層を割り当てるのを伴うかもしれません。 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.
特定の層2の無線技術において広げることができるようにCAPWAPプロトコルメッセージを設計しなければなりません。 それをIEEE802.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.
Problem Statementは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.
IEEE802.11APFアド・ホック委員会は、IEEE802.11の機能性を再検討して、新しい要件のための、より徹底的な定義をしました。 CAPWAPプロトコルは最小量の変化に伴うこれらの定義を取り入れることができなければなりません。 その上、IEEE802.11のための多くの拡大が現在、標準化されています。 また、CAPWAPプロトコルは最小量の変化に伴うこれらの新しい拡大を取り入れることができなければなりません。
Govindan, et al. Informational [Page 22] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [22ページ]情報のRFC4564CAPWAP目的2006年7月
Protocol Requirement:
要件について議定書の中で述べてください:
The CAPWAP protocol MUST be openly designed to support new IEEE 802.11 definitions and extensions.
新しいIEEE802.11に定義と拡大をサポートするようにオープンにCAPWAPプロトコルを設計しなければなりません。
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の中でIEEE802.11技術の機能性に関してされる多くの進歩があります。 これが今日の使用中の主要な無線技術の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.
Problem StatementはIEEE802.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の両方の上の操作ができるでしょう。 また、それは、企業網などのしっかり管理されたネットワーク、または開いていて、公立のアクセスネットワークを経営できるように設計されるでしょう。 例えば、CAPWAPが作動する異なったタイプのネットワークの向こう側にVLANトンネルを使用できます。
Protocol Requirement:
要件について議定書の中で述べてください:
The CAPWAP protocol MUST NOT be constrained to specific underlying transport mechanisms.
特定の基本的な移送機構にCAPWAPプロトコルを抑制してはいけません。
Govindan, et al. Informational [Page 23] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [23ページ]情報のRFC4564CAPWAP目的2006年7月
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.
Problem Statementは大きいWLANsを構成する複雑さについて議論します。 大規模な展開のための利用可能なインタコネクト技術の品揃えはこの複雑さをさらに激化させます。 この要件は、基本的な輸送からプロトコルの操作上の局面からの独立を支持することによって、複雑さの一部を避けます。
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.
この目的はWTPsと彼らのWLANコントローラの間でこの情報を輸送する際に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。 IEEE802.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の入場を制御するのも必要です。 凶暴な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のアクセスコントロールに必要であるワイヤレスの端末ができなければなりません。
Govindan, et al. Informational [Page 24] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [24ページ]情報のRFC4564CAPWAP目的2006年7月
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.
この目的は大きいWLANsでアクセスコントロールの問題を扱います。 広く、それはそのようなネットワークの複雑さスケールを管理するという問題を関係づけます。 切り換えとワイヤレスの中型のセグメントの両方の集合的な情報で、この目的がわかると、コントロールが助けられて、複雑さは管理されるでしょう。
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のいくつかの局面を管理するなら、WTPsが他の実体によって行われたどんな変更についてもWLANコントローラに通知するのにCAPWAPプロトコルは使用されるかもしれません。
Protocol Requirement:
要件について議定書の中で述べてください:
The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and existing network management systems.
CAPWAPは、レガシーWTPsを認識できて、存在しながら、SHOULDについて議定書の中で述べます。ネットワーク管理システム。
Govindan, et al. Informational [Page 25] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [25ページ]情報のRFC4564CAPWAP目的2006年7月
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.
Problem Statementは大きいWLANsの主要な問題として管理の複雑さを目立たせます。 この複雑さの一部がこの目的が適切である集結された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プロトコルは、西暦、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ベンダーSHOULD NOTは、相互運用性が達成されるためにハードウェアとソフトウェアのための技術仕様書を交流ベンダーと共有しなければなりません。
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設備ベンダーが1セットの仕様を示すのは、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).
この目的はそれとしての非目的として最優先されているのが、プロトコルSpecifications目的(セクション5.1.12)の写しであるということです。
Govindan, et al. Informational [Page 26] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [26ページ]情報のRFC4564CAPWAP目的2006年7月
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.
以下の目的はネットワーク・サービスオペレータによって提供されました。 彼らは結局それらのWLANsの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.
ネットワーク・サービスオペレータは、handoffsが彼らの顧客のモバイル自然のために重要であると考えます。 この点で、CAPWAPプロトコルはAP速い移管手順に悪影響を与えるべきではありません。 プロトコルは、handoffsの間、本当の時間指定サービスの、より良いサポートを許すために速い移管手順のための最適化をサポートするかもしれません。
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.
これらの要件は大規模なWLANsを管理するために簡単で、共同利用できるプロトコルに標準化取り組みの焦点を合わせるのを目的とされます。 アーキテクチャ要件はプロトコルに関する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プロトコルの開発と評価にそれらの即座の意味を反映するためにさらに、最優先しました。 プライオリティは、Mandatoryと、Acceptedと、Desirableと、Non-目的です。 彼らはプロトコルデザインの文脈の要件の有効性に関するワーキンググループコンセンサスを反映します。
Govindan, et al. Informational [Page 27] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [27ページ]情報のRFC4564CAPWAP目的2006年7月
Additionally, this document includes requirements from network service operators that have been derived based on their experience in operating large-scale WLANs.
さらに、このドキュメントは操作の大規模なWLANsの彼らの経験に基づいて引き出されたネットワーク・サービスオペレータからの要件を含んでいます。
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.
このドキュメントからの結果として起こる要件は、大規模なWLANsのWTPsのコントロールと食糧を供給するために共同利用できるプロトコルを開発して、評価するのにCAPWAP Problem Statement[RFC3990]とCAPWAP Architecture Taxonomy[RFC4118]に関連して使用されるでしょう。
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 WTPsの両方のサポートを強調します。 展開では、WTPsの両方のタイプが使用されているところでそれぞれが能力を考慮して機密保護されるのを保証するのは重要です。 Architecture Taxonomyは異なった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展開では、各グループからのトラフィックは、互いに切り離される必要があります。 それで、また、プロトコル関連の交換に加えて、ワイヤレスの端末からのデータ通信量はそれらが属する論理的なグループに関して隔離されるべきです。 1つの論理的なグループからのデータかコントロールトラフィックが別の論理的なグループにさ迷うか、または影響を及ぼすのが、可能であるべきではありません。
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の向こう側に共有される実装を考慮します。 これは正統の共有と違法なコピーの間のあいまいさを上げます。 ワイヤレスの端末は、このあいまいさを知らずに犠牲となるか、または利用するかもしれません。 この問題の解決は現在、IEEE802と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.
WLANsに対する攻撃に着手する低価格は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に影響するのは可能であるべきではありません。
Govindan, et al. Informational [Page 28] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [28ページ]情報のRFC4564CAPWAP目的2006年7月
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.
作者はワーキンググループいす、ドロシー・ゲラート、およびMahalingamマニに感謝したがっています、このドキュメントがある彼らのサポートと忍耐のために。 また、目的を形成するのを助けたワーキンググループの関係者に感謝申し上げます。 特に、作者は彼らの非常に貴重な入力についてジェームス・ケンフ、パットCalhoun、Inderpreetシン、ダン・ハーキンズ、T.Sridhar、チャールズClancy、およびEmek Sadotに感謝します。 また、私たちはドキュメントの評価のためにIEEE802.11アド・ホック委員会に感謝します。 また、作者はMeimei Dang、Satoshi Iino、Mikihito Sugiura、およびDongワングから貢献を承諾します。
9. Normative References
9. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)問題声明にアクセスします」、RFC3990、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、「ワイヤレス・アクセスのコントロールと食糧を供給するアーキテクチャ分類学は(CAPWAP)を指します」、RFC4118、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規格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、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
Govindan, et al. Informational [Page 29] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [29ページ]情報のRFC4564CAPWAP目的2006年7月
Authors' Addresses
作者のアドレス
Saravanan Govindan Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore
Saravanan Govindanパナソニックシンガポール研究所は1022を妨げて、タイはSeng工業団地#06-3530、タイ・Seng Avenueシンガポール534 415シンガポールです。
Phone: +65 6550 5441 EMail: saravanan.govindan@sg.panasonic.com
以下に電話をしてください。 +65 6550 5441はメールされます: saravanan.govindan@sg.panasonic.com
Zhonghui Yao Huawei Longgang Production Base Shenzhen 518 129 P. R. China
Zhonghui Huawei Longgang生産基盤深川P.R.中国八尾518 129
Phone: +86 755 2878 0808 EMail: yaoth@huawei.com
以下に電話をしてください。 +86 755 2878 0808はメールされます: yaoth@huawei.com
Wenhui Zhou China Mobile 53A, Xibianmen Ave, Xuanwu District Beijing 100 053 P. R. China
Wenhui中国の周のモバイル53A、Xibianmen Ave、Xuanwu District P.R.中国北京100 053
Phone: +86 10 6600 6688 ext.3061 EMail: zhouwenhui@chinamobile.com
以下に電話をしてください。 +86 10 6600 6688ext.3061EMail: zhouwenhui@chinamobile.com
L. Lily Yang Intel Corp. JF3-206, 2111 NE 25th Ave. Hilsboro, OR 97124 USA
L.ユリ陽のインテル社JF3-206、2111年のNe、第25Ave。 Hilsboro、または97124米国
Phone: +1 503 264 8813 EMail: lily.l.yang@intel.com
以下に電話をしてください。 +1 8813年の503 264メール: lily.l.yang@intel.com
Govindan, et al. Informational [Page 30] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [30ページ]情報のRFC4564CAPWAP目的2006年7月
Hong Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore
商館チェンパナソニックシンガポール研究所は1022を妨げて、タイはSeng工業団地#06-3530、タイ・Seng Avenueシンガポール534 415シンガポールです。
Phone: +65 6550 5447 EMail: hong.cheng@sg.panasonic.com
以下に電話をしてください。 +65 6550 5447はメールされます: hong.cheng@sg.panasonic.com
Govindan, et al. Informational [Page 31] RFC 4564 CAPWAP Objectives July 2006
Govindan、他 [31ページ]情報のRFC4564CAPWAP目的2006年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Govindan, et al. Informational [Page 32]
Govindan、他 情報[32ページ]
一覧
スポンサーリンク
