Independent Submission P. Narasimhan
Request for Comments: 5413 D. Harkins
Category: Historic S. Ponnuswamy
ISSN: 2070-1721 Aruba Networks
February 2010
SLAPP: Secure Light Access Point Protocol
Abstract
抽象
The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.
ワイヤレスアクセスポイントの管理およびプロビジョニング（CAPWAP）問題文は、複数のワイヤレスターミネーションポイント（WTP）とアクセスコントローラ（AC）からなる溶液を構築することができ、ワイヤレスLAN（WLAN）ネットワーク設計者の前に対処する必要がある問題について説明し、異なるベンダー。主な目標の一つは、別のWTPを制御および管理するために、1つのベンダからの交流を可能にすること装置（WTPs及びACS）の二つのクラスの間での相互運用性を解決する解決策を見つけることです。
In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.
この文書では、我々は一般的な技術に依存しないフレームワークと、このフレームワークの上に交渉して追加することができ、完全なソリューションに到達するための技術に依存するコンポーネントが含まれている制御プロトコルを構成するプロトコルを提示します。この文書では、802.11制御プロトコル、および他の、より一般的な画像のダウンロードプロトコル - 私たちは、2つのこのような制御プロトコルを提示しています。
Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP).
本文書内のテキストは、特にRFC 3990に記載された問題に対処するために書かれていても、溶液（WTPに相当）1つまたは複数のネットワーク要素を管理（ACに相当）コントローラを有するあらゆる問題に適用することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはインターネット標準化過程仕様ではありません。それは歴史的な記録のために公開されています。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのための歴史的な文書を定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5413.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5413で取得することができます。
IESG Note
IESG注意
This RFC documents the SLAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP Working Group, and therefore it may resemble the CAPWAP protocol specification in RFC 5415 as well as other IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions.
それはCAPWAPワーキンググループでは今後の作業の基礎としてIETFに提出されたときのように、このRFCはSLAPPプロトコルを文書化し、そのためには、CAPWAPプロトコルRFC 5415で仕様だけでなく、他のIETF仕事似ていてもよいです。このRFCは、歴史的な記録のためだけに公開されています。このRFCに記載されているプロトコルは徹底的に見直されていないとエラーや欠落が含まれていてもよいです。
RFC 5415 documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of Internet deployment.
RFC 5415は、CAPWAPワーキンググループのための標準トラック・ソリューションを文書化し、このRFCで定義された任意およびすべてのメカニズムを廃止します。このRFCはインターネットStandardのどんなレベルの候補ではなく、インターネットの展開の任意の並べ替えのための基礎として使用するべきではありません。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http//:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントの発行日に有効な：（trustee.ietf.org/license-infoのhttp //）この文書では、BCP 78とIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Definitions .....................................................7
2.1. Conventions Used in This Document ..........................7
3. Topology ........................................................7
4. Protocol ........................................................8
4.1. Protocol Description .......................................8
4.1.1. State Machine Explanation ...........................9
4.2. Format of a SLAPP Header ..................................10
4.3. Version ...................................................11
4.4. Retransmission ............................................12
4.5. Discovery .................................................12
4.5.1. SLAPP Discover Request .............................13
4.5.2. SLAPP Discover Response ............................15
4.6. SLAPP Discovery Process ...................................17
4.6.1. WTP ................................................17
4.6.2. AC .................................................19
5. Security Association ...........................................19
5.1. Example Authentication Models (Informative) ...............20
5.1.1. Mutual Authentication ..............................20
5.1.2. WTP-Only Authentication ............................21
5.1.3. Anonymous Authentication ...........................21
6. SLAPP Control Protocols ........................................21
6.1. 802.11 Control Protocol for SLAPP .........................21
6.1.1. Supported CAPWAP Architectures .....................21
6.1.2. Transport ..........................................24
6.1.3. Provisioning and Configuration of WTP ..............26
6.1.4. Protocol Operation .................................60
6.2. Image Download Protocol ...................................66
6.2.1. Image Download Packet ..............................66
6.2.2. Image Download Request .............................67
6.2.3. Image Download Process .............................68
6.2.4. Image Download State Machine .......................69
7. Security Considerations ........................................73
8. Extensibility to Other Technologies ............................73
9. Informative References .........................................74
The need for a protocol by which wireless LAN (WLAN) Access Controllers (ACs) can control and manage Wireless Termination Points (WTPs) from a different vendor has been presented in the CAPWAP problem statement [3]. We believe that this problem is more general than as stated in [3] and can be found in any application, including non-wireless ones, that requires a central controller to control and manage one or more network elements from a different vendor.
無線LAN（WLAN）アクセスコントローラ（ACS）は、異なるベンダーからワイヤレスターミネーションポイント（WTPs）を制御および管理することが可能なプロトコルの必要性は、CAPWAP問題文の中で提示されている[3]。我々は、この問題はで述べたようにより一般的であると考えている[3]と異なるベンダーからの1つまたは複数のネットワーク要素を制御および管理するための中央コントローラを必要と非無線のものを含む任意のアプリケーション、に見出すことができます。
One way to solve the CAPWAP problem is to define a complete control protocol that enables an AC from one vendor to control and manage a WTP from a different vendor. But a solution that is primarily focused towards solving the problem for one particular underlying technology (IEEE 802.11, in this case) may find it difficult to address other underlying technologies. Different underlying technologies may differ on the set of configurable options, and different architectural choices that are specific to that underlying technology (similar to the Local Medium Access Control (MAC) versus Split MAC architectures in 802.11). The architectural choices that are good for one underlying technology may not necessarily work for another. Not to forget that there may be multiple architectural choices [2] even for the same underlying technology. A monolithic control protocol that strives to solve this problem for multiple technologies runs the risk of adding too much complexity and not realizing the desired goals, or it runs the risk of being too rigid and hampering technological innovation.
CAPWAPの問題を解決する1つの方法は、異なるベンダーからWTPを制御および管理するために、1つのベンダからの交流を可能にする完全な制御プロトコルを定義することです。しかし、主に（この場合には、IEEE 802.11）1つの特定の基礎となる技術のための問題を解決に向けて集中しているソリューションは、それが困難な他の基盤技術に対処するかもしれません。別の基礎となる技術は、設定可能なオプション、および（802.11スプリットMACアーキテクチャ対ローカル媒体アクセス制御（MAC）に似ています）その基盤となる技術に固有の異なるアーキテクチャの選択肢のセットに異なる場合があります。 1基本的な技術のために優れている建築の選択肢は必ずしも別では動作しない場合があります。 [2]でも同じ基本的な技術のための複数の建築の選択肢があるかもしれないことを忘れないように。複数の技術のために、この問題を解決するために努力するモノリシック制御プロトコルは、あまりにも多くの複雑さを追加し、希望の目標を実現していないのリスクを実行し、またはそれはあまりにも剛性であることと技術革新を妨げる危険を冒します。
A different way to solve this problem is to split the solution space into two components -- one that is technology-agnostic or independent, and another that is specific to the underlying technology or even different approaches to the same underlying technology. The technology-independent component would be a common framework that would be an important component of the solution to this class of problems without any dependency on the underlying technology (i.e., 802.11, 802.16, etc.) being used. The technology-specific component would be a control protocol that would be negotiated using this common framework and can be easily defined to be relevant to that technology without the need for having any dependency on other underlying technologies. This approach also lends itself easily to extend the solution as new technologies arise or as new innovative methods to solve the same problem for an existing technology present themselves in the future.
基本的な技術や同じ基本的な技術にも、さまざまなアプローチに固有の技術にとらわれない、または独立して1及び別 - この問題を解決するための別の方法は、二つの成分に解空間を分割することです。技術に依存しない成分が使用されている基本的な技術（すなわち、802.11、802.16、等）上の任意の依存せずに問題のこのクラスに溶液の重要成分であろう一般的なフレームワークであろう。技術固有のコンポーネントは、この共通のフレームワークを使用してネゴシエートされると、容易に他の基礎となる技術上の任意の依存性を必要とすることなく、その技術に関連するように定義することができる制御プロトコルであろう。このアプローチはまた、新しい技術は、既存の技術は、将来的に自分自身を提示するため、同じ問題を解決するための新しい革新的な方法として生じるかのような溶液を拡張するために簡単に自分自身を貸します。
In this document, we present secure light access point protocol (SLAPP), a technology-independent protocol by which network elements that are meant to be centrally managed by a controller can discover one or more controllers, perform a security association with one of them, and negotiate a control protocol that they would use to perform the technology-specific components of the control and provisioning protocol. We have also presented two control protocols in this document -- an 802.11 control protocol for provisioning and managing a set of 802.11 WTPs, and an image download protocol that is very generic and can be applied to any underlying technology.
この文書では、我々は、安全な光アクセスポイントプロトコル（SLAPP）、中央コントローラによって管理されることを意図されているネットワーク要素はそれらのうちの一つとのセキュリティアソシエーションを実行し、1つ以上のコントローラを発見することが可能な技術に依存しないプロトコルを提示しますそして、彼らは制御およびプロビジョニングプロトコルの技術固有のコンポーネントを実行するために使用する制御プロトコルを交渉します。 802.11 WTPsのセットと、非常に一般的であり、任意の基礎となる技術に適用することができ、画像のダウンロードプロトコルをプロビジョニングおよび管理するための802.11制御プロトコル - 我々はまた、この文書では二つの制御プロトコルを提示しています。
Figure 1 shows the model by which a technology-specific control protocol can be negotiated using SLAPP to complete a solution for a certain underlying technology. The figure shows a control protocol for 802.11 and 802.16 technology components, but the SLAPP model does not preclude multiple control protocols within a certain technology segment. For example, a certain technology-specific control protocol may choose to support only the Local MAC architecture [2] while deciding not to support the Split MAC architecture [2]. While the image download protocol is presented in this document, a SLAPP implementation MUST NOT assume that this control protocol is supported by other SLAPP implementations.
図1は、技術固有の制御プロトコルは、特定の基礎となる技術のためのソリューションを完了するためにSLAPPを使用してネゴシエートすることが可能なモデルを示します。図は802.11および802.16技術コンポーネントの制御プロトコルを示しているが、SLAPPモデルは、特定の技術セグメント内の複数の制御プロトコルを排除するものではありません。例えば、特定の技術固有の制御プロトコルは、ローカルMACアーキテクチャをサポートするように選択することができる[2]スプリットMACアーキテクチャをサポートしないことを決定しながら、[2]。画像のダウンロードプロトコルは、この文書で提示されている間、SLAPPの実装は、この制御プロトコルは、他のSLAPPの実装によってサポートされていると仮定してはいけません。
Negotiated
SLAPP Control
Protocol
+-------------------------+ +------------+
| | | |
| SLAPP | | Image |
| (technology-independent +-------+----->| Download |
| framework) | | | protocol |
| | | | |
| negotiate one control | | +------------+
| protocol here | |
+-------------------------+ |
| +------------+
| | |
| | 802.11 |
+----->| control |
| | protocol |
| | |
| +------------+
|
|
| +------------+
| | |
| | 802.16 |
+----->| control |
| | protocol |
| | |
| +------------+
|
| .......
Figure 1: SLAPP Protocol Model
図1：SLAPPプロトコルモデル
The control protocols that are negotiable using SLAPP are expected to be published ones that have gone through a review process in standards bodies such as the IETF. The control protocols can either re-use the security association created during SLAPP or have the option of clearing all SLAPP state and restarting with whatever mechanisms are defined in the control protocol.
SLAPPを使用して交渉している制御プロトコルは、IETFなどの標準化団体で検討プロセスを経てきたものを公表することが期待されます。制御プロトコルはSLAPP中に作成されたセキュリティアソシエーションを再使用するか、またはすべてのSLAPP状態をクリアし、制御プロトコルで定義されているどんなメカニズムと再起動のオプションを持っていることができます。
Recently, there was a significant amount of interest in a similar problem in the Radio Frequency Identification (RFID) space that has led to the definition of a simple lightweight RFID reader protocol (SLRRP) [9]. It is quite possible that SLRRP could be a technology-specific (RFID, in this case) control protocol negotiated during a common technology-independent framework.
最近、単純な軽量のRFIDリーダプロトコル（SLRRP）の定義につながった無線周波数識別（RFID）空間における同様の問題への関心のかなりの量が存在した[9]。 SLRRPが共通の技術に依存しないフレームワーク中にネゴシエートされた制御プロトコル（この場合はRFID）技術固有であり得ることはかなり可能です。
All of the text in the document would seem to be written with a WLAN problem in mind. Please note that while the letter of the document does position the solution to solve a CAPWAP-specific problem, the spirit of the document is to address the more general problem.
文書内のテキストのすべては心の中でWLANの問題で書かれているように見えるでしょう。文書の文字がCAPWAP固有の問題を解決するためのソリューションを配置しながら、文書の精神はより一般的な問題に対処することであることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
The SLAPP protocol supports multiple topologies for interconnecting WTPs and ACs as indicated in Figure 2.
SLAPPプロトコルは、図2に示すようにWTPs及びACSを相互接続するための複数のトポロジをサポートします。
In Figure 2, we have captured four different interconnection topologies:
図2では、我々は、4つの異なる相互接続トポロジをキャプチャしています：
1. The WTP is directly connected to the AC without any intermediate nodes. Many WTPs are deployed in the plenum of buildings and are required to be powered over the Ethernet cable that is connecting it to the network. Many ACs in the marketplace can supply power over Ethernet, and in the case where the AC is the one powering the WTP, the WTP is directly connected to the AC.
1. WTPは、任意の中間ノードなしACに直接接続されています。多くのWTPsは建物のプレナムに配備されており、ネットワークに接続されたイーサネットケーブルを介して電力を供給することが要求されています。市場には多くのACSは、イーサネット上電力を供給することができ、およびACはWTPに電力を供給するものである場合に、WTPがACに直接接続されています。
2. The WTP is not directly connected to the AC, but both the AC and the WTP are in the same Layer 2 (L2) (broadcast) domain.
2. WTP直接ACに接続されていないが、ACとWTPの両方が同じレイヤ2（L2）（ブロードキャスト）ドメインです。
3. The WTP is not directly connected to the AC, and they are not present in the same L2 (broadcast) domain. They are on two different broadcast domains and have a node on the path that routes between two or more subnets.
3. WTP直接ACに接続されていない場合、それらは同一のL2（ブロードキャスト）ドメインに存在しません。彼らは、二つの異なるブロードキャストドメインにあり、2つの以上のサブネット間の経路の経路上のノードを有します。
4. The fourth case is a subset of the third one with the exception that the intermediate nodes on the path from the WTP to the AC may not necessarily be in the same administrative domain. The intermediate network may also span one or more WAN links that may have lower capacity than if both the AC and the WTP are within the same building or campus.
4.第4のケースは、ACへのWTPからの経路上の中間ノードは、必ずしも同一の管理ドメイン内ではないかもしれないことを除いて、第1のサブセットです。中間ネットワークはまた、ACとWTPの両方が同じ建物またはキャンパス内にある場合よりも小さい容量を有することができる1つのまたは複数のWANリンクにまたがることができます。
+-----------------+ +-------+
| | (1) | |
| AC +------------+ WTP |
| | | |
+--------+--------+ +-------+
|
|
|
+---+---+
(2) | |
+------+ L2 +--------+
| | | |
| +---+---+ |
| |
| |
+-----+-----+ +---+---+ +-------+
| | | | (3)| |
| WTP | | L3 +----+ WTP |
| | | | | |
+-----------+ +---+---+ +-------+
|
|
|
+---+----+ +-------+
| | (4)| |
|Internet+----+ WTP |
| | | |
+--------+ +-------+
Figure 2: SLAPP Topology
図2：トポロジをRELAX
The SLAPP state machine for both the WTP and AC is shown in Figure 3. Both the WTP and the AC discover each other, negotiate a control protocol, perform a secure handshake to establish a secure channel between them, and then use that secure channel to protect a Negotiated Control Protocol.
WTPとACの両方のためSLAPP状態マシンはWTPとACの両方が互いを発見し、図3に示され、それらの間に安全なチャネルを確立するセキュアなハンドシェイクを実行し、制御プロトコルをネゴシエートし、その後にそのセキュアチャネルを使用します交渉制御プロトコルを保護します。
The WTP maintains the following variable for its state machine:
WTPはその状態マシンの次の変数を保持しています。
abandon: a timer that sets the maximum amount of time the WTP will wait for an acquired AC to begin the Datagram Transport Layer Security (DTLS) handshake.
放棄：WTPは、データグラムトランスポート層セキュリティ（DTLS）ハンドシェイクを開始するために取得したACを待機する最大時間を設定し、タイマーを。
/--------\ /-----------\
| | | |
| v v |
| +-------------+ |
| C| discovering |<-\ |
| +-------------+ | |
| | | |
| v | |
| +-----------+ | |
\--| acquiring | | |
+-----------+ | |
| | |
v | |
+----------+ | |
C| securing |-----/ |
+----------+ |
| |
v |
+----------------+ |
| negotiated | |
C| control |-----/
| protocol |
+----------------+
Figure 3: SLAPP State Machine
図3：SLAPPステートマシン
Note: The symbol "C" indicates an event that results in the state remaining the same.
注：記号「C」は同じままの状態になるイベントを示しています。
Discovering
発見
AC: This is a quiescent state for the AC in which it waits for WTPs to request its acquisition. When a request is received, the AC transitions to Acquiring.
AC：これはWTPsがその取得を要求することを待機するためのAC静止状態です。要求が受信されると、ACは、取得に遷移します。
WTP: The WTP is actively discovering an AC. When the WTP receives a response to its Discover Request, it transitions to Acquiring.
WTP：WTPは、積極的に交流を発見されました。 WTPは、その検出要求に対する応答を受信すると、取得に移行します。
Acquiring
取得
AC: A discover request from a WTP has been received. If the request is invalid or the AC wishes to not acquire the WTP, it drops the packet and transitions back to Discovering. Otherwise, a Discover Response is sent and the AC transitions to Securing.
ACは：Aは、WTPからの要求が受信されているを発見します。リクエストが無効であるか、ACはWTPを取得しないことを希望する場合は、それが戻って発見へのパケットやトランジションをドロップ。そうでなければ、発見応答が送信され、ACは、確保に遷移します。
WTP: A discover response from an AC has been received. If the response is not valid, the WTP transitions to Discovering; otherwise, it sets the abandon timer to a suitable value to await a DTLS exchange. If the timer fires in Acquiring, the WTP transitions back to Discovering. If a DTLS "client hello" is received, the WTP transitions to Securing and cancels the abandon timer.
WTP：ACから発見応答が受信されています。応答が有効でない場合、WTPは発見に遷移し、それ以外の場合は、DTLS交換を待つために適切な値に放棄するタイマーを設定します。取得中タイマーが起動した場合、WTPは戻って発見へ遷移します。 DTLS「クライアントこんにちは」を受信した場合、WTPは確保に移行し、放棄タイマーをキャンセルします。
Securing
確保
AC: The AC performs the "client end" of the DTLS exchange. Any error in the DTLS exchange results in the AC transitioning to Discovering. When the DTLS exchange finishes, the AC transitions to the Negotiated Control Protocol.
AC：ACは、DTLS交換の「クライアント側」を行います。発見へのAC移行でDTLS交換結果に誤り。 DTLS交換が終了すると、ACは交渉制御プロトコルに移行する場合。
WTP: The WTP performs the "server end" of the DTLS exchange. Any error in the DTLS exchange results in the WTP transitioning to Discovering. When the DTLS exchange finishes, the WTP transitions to the Negotiated Control Protocol.
WTP：WTPは、DTLS交換の「サーバーの終了」を実行します。発見へのWTPの移行でDTLS交換結果に誤り。 DTLS交換が終了すると、WTPは交渉制御プロトコルに移行します。
Negotiated Control Protocol
交渉さ制御プロトコル
AC: The AC performs its side of the protocol agreed to during the discovery process. Please refer to Section 6.1 for the SLAPP 802.11 Control Protocol. For the Image Download Protocol example, see Section 6.2.
AC：ACは、プロトコルのその側は、発見プロセス中に同意行います。 SLAPP 802.11制御プロトコルについては、セクション6.1を参照してください。イメージのダウンロードプロトコル例えば、6.2節を参照してください。
WTP: The WTP performs its side of the protocol agreed to during the discovery process. Please refer to Section 6.1 for the SLAPP 802.11 Control Protocol. For the Image Download Protocol example, see Section 6.2.
WTP：WTPは、プロトコルのその側は、発見プロセス中に同意行います。 SLAPP 802.11制御プロトコルについては、セクション6.1を参照してください。イメージのダウンロードプロトコル例えば、6.2節を参照してください。
All SLAPP packets begin with the same header as shown in Figure 4.
図4に示すように、すべてのSLAPPパケットは、同一のヘッダで始まります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SLAPP Header
図4：ヘッダーをRELAX
Where:
どこ：
Maj (4 bits): the major number of the SLAPP version
MAJ（4ビット）：SLAPPバージョンのメジャー番号
Min (4 bits): the minor number of the SLAPP version
分（4ビット）：SLAPPバージョンのマイナー番号
Type (1 octet): the type of SLAPP message
タイプ（1つのオクテット）：SLAPPメッセージのタイプ
Length (two octets): the length of the SLAPP message, including the entire SLAPP header
長さ（2つのオクテット）：SLAPPメッセージの長さ、全体SLAPPヘッダを含みます
The following types of SLAPP messages have been defined:
SLAPPメッセージの種類は次のとおり定義されています。
name type
----- ------
discover request 1
discover response 2
image download control 3
control protocol packet 4
reserved 5-255
SLAPP messages include a version in the form of major.minor. This document describes the 1.0 version of SLAPP, that is the major version is one (1) and the minor version is zero (0).
SLAPPメッセージはメジャー。マイナー形式のバージョンが含まれています。この文書はSLAPPの1.0バージョンを記述し、それがメジャーバージョンである1（1）とマイナーバージョンはゼロ（0）です。
Major versions are incremented when the format of a SLAPP message changes or the meaning of a SLAPP message changes such that it would not be properly parsed by an older, existing version of SLAPP. Minor versions are incremented when some incremental additions have been made to SLAPP that enhance its capabilities or convey additional information in a way that does not change the format or meaning of the SLAPP message.
SLAPPメッセージのフォーマットが変化したときのメジャーバージョンがインクリメントされるか、またはSLAPPメッセージの意味は、それが適切にSLAPPの古い、既存のバージョンで解析されないように変更します。いくつかの増分追加がその機能を強化したり、SLAPPメッセージの形式や意味を変えない方法で、追加の情報を伝えるSLAPPに行われていたときにマイナーバージョンがインクリメントされています。
Future versions of SLAPP MAY NOT mandate support for earlier major versions of SLAPP, so an implementation MUST NOT assume that a peer that supports version "n" will therefore support version "n - i" (where both "n" and "i" are non-zero integers and "n" is greater than "i").
SLAPPの将来のバージョンではSLAPPの以前のメジャーバージョンのサポートを強制されない場合があり、その実装は、バージョンをサポートしていますピアは「n」はそのためのバージョンをサポートすることを前提と「N - I」てはならない（「N」と「i」は、ともにゼロ以外の整数と「N」は「I」）よりも大きくなります。
A SLAPP implementation that receives a SLAPP message with a higher major version number MUST drop that message. A SLAPP implementation that receives a SLAPP message with a lower major version SHOULD drop down to the version of SLAPP the peer supports. If that version of SLAPP is not supported, the message MUST be dropped. However, there may be valid reasons for which a peer wishes to drop a SLAPP message with a supported major version.
より高いメジャーバージョン番号とSLAPPメッセージを受信SLAPP実装は、そのメッセージを削除する必要があります。下部メジャーバージョンとSLAPPメッセージを受信SLAPPの実装では、ピアがサポートSLAPPのバージョンにドロップダウンすべきです。 SLAPPのそのバージョンがサポートされていない場合、メッセージは削除されなければなりません。しかし、ピアがサポートされているメジャーバージョンとSLAPPメッセージをドロップすることを望むために正当な理由があってもよいです。
A SLAPP implementation that receives a SLAPP message with a higher minor version number MUST NOT drop that message. It MUST respond with the minor version number that it supports and will necessarily not support whatever incremental capabilities were added that justified the bump in the minor version. A SLAPP implementation that receives a SLAPP message with a lower minor version MUST NOT drop that message. It SHOULD revert back to the minor version that the peer supports and not include any incremental capabilities that were added that justified the bump in the minor version.
高いマイナーバージョン番号とSLAPPメッセージを受信SLAPP実装は、そのメッセージをドロップしてはなりません。それはサポートしており、必ずしもマイナーバージョンでバンプを正当化している追加された増分どんな機能がサポートされませんマイナーバージョン番号で応じなければなりません。下のマイナーバージョンでSLAPPメッセージを受信SLAPP実装は、そのメッセージをドロップしてはなりません。これは、バックピアサポート及びませんが、マイナーバージョンでバンプを正当化している追加された増分機能を含むマイナーバージョンに戻すべきです。
SLAPP is a request response protocol. Discovery and security handshake requests are made by the WTP, and responses to them are made by the AC. Image Download packets are initiated by the AC and acknowledged by the WTP (in a negative fashion, see Section 6.2).
SLAPPは、要求応答プロトコルです。発見とセキュリティのハンドシェイク要求はWTPで作られており、それらへの応答は、ACによって作られています。イメージのダウンロードパケットはACによって開始され、WTPによって確認されている（負のやり方で、6.2節を参照してください）。
Retransmissions are handled solely by the initiator of the packet. After each packet for which a response is required is transmitted, the sender MUST set a retransmission timer and resend the packet upon its expiry. The receiver MUST be capable of either regenerating a previous response upon receipt of a retransmitted packet or caching a previous response and resending upon receipt of a retransmitted packet.
再送は、パケットのイニシエータによってのみ処理されます。応答が必要とされる各パケットが送信された後、送信側は再送タイマーを設定し、その期間満了時にパケットを再送しなければなりません。受信機は、再送されたパケットを受信すると、以前の応答を再生または前の応答をキャッシュし、再送パケットを受信すると再送のどちらかが可能でなければなりません。
The retransmission timer MUST be configurable and default to one (1) second. No maximum or minimum for the timer is specified by this version of SLAPP.
再送タイマーは1秒に設定可能で、デフォルトでなければなりません。タイマーのための最大値や最小値はSLAPPのこのバージョンで指定されていません。
Each time a retransmission is made, a counter SHOULD be incremented, and the number of retransmissions attempted by a sender before giving up and declaring a SLAPP failure SHOULD be four (4)-- that is, the number of attempts made for each packet before declaring failure is five (5).
即ち、試行回数が前に各パケットのために作られた - （4）の再送が行われるたびに、カウンタをインクリメントする必要があり、SLAPP障害を与えると宣言する前に送信者によって試みられた再送信の数は4であるべきです失敗を宣言すると、5（5）です。
The exception to this rule is Image Download packets, which are not individually acknowledged by the WTP (see Section 6.2). The final packet is acknowledged and lost packets are indicated through Image Download Requests.
この規則の例外は、個別にWTP（6.2節を参照）によって確認されていないイメージのダウンロードパケット、です。最後のパケットが認められ、失われたパケットは、イメージのダウンロード要求によって示されます。
When a WTP boots up and wants to interoperate with an Access Controller so that it can be configured by the AC, one of the first things it needs to do is to discover one or more ACs in its network neighborhood. This section contains the details of this discovery mechanism.
WTPが起動すると、それはACで設定できるように、アクセスコントローラと相互運用したい場合は、それを行う必要がある最初のものの一つは、そのネットワークコンピュータ内の1つまたは複数のACSを発見することです。このセクションでは、この発見機構の詳細が含まれています。
As described in Section 3, an AC and a WTP could reside in the same Layer 2 domain, or be separated by a Layer 3 cloud including intermediate clouds that are not under the same administrative domain (for example, an AC and a WTP separated by a wide-area public network). So any proposed discovery mechanism should have provisions to enable a WTP to discover an AC across all these topologies.
第3節で説明したように、AC及びWTPは、同じレイヤ2ドメインに存在することができ、または例えば、（同じ管理ドメインの下にない中間雲を含むレイヤ3クラウドにより分離され、ACで区切らWTP広域パブリックネットワーク）。だから、任意の提案の発見メカニズムは、これらすべてのトポロジ間で交流を発見するためにWTPを有効にする規定を持つべきです。
We assume that a WTP, prior to starting the discovery process, has already obtained an IP address on its wired segment.
私たちは、WTPは、発見プロセスを開始する前に、すでにその有線セグメント上のIPアドレスを取得していることを前提としています。
The SLAPP discovery process is initiated by sending a SLAPP discover request packet. The packet can be addressed to the broadcast IP address, a well-known multicast address, or (if the IP address of an AC is either configured prior to the WTP booting up or is learned during the boot-up sequence) addressed to a unicast IP address. Lack of a response to one method of discovery SHOULD result in the WTP trying another method of discovery. The SLAPP discover request packet is a UDP packet addressed to port [TBD] designated as the SLAPP discovery port. The source port can be any random port. The payload of the SLAPP discover request packet is shown in Figure 5.
SLAPP検出プロセスはSLAPPが要求パケットを発見送信することにより開始されます。 （ACのIPアドレスは前WTPが起動中または起動シーケンス中に学習されるように構成されているいずれかの場合）、パケットは、ユニキャスト宛ブロードキャストIPアドレス、よく知られたマルチキャストアドレスに宛て、またはすることができますIPアドレス。発見の一つの方法への応答の欠如は、発見の別の方法を試しWTPを生じるはずです。 SLAPPは、要求パケットがUDPパケットがSLAPP発見ポートとして指定されたポート[TBD]宛で発見します。送信元ポートは、任意のランダムなポートにすることができます。 SLAPPのペイロードは、要求パケットが図5に示されている発見します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n controltypes| control type | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SLAPP Discover Request
図5：SLAPP検出要求
The transaction ID is a randomly generated, 32-bit number that is maintained during one phase of the SLAPP discovery process. It is generated by a WTP starting a discovery process. When one discovery method fails to find an AC and the WTP attempts another discovery method it MUST NOT re-use the Transaction ID. All ACs that intend to respond to a SLAPP discover request must use the same value for this field as in the request frame.
トランザクションIDはSLAPP発見プロセスの一つの相の間、維持されるランダムに生成され、32ビットの数値です。これは、発見プロセスを開始するWTPによって生成されます。 1つの発見方法は、ACを見つけるために失敗し、WTPは、トランザクションIDを再使用してはならない他の検出方法を試みる。ときSLAPPに応答する予定のすべてのACSは、要求が要求フレームのように、このフィールドに同じ値を使用する必要があります発見します。
This field allows the WTP to specify a unique identifier for itself. This MAY be, for instance, its 48-bit MAC address or it could be any other string such as a serial number.
このフィールドは、WTPは、それ自体の一意の識別子を指定することができます。これは、例えば、その48ビットのMACアドレスであってもよく、またはそれは、シリアル番号のような任意の他の文字列とすることができます。
The Flags field is used to indicate certain things about the discover request. For example, bit 0 in the Flags field indicates whether the discover request packet is being sent to the AC, if unicast, based on a configuration at the WTP or based on some other means of discovery. This bit should always be set to the discover mode if the SLAPP discover request packet is being sent to either a broadcast or multicast address. Here are the valid values for various bits in the Flags field.
Flagsフィールドは、検出要求に関する特定の事柄を示すために使用されます。例えば、フラグフィールドに0が発見要求パケットは、ACに送信されるかどうかを示すビットであれば、ユニキャスト、WTPでの構成に基づいてまたは検出の他の手段に基づきます。 SLAPPが要求パケットをブロードキャストまたはマルチキャストアドレスのどちらかに送信されている発見した場合、このビットは常に発見モードに設定する必要があります。ここではフラグ欄に様々なビットの有効な値は。
Bit 0: 0 - Configuration mode 1 - Discover mode
ビット0：0 - コンフィギュレーションモード1 - 発見モード
Bits 1-15: Must always be set to 0 by the transmitter Must be ignored by the receiver
ビット1-15：常に送信機によって0に設定する必要があり、受信機によって無視されなければなりません
This 32-bit field is the WTP vendor's Structure of Management Information (SMI) enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA).
この32ビットのフィールドは、管理情報（SMI）ネットワークオクテット順に企業コード（これらの企業コードから得られ、IANAに登録することができる）のWTPベンダの構造です。
This 32-bit field indicates the version of hardware present in the WTP. This is a number that is totally left to the WTP vendor to choose.
この32ビットのフィールドは、WTPにハードウェア現在のバージョンを示しています。これは完全に選択するWTPのベンダーに任されている番号です。
This 32-bit field indicates the version of software present in the WTP. This is a number that is totally left to the WTP vendor to choose.
この32ビットのフィールドは、WTPのソフトウェア現在のバージョンを示しています。これは完全に選択するWTPのベンダーに任されている番号です。
This 8-bit field indicates the number of 8-bit control protocol indicators that follow it and therefore implicitly indicates the number of different control protocols the WTP is capable of supporting. This number MUST be at least one (1).
この8ビットフィールドは、それに続く、したがって暗黙WTPがサポートすることができる異なる制御プロトコルの数を示す8ビットの制御プロトコルインジケータの数を示します。この数は、少なくとも一つの（1）でなければなりません。
This 8-bit field indicates the type of control protocol the WTP supports and is willing to use when communicating with an AC. There MAY be multiple "control type" indicators in a single SLAPP Discover Request.
この8ビットのフィールドは、WTPがサポートする制御プロトコルのタイプを示し、ACとの通信時に使用する意思があります。単一SLAPP検出要求で複数の「制御タイプ」の指標があるかもしれません。
Valid Control Types
-------------------
0 - RESERVED (MUST not be used)
1 - Image Download Control Protocol
2 - 802.11 SLAPP Control Protocol
3-255 - RESERVED (to IANA)
An AC that receives a SLAPP discover request packet from a WTP can choose to respond with a SLAPP discover response packet. The format of the SLAPP discover response packet is shown in Figure 6.
SLAPPを受けたACは、応答パケットを発見SLAPPで応答するかを選択することができますWTPからの要求パケットを発見します。 SLAPPのフォーマットは、応答パケットは、図6に示されている発見します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| control type |
+-+-+-+-+-+-+-+-+
Figure 6: SLAPP Discover Response
図6：SLAPP発見レスポンス
The SLAPP discover response packet is a UDP packet. It is always unicast to the WTP's IP address. The source IP address is that of the AC sending the response. The source port is the SLAPP discover port [TBD] and the destination port is the same as the source port used in the SLAPP discover request. The WTP's MAC address and the transaction ID must be identical to the values contained in the SLAPP discover request. The Status field indicates to the WTP whether the AC is either accepting the discover request and is willing to allow the WTP to proceed to the next stage (ACK) or whether it is denying the WTP's earlier request (NACK). The AC includes its own vendor ID, hardware, and software versions in the response.
SLAPPは、応答パケットを発見UDPパケットです。それは、常にWTPのIPアドレスにユニキャストです。送信元IPアドレスは、ACの応答を送信することです。ソースポートはSLAPPポート[TBD]を発見し、宛先ポートが要求を発見SLAPPに使用される送信元ポートと同じです。 WTPのMACアドレスとトランザクションIDはSLAPPに含まれる値と同一でなければならない要求を発見。 Statusフィールドは、ACのいずれかの要求を発見受け付け、WTPは、次の段階（ACK）又はそれがWTPの以前の要求（NACK）を拒否されたか否かを進行させるために喜んであるかどうかをWTPに示します。 AC応答でそれ自身のベンダーID、ハードウェア、およびソフトウェアのバージョンを含みます。
The value of the Transaction ID field should be identical to its value in the SLAPP discover request packet sent by the WTP.
トランザクションIDフィールドの値は、WTPにより送信された要求パケットを発見SLAPPで、その値と同じでなければなりません。
The WTP Identifier that was sent in the corresponding SLAPP discover request frame.
対応SLAPPで送信されたWTP識別子は、要求フレームを発見します。
This field is unused by this version of SLAPP. It MUST be set to zero (0) on transmission and ignored upon receipt.
このフィールドは、SLAPPのこのバージョンで使用されていません。これは、送信にゼロ（0）に設定し、受信時に無視しなければなりません。
If the value of the Status field is a 1, indicating that the AC is sending a successful response, then the values in this field and the following two are valid. The 32-bit AC Vendor ID points to the vendor ID of the AC. If the value of the Status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP.
Statusフィールドの値は、ACが成功応答を送信していることを示し、1であれば、このフィールドの値は次の2つが有効です。 ACのベンダーIDの32ビットACベンダーIDポイント。 Statusフィールドの値が1でない場合、このフィールドはACで0に設定し、WTPによって無視されるべきです。
If the value of the Status field is 1, then this 32-bit field contains the value of the AC's hardware version. This value is chosen by the AC vendor. If the value of the Status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP.
Statusフィールドの値が1である場合、この32ビットのフィールドは、ACのハードウェアバージョンの値が含まれています。この値は、ACベンダによって選択されます。 Statusフィールドの値が1でない場合、このフィールドはACで0に設定し、WTPによって無視されるべきです。
If the value of the Status field is 1, then this 32-bit field contains the value of the AC's software version. This value is chosen by the AC vendor. If the value of the Status field is not 1, then this field should be set to 0 by the AC and ignored by the WTP.
Statusフィールドの値が1である場合、この32ビットのフィールドは、ACのソフトウェアバージョンの値が含まれています。この値は、ACベンダによって選択されます。 Statusフィールドの値が1でない場合、このフィールドはACで0に設定し、WTPによって無視されるべきです。
The control type that the AC will use to communicate with the WTP. This value MUST match one of the control types passed in the corresponding SLAPP Discover Request.
ACは、WTPとの通信に使用する制御型。この値は、対応するSLAPP検出要求に渡されたコントロールの種類のいずれかと一致しなければなりません。
There are multiple ways in which a WTP can discover an AC.
WTPはACを発見することが可能な複数の方法があります。
1. Static configuration: An administrator, prior to deploying a WTP, can configure an IP address of an AC on the WTP's non-volatile memory. If this is the case, then the SLAPP discover request packet is addressed to the configured IP address.
1.静的設定：管理者は、WTPを展開する前に、WTPの不揮発性メモリ上のACのIPアドレスを設定することができます。このような場合は、その後、SLAPPは、要求パケットが設定されたIPアドレスにアドレス指定されているを発見します。
2. DHCP options: As part of the DHCP response, the DHCP server could be configured to use option 43 to deliver the IP address of an AC to which the WTP should address the SLAPP discover request packet. If the IP address of an AC is handed to the WTP as part of the DHCP response, then the WTP should address the SLAPP discover request packet to this IP address.
2. DHCPオプション：DHCP応答の一部として、DHCPサーバは、WTPがSLAPPが要求パケットを発見取り組むべきとの交流のIPアドレスを提供するためにオプション43を使用するように構成することができます。 ACのIPアドレスはDHCP応答の一部としてWTPに渡されている場合、WTPはSLAPPは、このIPアドレスに要求パケットを発見し対処する必要があります。
3. DNS configuration: Instead of configuring a static IP address on the WTP's non-volatile memory, an administrator can configure a Fully-Qualified Domain Name (FQDN) of an AC. If the FQDN of an AC is configured, then the WTP queries its configured DNS server for the IP address associated with the configured FQDN of the AC. If the DNS query is successful and the WTP acquires the IP address of an AC from the DNS server, then the above discover request packet is addressed to the unicast address of the AC.
3. DNSの設定：代わりにWTPの不揮発性メモリに静的IPアドレスを設定するのは、管理者がACの完全修飾ドメイン名（FQDN）を設定することができます。 ACのFQDNが設定されている場合は、WTPはACの構成されたFQDNに関連付けられたIPアドレスをその設定されたDNSサーバーを照会します。 DNSクエリが成功し、WTPは、DNSサーバからACのIPアドレスを取得した場合は、上記の発見要求パケットはACのユニキャストアドレスにアドレス指定されています。
4. Broadcast: The WTP sends a discover request packet addressed to the broadcast IP address with the WTP's IP address as the source. A network administrator, if necessary, could configure the default router for the subnet that the WTP is on with a helper address and unicast it to any address on a different subnet.
4.放送：WTPは、要求パケットが送信元としてWTPのIPアドレスを持つブロードキャストIPアドレス宛の発見を送信します。ネットワーク管理者は、必要に応じて、ヘルパーアドレスでWTPがオンになっているサブネットのデフォルトのルータを設定し、別のサブネット上の任意のアドレスに、それをユニキャストできます。
5. IP Multicast: A WTP can send the above payload to a SLAPP IP multicast address [TBD].
5. IPマルチキャスト：WTPはSLAPP IPマルチキャストアドレス[TBD]に上記ペイロードを送信することができます。
6. DNS: If there is no DNS FQDN configured on the WTP, and the WTP is unable to discover an AC by any of the above methods, then it should attempt to query the DNS server for a well-known FQDN of an AC [TBD]. If this DNS query succeeds, then the WTP should address the SLAPP discover request packet to the unicast address of the AC.
6. DNS：そこWTPに構成ないDNSのFQDNがなく、WTPは、上記の方法のいずれかによりACを発見できない場合、それは[ACの周知のFQDNのDNSサーバーを照会することを試みるべきですTBD]。このDNSクエリが成功した場合、WTPはSLAPPはACのユニキャストアドレスに要求パケットを発見し対処する必要があります。
The above process is summarized in the sequence shown in Figure 7.
上記プロセスは、図7に示すシーケンスにまとめられています。
SLAPP discovery start: Static IP address config option: Is a static IP address for an AC configured? If yes, send SLAPP discover request to that unicast IP address SLAPP discover response within discovery_timer? If yes, go to "done" If not, go to "Static FQDN config option" If not, go to "Static FQDN config option" Static FQDN config option: Is a static FQDN configured? If yes, send a DNS query for the IP address for the FQDN. Is DNS query successful? If yes, send SLAPP discover request to that IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "DHCP options option" If not, go to "DHCP options option" DHCP options option: Is the IP address of an AC present in the DHCP response? If yes, send SLAPP discover request to the AC's IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "Broadcast option" If not, go to "Broadcast option" Broadcast option: Send SLAPP discover packet to the broadcast address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "Multicast option" Multicast option: Send SLAPP discover packet to the SLAPP multicast address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "DNS discovery option" DNS discovery option: Query the DNS server for a well-known DNS name Is the DNS discovery successful? If yes, send SLAPP discover request to that IP address SLAPP discover response within discovery timer? If yes, go to "done" If not, go to "SLAPP discovery restart" If not, go to "SLAPP discovery restart"
SLAPP探索開始：静的IPアドレスの設定オプション：ACのための静的IPアドレスが設定されていますか？はい、SLAPPを送信する場合は、そのユニキャストIPアドレスSLAPPにリクエストを発見discovery_timer内に応答を発見？静的FQDNが設定されている：はい場合は、いない場合は、「静的FQDNの設定オプション」でない場合は、「静的FQDNコンフィグオプション」静的FQDNの設定オプションに行くに行く「完了」に進んでください？はい場合は、FQDNのためのIPアドレスのDNSクエリを送信します。 DNSクエリが成功しましたか？はい、SLAPPを送信する場合は、そのIPアドレスSLAPPにリクエストを発見し、発見タイマー内に応答を発見？はい場合は、「完了」に進んでいない場合は、「DHCPオプションオプション」に行っていない場合は、「DHCPオプションオプション」DHCPオプションオプションにアクセスしてください：DHCP応答にACの存在のIPアドレスですか？はい、SLAPPを送信する場合は、ACのIPアドレスSLAPPにリクエストを発見し、発見タイマー内に応答を発見？そうならば、そうでない場合は、「ブロードキャストオプション」に進みます「完了」に進んでいない場合は、「ブロードキャストオプション」ブロードキャストオプションに行く：SLAPPはSLAPPが発見タイマー内に応答を発見ブロードキャストアドレスにパケットを発見送信しますか？はい、そうでない場合は「完了」に行けば、「マルチキャストオプション」マルチキャストオプションに行く：SLAPPを送るSLAPPマルチキャストアドレスSLAPPにパケットを発見し、発見タイマー内に応答を発見？はい場合は、「DNS発見オプション」DNSディスカバリオプションに行き、そうでない場合は「完了」に進んでください：よく知られているDNS名のDNSサーバーを照会成功したDNSの発見か？はい、SLAPPを送信する場合は、そのIPアドレスSLAPPにリクエストを発見し、発見タイマー内に応答を発見？そうならば、そうでない場合は、「SLAPPの発見の再起動」に進んでいない場合は、「SLAPPの発見の再起動」に進んで「完了」に進んでください。
SLAPP discovery restart:
Set timer for SLAPP discovery idle timer
When timer expires, go to "SLAPP discovery start"
done:
Go to the next step
Figure 7
図7
When an AC receives a SLAPP discover request, it must determine whether or not it wishes to acquire the WTP. An AC MAY only agree to acquire those WTPs whose WTP Identifiers are statically configured in its configuration. Or an AC that is willing to gratuitously acquire WTPs MAY accept any request pending authentication. An AC MUST only choose to acquire WTPs that speak a common Negotiated Control Protocol, but other factors may influence its decision. For instance, if the Negotiated Control Protocol is the Image Download protocol defined in this memo, the AC MUST NOT acquire a WTP for which it does not have a compatible image to download as determined by the WTP's HW Vendor ID, HW Version, and Software Version. Whatever its decision, the AC MUST respond one of two ways.
ACはSLAPP要求を発見受信すると、それはWTPを取得することを望むか否かを決定しなければなりません。 ACはそのWTP識別子静的にその構成で構成されたものWTPsを取得することに同意することができます。または無償認証保留中のすべての要求を受け入れるかもしれWTPsを獲得していく所存ですAC。 ACは、唯一の共通交渉制御プロトコルを話すWTPsを取得することを選択する必要がありますが、他の要因は、その決定に影響を与える可能性があります。交渉制御プロトコルはこのメモで定義されたイメージのダウンロードプロトコルである場合たとえば、ACは、WTPのHWベンダーID、HWバージョン、およびソフトウェアによって決定されるダウンロードする互換性のあるイメージを持っていないためにWTPを取得してはなりません版。どのようなその決定、ACは、2つの方法のいずれかを反応しなければなりません。
1. The AC sends a SLAPP discover response indicating its agreement to acquire the WTP.
1. ACはSLAPPはWTPを取得するための契約を示す応答を発見送信します。
2. The AC silently drops the SLAPP discover request and does not respond at all.
2. ACは黙っSLAPPが要求を発見し、全く応答しない落ちます。
Once an AC has been discovered by a WTP and agreed to acquire it (by sending a Discover Response), it will initiate a DTLS [6] [8] exchange with the WTP by assuming the role of the "client". The WTP assumes the role of the "server". The port used by both the WTP and AC for this exchange will be [TBD].
ACは、WTPによって発見され（発見応答を送信することで）それを取得することに合意したら、それは「クライアント」の役割を想定してWTPとDTLS [6] [8]交換を開始します。 WTPは、「サーバー」の役割を前提としています。この交換のためのWTPとACの両方によって使用されるポートは、[TBD]あろう。
An obvious question is "Why is the AC acting as a client?". The reason is to allow for non-mutual authentication in which the WTP is authenticated by the AC (see Section 5.1.2).
明白な疑問は「なぜACがクライアントとして動作している？」です。その理由は、WTPは、AC（5.1.2項を参照）によって認証された非相互認証を可能にすることです。
Informational note: DTLS is used because it provides a secure and connectionless channel using a widely accepted and analyzed protocol. In addition, the myriad of authentication options in DTLS allows for a wide array of options with which to secure the channel between the WTP and the AC -- mutual and certificate-based; asymmetric or non-mutual authentication; anonymous authentication, etc. Furthermore, DTLS defines its own fragmentation and reassembly techniques as well as ways in which peers agree on an effective MTU. Using DTLS obviates the need to redefine these aspects of a protocol and therefore lessens code bloat as the same problem doesn't need to be solved yet again in another place.
情報注：それは広く受け入れられ、分析プロトコルを使用して安全でコネクションレスチャネルを提供するため、DTLSが使用されます。また、DTLSで認証オプションの無数はWTPとACとの間のチャネルを確保するには、オプションの広いアレイを可能に - 相互と証明書ベース。非対称または非相互認証;匿名認証、等さらに、DTLSは、独自のフラグメンテーションと再構成技術ならびにピアが有効なMTUに同意する方法を定義します。 DTLSを使用するプロトコルのこれらの側面を再定義する必要がなくなるため、同じ問題が別の場所に再び解決する必要がないように、コードの膨張を軽減します。
Failure of the DTLS handshake protocol will cause both parties to abandon the exchange. The AC SHOULD blacklist this WTP for a period of time to prevent a misconfigured WTP from repeatedly discovering and failing authentication. The WTP MUST return to the discovery state of SLAPP to locate another suitable AC with which it will initiate a DTLS exchange.
DTLSハンドシェイクプロトコルの失敗は、両当事者が交流を放棄するようになります。 ACは繰り返し認証を発見し、失敗から誤って設定WTPを防ぐために、一定期間、このWTPをブラックリストすべきです。 WTPは、DTLS交換を開始される別の適切なACを見つけるためにSLAPPの発見状態に戻らなければなりません。
Once the DTLS handshake has succeeded, the WTP and AP transition into "image download state" and protect all further SLAPP messages with the DTLS-negotiated cipher suite.
DTLSハンドシェイクが成功した後は、WTPとAP「画像ダウンロード状態」への移行とは、DTLS交渉暗号スイートを持つすべての更なるSLAPPメッセージを保護します。
Any valid cipher suite in [7] can be used to authenticate the WTP and/or the AC. Different scenarios require different authentication models. The following examples are illustrative only and not meant to be exhaustive.
[7]のいずれかの有効な暗号スイートは、WTP及び/又はACを認証するために使用することができます。異なるシナリオが異なる認証モデルを必要とします。以下の実施例は、例示にすぎず、網羅的であることを意味しています。
Since neither side typically involves a human being, a username/ password-based authentication is not possible.
どちらの側は、一般的に人間が関与するので、ユーザ名/パスワードベースの認証はできません。
Zero-config requirements on certain WTP deployments can predicate certain authentication options and eliminate others.
特定のWTPの展開上のゼロコンフィグ要件は、特定の認証オプションを述語と他の人を排除することができます。
When mutually authenticating, the WTP authenticates the AC, thereby ensuring that the AC to which it is connecting is a trusted AC, and the AC authenticates the WTP, thereby ensuring that the WTP that is connecting is a trusted WTP.
相互認証時に、WTPがACを認証し、それによってACは、それが接続されているためにどのことを保証する信頼ACであり、ACは、それによって接続されているWTPが信頼WTPであることを保証する、WTPを認証します。
Mutual authentication is typically achieved by using certificates on the WTP and AC, which ensure public keys each party owns. These certificates are digitally signed by a Certification Authority, a trusted third party.
相互認証は、典型的には、各当事者が所有している公開鍵を確保WTPとAC上の証明書を使用することによって達成されます。これらの証明書は、デジタル認証局、信頼できるサードパーティによって署名されています。
Enrolling each WTP in a Certification Authority is outside the scope of this document, but it should be noted that a manufacturing Certification Authority does not necessarily provide the level of assurance necessary as it will only guarantee that a WTP or AC was manufactured by a particular company and cannot distinguish between a trusted WTP and a WTP that is not trusted but was purchased from the same manufacturer as the AC.
証明機関の各WTPを登録することは、この文書の範囲外であるが、それだけWTPまたはACは、特定の会社によって製造されたことを保証するように製造証明機関は、必ずしも必要な保証のレベルを提供しないことに留意すべきですそして、信頼できるWTPと信頼されていないが、ACと同じメーカーから購入したWTPを区別することはできません。
Some deployments may only require the WTP to authenticate to the AC and not the other way around.
いくつかの展開はACのみではなく他の方法で回避への認証にWTPが必要な場合があります。
In this case, the WTP has a keypair that can uniquely identify it (for example, using a certificate) and, that keypair is used in a "server-side authentication" [7] exchange.
この場合、WTP一意（証明書を使用して、など）を識別することができる鍵ペアを有しており、その鍵ペアを「サーバ側認証」[7]交換に使用されます。
This authentication model does not authenticate the AC and a rogue AC could assert control of a valid WTP. It should be noted, though, that this will only allow the WTP to provide service for networks made available by the rogue AC. No unauthorized network access is possible.
この認証モデルは、有効なWTPの制御を主張できACおよび不正ACを認証しません。唯一のWTPは、不正なACによって使用可能になるネットワークのためのサービスを提供できるようになると、しかし、注意すべきです。権限のないネットワークアクセスが可能ではありません。
In some deployments, it MAY just be necessary to foil the casual snooping of packets. In this case, an unauthenticated, but encrypted, connection can suffice. Typically a Diffie-Hellman exchange is performed between the AC and WTP and the resulting unauthenticated key is used to encrypt traffic between the AC and WTP.
いくつかの展開では、それだけでパケットのカジュアルスヌーピングをくじくする必要があるかもしれません。この場合、認証されていないが、暗号化され、接続が十分できます。典型的にDiffie-Hellman交換がACとWTPの間で行われ、得られた未認証キーはACとWTPの間のトラフィックを暗号化するために使用されます。
In this section, we describe two extensions for SLAPP -- one that is specific to 802.11 WLANs and another that is a technology-neutral protocol by which an AC can download a bootable image to a WTP.
ACはWTPに起動可能なイメージをダウンロードすることが可能な技術中立プロトコルである802.11 WLANおよび別に固有の1 - このセクションでは、我々はSLAPPのための2つの拡張機能について説明します。
This section describes a SLAPP extension that is targeted towards WTPs and ACs implementing the IEEE 802.11 WLAN standard. This extension contains all the technology-specific components that will be used by an AC to control and manage 802.11 WTPs.
このセクションでは、WTPsおよびIEEE 802.11 WLAN標準を実装するのACを対象としてSLAPP拡張を説明しています。この拡張は802.11 WTPsを制御し、管理するためにACで使用される全ての技術固有のコンポーネントが含まれています。
The CAPWAP architecture taxonomy document [2] describes multiple architectures that are in use today in the WLAN industry. While there is a wide spectrum of variability present in these documented architectures, supporting every single variation or choice would lead to a complex protocol and negotiation phase. In the interest of limiting the complexity of the 802.11 component, we have limited the negotiation to four different architectural choices as listed below:
CAPWAPアーキテクチャタクソノミー文書では、[2] WLAN業界で使用され、今日ある複数のアーキテクチャを説明しています。変動の存在の広いスペクトルはこれらの文書のアーキテクチャであるが、ひとつひとつの変動や選択をサポートすることは、複雑なプロトコルと交渉相につながります。以下に示すよう802.11部品の複雑さを制限するの関心では、我々は、4つの異なるアーキテクチャの選択肢に交渉が限られています：
Local MAC, bridged mode: This mode of operation falls under the Local MAC architecture. The 802.11 MAC is terminated at the WTP. The WTP implements an L2 bridge that forwards packets between its WLAN interface and its Ethernet interface.
ローカルMAC、ブリッジモード：この動作モードは、ローカルMACアーキテクチャに該当します。 802.11 MACは、WTPで終了されます。 WTPは、そのWLANインタフェースとイーサネットインタフェース間でパケットを転送するL2ブリッジを実装します。
Local MAC, tunneled mode: This mode of operation also falls under the Local MAC architecture where the 802.11 MAC is terminated at the WTP. The difference between this mode and the previous one is that in this mode, the WTP tunnels 802.3 frames to the AC using the mechanisms defined in Section 6.1.2.
ローカルMAC、トンネル化モード：この動作モードはまた、802.11 MACは、WTPで終端されているローカルMACアーキテクチャに該当します。このモードと以前のものとの差は、このモードでは、WTPは、セクション6.1.2で定義されたメカニズムを使用してACを802.3フレームをトンネリングすることです。
Split MAC, L2 crypto at WTP: This mode of operation falls under the Split MAC architecture. The 802.11 MAC is split between the WTP and the AC, the exact nature of the split is described in Section 6.1.1.2. The L2 crypto functions are implemented in the WTP are the ones used to satisfy this function irrespective of whether or not the AC is also capable of this function. The WTP tunnels L2 frames to the AC using mechanisms defined in Section 6.1.2.
スプリットMAC、WTPのL2暗号は：この動作モードは、スプリットMACアーキテクチャに該当します。 802.11 MACは、WTPとACとの間で分割され、分割の正確な性質は、セクション6.1.1.2に記載されています。 WTPで実装されるL2暗号機能はACもこの機能が可能であるか否かにかかわらず、この機能を満たすために使用されるものです。 WTPは、セクション6.1.2で定義されたメカニズムを使用してACにL2フレームをトンネリングします。
Split MAC, L2 crypto at AC: This mode of operation also falls under the Split MAC architecture. The difference between this one and the previous one is that the L2 crypto functions implemented in the AC are used to satisfy this function irrespective of whether or not these functions are also available at the WTP. The WTP tunnels L2 frames to the AC using mechanisms defined in Section 6.1.2.
スプリットMAC、ACでL2暗号は：この動作モードは、スプリットMACアーキテクチャに該当します。これと以前のものとの差はACで実装L2暗号機能にかかわらず、これらの機能はまた、WTPで入手可能であるか否かのこの機能を満たすために使用されることです。 WTPは、セクション6.1.2で定義されたメカニズムを使用してACにL2フレームをトンネリングします。
The Local MAC architecture as documented in the CAPWAP architecture taxonomy document [2] performs all 802.11 frame processing at the WTP. The conversion from 802.11 to 802.3 and vice versa is also implemented at the WTP. This would mean that other functions like fragmentation/reassembly of 802.11 frames, and encryption/decryption of 802.11 frames is implemented at the WTP.
ローカルMACアーキテクチャCAPWAPアーキテクチャタクソノミ文書に記載されているように[2] WTP全く802.11フレームの処理を行います。 802.11から802.3への変換及びその逆もWTPで実現されます。これは、802.11フレームの断片化/再構築、および802.11フレームの暗号化/復号化のような他の機能は、WTPで実装されていることを意味します。
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and bridged onto the Ethernet interface of the WTP. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
ローカルMACアーキテクチャのこのサブモードでは、802.11フレームを802.3フレームに変換され、WTPのイーサネットインタフェースにブリッジ。これらのフレームは、ACによって割り当てられた802.1Q VLANタグでタグ付けされてもよいです。
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and are tunneled (using the tunneling mechanism defined in Section 6.1.2) to the AC to which the WTP is attached. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
ローカルMACアーキテクチャのこのサブモードでは、802.11フレームを802.3フレームに変換され、WTPが取り付けられたACに（セクション6.1.2で定義されたトンネリングメカニズムを使用して）トンネリングされます。これらのフレームは、ACによって割り当てられた802.1Q VLANタグでタグ付けされてもよいです。
In the Split MAC architecture, the MAC functions of an 802.11 AP are split between the WTP and the AC. The exact nature of the split is dependent upon the sub-modes listed in this section. In both cases, frames are tunneled to the AC using the mechanism defined in Section 6.1.2.
スプリットMACアーキテクチャでは、802.11 APのMAC機能は、WTPとACとの間で分割されます。分割の正確な性質は、このセクションに記載されているサブモードに依存します。両方の場合において、フレームは、セクション6.1.2で定義されたメカニズムを使用してACにトンネリングされます。
Some of these Split MAC architectures convert the 802.11 frames into 802.3 frames, which may be 802.1Q-tagged using tags assigned by the AC, while other of these Split MAC architectures will tunnel the entire 802.11 frame to the AC. The AC and WTP agree on what type of frame will be tunneled during the control protocol registration in Section 6.1.3
これらスプリットMACアーキテクチャのいくつかは、802.1Qタグ付きACによって割り当てられたタグを使用してもよい802.3フレームに802.11フレームに変換し、これらのスプリットMACアーキテクチャの他の一方のトンネルACの全体802.11フレームをします。 ACとWTPは、セクション6.1.3で制御プロトコルの登録時にトンネルされますフレームの種類に同意します
For this sub-mode of the Split MAC architecture, the 802.11 AP functions are split as follows:
次のようにスプリットMACアーキテクチャのこのサブモードでは、802.11 AP機能が分割されています。
At the WTP:
WTPで：
Rate Adaptation
レートアダプテーション
Power-save buffering and Traffic Indication Map (TIM) processing
バッファリングとトラフィック指示マップ（TIM）処理をパワーセーブ
At the AC:
AC時：
Split MAC implementations of this kind may tunnel either 802.11 or 802.3 frames between the AC and the WTP.
この種のスプリットMAC実装はACとWTPとの間のトンネルのいずれか802.11又は802.3フレームもよいです。
For this sub-mode of the Split MAC architecture, the 802.11 AP functions are split as follows:
次のようにスプリットMACアーキテクチャのこのサブモードでは、802.11 AP機能が分割されています。
At the WTP:
WTPで：
Rate Adaptation
レートアダプテーション
Power-save buffering and TIM processing
バッファリングとTIM処理をパワーセーブ
At the AC:
AC時：
Split MAC implementations of this kind tunnel 802.11 frames between the AC and the WTP.
このようなトンネルのスプリットMAC実装ACとWTPの間の802.11フレーム。
The 802.11 Control Protocol has two components, one for transporting the specific control and provisioning messages and another to tunnel data traffic from the WTP to the AC.
802.11制御プロトコルは、2つの成分、具体的な制御を輸送し、WTPからACへのトンネルデータトラフィックにメッセージ及び他のプロビジョニングのための1つを有しています。
The SLAPP 802.11 Control Protocol uses the Generic Routing Encapsulation (GRE) [4] to encapsulate L2 frames. Depending on whether and how an architecture splits its MAC, some architectures may tunnel 802.11 frames directly to the AC while others may tunnel 802.3 frames, which may be optionally 802.1Q-tagged using tags assigned by the AC.
SLAPP 802.11制御プロトコル[4] L2フレームをカプセル化するために、汎用ルーティングカプセル化（GRE）を使用します。他のものは必要に応じてACによって割り当てられたタグを使用して、802.1Qタグ付けすることができるトンネル802.3フレーム、できるがアーキテクチャは、ACに直接そのMAC、いくつかのアーキテクチャ月トンネル802.11フレームを分割するかどうか、どのように依存します。
The delivery mechanism of these GRE packets is IP. Therefore, the IP protocol of the outer packet is 47, indicating a GRE header follows. When GRE encapsulates 802.11 frames, the ether type in the GRE header is TBD; when GRE encapsulates 802.3 frames, the ether type in the GRE header is TBD2.
これらのGREパケットの配信メカニズムはIPです。したがって、外側のパケットのIPプロトコルは、GREヘッダは以下を示し、47です。 GREは、802.11フレームをカプセル化する場合、GREヘッダーのエーテル系はTBDです。 GREは802.3フレームをカプセル化する場合、GREヘッダーのエーテル系はTBD2あります。
Since IP is the delivery mechanism, all issues governing fragmentation and reassembly are handled by [5].
IP配信機構であるため、フラグメンテーション及び再組み立てを支配するすべての問題は、[5]によって処理されます。
When using the 802.11 Control Protocol, the type of SLAPP message is four (4), "control protocol packet". In this case, a two (2) octet field is appended to the SLAPP header to indicate the control protocol type as shown in Figure 8. The SLAPP 802.11 Control Protocol takes place in the "Negotiated Control Protocol" phase of Section 4.1, and all SLAPP 802.11 Control Protocol messages are therefore secured by the security association created immediately prior to entering that phase.
802.11制御プロトコルを使用する場合、SLAPPメッセージの種類は、4つの（4）、「コントロール・プロトコル・パケット」です。図8に示すように、2つ（2）オクテットフィールドは、制御プロトコルタイプを示すためSLAPPヘッダに付加され、この場合、SLAPP 802.11制御プロトコルは、セクション4.1の「交渉制御プロトコル」相で行われ、すべてのしたがって、セキュリティアソシエーションによって固定されているSLAPP 802.11制御プロトコルメッセージは、そのフェーズに入る直前に作成しました。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 Control Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SLAPP Control Protocol Header
図8：SLAPP制御プロトコルヘッダ
Where valid 802.11 Control Protocol Types are:
有効802.11制御プロトコルの種類は次のとおりです。
1 : Registration Request - sent from WTP to AC
1：登録要求 - ACにWTPから送られました
2 : Registration Response - sent from AC to WTP
2：登録応答 - WTPにACから送られました
3 : De-Registration Request - sent by either WTP or AC
3：登録解除要求 - WTPまたはACのいずれかによって送信されます
4 : De-Registration Response - sent by the recipient of the corresponding request
4：登録解除応答 - 対応する要求の受信者が送信され
5 : Configuration Request - sent by WTP to AC
5：構成要求 - ACにWTPにより送信されました
6 : Configuration Response - sent by AC to WTP
6：構成応答 - WTPにACにより送信されました
7 : Configuration Update - sent by AC to WTP
7：構成の更新 - WTPにACにより送信されました
8 : Configuration Acknowledgment - sent by the WTP to AC
8：設定謝辞 - ACにWTPにより送信されました
9 : Status Request - sent by the AC to the WTP
9：ステータス要求 - WTPにACにより送信されました
10 : Status Response - sent by the WTP to the AC
10：ステータス応答 - ACにWTPにより送信されました
11 : Statistics Request - sent by the AC to the WTP
11：統計のリクエスト - WTPにACにより送信されました
12 : Statistics Response - sent by the WTP to the AC
12：統計レスポンス - ACにWTPにより送信されました
13 : Event - sent by the WTP to the AC
13：イベント - ACにWTPにより送信されました
14 : Keepalive - sent either way
14：キープアライブ - のいずれかの方法を送りました
15 : Key Config Request - sent by the AC to the WTP
15：キーコンフィグリクエスト - WTPにACにより送信されました
16 : Key Config Response - sent by the WTP to the AC
16：キーコンフィグレスポンス - ACにWTPにより送信されました
All basic configuration functions are applicable per-Extended Service Set Identifier (ESSID) per-radio in a WTP. Some WTPs MAY support more than one ESSID per-radio, while all WTPs MUST support at least one ESSID per-radio, which may be considered the primary ESSID in case of multiple ESSID support. All per-WTP configurations and capabilities (e.g., number of radios) are handled as part of the discovery and initialization process.
すべての基本的な設定機能は、WTPに当たり、無線ごとに、拡張サービスセット識別子（ESSID）適用されます。全てWTPsが複数のESSID支持体の場合には一次ESSIDと考えることができるあたりの無線少なくとも一つのESSIDをサポートする必要があるが、いくつかのWTPsは、毎無線つ以上のESSIDをサポートするかもしれません。全てごとWTPの構成および機能は、（例えば、無線の数）が発見と初期化プロセスの一部として扱われます。
The provisioning of the regulatory domain of a WTP is beyond the scope of this document. A WTP, once provisioned for a specific regulatory domain, MUST restrict the operational modes, channel, transmit power, and any other necessary limits based on the knowledge contained within its software image and hardware capabilities. The WTP MUST communicate its capabilities limited by the regulatory domain as well as by the WTP hardware, if any, to the AC during the capability exchange.
WTPの調節ドメインのプロビジョニングは、このドキュメントの範囲を超えています。一度特定の調節ドメインにプロビジョニングWTPは、、、、チャネルの動作モードを制限する送信電力を、そのソフトウェアイメージとハードウェアの能力の範囲内に含まれる知識に基づいて、その他の必要な制限をしなければなりません。 WTPは、能力交換時にACに、もしあれば、規制ドメインによってだけでなく、WTPのハードウェアによって制限され、その機能を通信する必要があります。
The allocation and assignment of Basic Service Set Identifiers (BSSIDs) to the primary interface and to the virtual access point (AP) interfaces, if supported, are outside the scope of this document.
プライマリインターフェイスおよび仮想アクセスポイント（AP）インタフェースへの割り当てと基本サービスセット識別子（のBSSID）の割り当ては、サポートされている場合、この文書の範囲外です。
Information elements (IEs) are used to communicate capability, configuration, status, and statistics information between the AC and the WTP.
情報要素（IE）の機能、構成、ステータス、およびACとWTPの間で統計情報を通信するために使用されます。
The structure of an information element is show below. The element ID starts with an element ID octet, followed by a 1-octet length, and the value of the element ID whose length is indicated in the Length field. The maximum length of an element is 255 octets.
情報要素の構造を以下に示してあります。要素IDは1オクテット長続く要素IDオクテット、および長さLengthフィールドに示されている要素のIDの値から始まります。要素の最大長は255オクテットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This element defines the MAC architecture modes (Section 6.1.1).
この要素は、MACアーキテクチャモード（6.1.1項）を規定します。
Element ID : 1
要素ID：1
Length : 1
長さ：1
Value : The following values are defined.
値：以下の値が定義されています。
Bit 0 : CAPWAP mode 1 - Local MAC, bridged mode
ビット0：CAPWAPモード1 - ローカルMAC、ブリッジモード
Bit 1 : CAPWAP mode 2 - Local MAC, tunneled mode
ビット1：CAPWAPモード2 - ローカルMAC、トンネリングされたモード
Bit 2 : CAPWAP mode 3 - Split MAC, WTP encryption, 802.3 tunneling
ビット2：CAPWAPモード3 - スプリットMAC、WTPの暗号化、802.3トンネリング
Bit 3 : CAPWAP mode 4 - Split MAC, WTP encryption, 802.11 tunneling
ビット3：CAPWAPモード4 - スプリットMAC、WTPの暗号化、802.11トンネリング
Bit 4 : CAPWAP mode 5 - Split MAC, AC encryption, 802.11 tunneling
ビット4：CAPWAPモード5 - スプリットMAC、ACの暗号化、802.11トンネリング
Bits 5-7 : Set to 0
ビット5-7：0に設定します
When this element is included in the capabilities message, then the setting of a bit indicates the support for this CAPWAP mode at the WTP. When this element is used in configuration and status messages, then exactly one of bits 0-4 MUST be set.
この要素は機能メッセージに含まれている場合、ビットの設定は、WTPでこのCAPWAPモードのサポートを示しています。この要素は、構成およびステータスメッセージで使用される場合、次に正確ビット0-4のいずれかに設定しなければなりません。
This element refers to the number of 802.11 WLANs present in the WTP.
この要素は、WTPに存在する802.11のWLANの数を指します。
Element ID : 2
要素ID：2
Length : 1
長さ：1
Value : 0-255
値：0〜255
This element is used to refer to a particular instance of a WLAN interface when used in configuration and status messages. When used within a recursion element, the elements within the recursion element correspond to the WLAN interface specified in this element.
この要素は、構成およびステータスメッセージで使用される場合、WLANインタフェースの特定のインスタンスを参照するために使用されます。再帰要素内で使用される場合、再帰要素内の要素は、この要素で指定されたWLANインタフェースに対応します。
Element ID : 3
エレメントID：3
Length : 1
長さ：1
Value : 0 - (Number of WLAN interfaces - 1)
値：0 - （WLANインターフェイスの数 - 1）
This element is the WLAN Interface hardware vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). This field appears once for each instance of WLAN interface present in the WTP.
この要素は、ネットワークオクテット順序（これらの企業コードから得られ、IANAに登録することができる）でWLANインタフェースハードウェアベンダのSMI企業コードです。このフィールドは、WTPに存在するWLANインターフェースのインスタンスごとに一度表示されます。
Element ID : 4
要素ID：4
Length : 4
長さ：4
Value : 32-bit value
値：32ビット値
This element is an ID assigned by the WLAN Interface hardware vendor to indicate the type of the WLAN interface. It is controlled by the hardware vendor and the range of possible values is beyond the scope of this document. This field appears once for each instance of a WLAN interface present in the WTP.
この要素は、WLANインタフェースのタイプを示すために、WLANインタフェースハードウェアベンダーによって割り当てられたIDです。これは、ハードウェアベンダーによって制御され、可能な値の範囲は、この文書の範囲外です。このフィールドは、WTPに存在するWLANインターフェースのインスタンスごとに一度表示されます。
Element ID : 5
要素ID：5
Length : 4
長さ：4
If a regulatory domain is provisioned in the WTP, then the WTP indicates this by including this element in the capabilities list. If this information is not available at the WTP, then this element SHOULD not be included in the capabilities list. The process by which this information is provisioned into the WTP is beyond the scope of this document.
規制ドメインはWTPでプロビジョニングされている場合、WTPは、能力リスト内でこの要素を含むことによって、これを示しています。この情報はWTPで利用できない場合、この要素は、機能のリストに含めることはできません。この情報はWTPにプロビジョニングされるプロセスは、この文書の範囲外です。
Element ID : 6
要素ID：6
Length : 4
長さ：4
Value : ISO code assigned to the regulatory domain
値：ISOコードは、規制ドメインに割り当て
This element indicates the list of 802.11 Physical Layer (PHY) modes supported by the WTP along with a list of channels and maximum power level supported for this mode. This element appears once for each instance of WLAN interface at the WTP. There could be multiple instances of this element if the WLAN interface supports multiple PHY types.
この要素は、チャネルと、このモードのためにサポートされる最大電力レベルのリストとともにWTPによってサポート802.11物理層（PHY）モードの一覧を示します。この要素は、WTPのWLANインタフェースのインスタンスごとに一度表示されます。 WLANインタフェースが複数のPHYタイプをサポートしている場合、この要素の複数のインスタンスがあるかもしれません。
Element ID : 7
要素ID：7
Length : Variable
長さ：可変
Valid : This field consists of
有効：このフィールドは、で構成されてい
PHY mode : With a length of 1 octet with values as follows:
PHYモード：次のように値を持つ1つのオクテットの長さ：
0 : Radio Disabled/Inactive
0：ラジオ無効/非アクティブ
1 : IEEE 802.11b
1：IEEE 802.11bの
2 : IEEE 802.11g
2：IEEE 802.11グラム
3 : IEEE 802.11a
3：IEEE 802.11aの
4-255 : Reserved
4-255：予約
Power Level : In the capabilities messages, this indicates the maximum power level supported in this mode by the WTP; while in the configuration and status messages, this field indicates the desired power level or the current power level that the WTP is operating at. The field has a length of 1 octet and the power level is indicated in dBm.
電力レベルは：機能のメッセージでは、これはWTPで、このモードでサポートされる最大電力レベルを示します。コンフィギュレーションおよびステータスメッセージにある間、このフィールドは、所望の電力レベルまたはWTPがで動作している現在の電力レベルを示しています。フィールドは、1つのオクテットの長さを有し、電力レベルはdBmで示されています。
Channel Information : A variable number of 2-octet values that indicate the center frequencies (in KHz) of all supported channels in this PHY mode.
チャンネル情報：このPHYモードではサポートされているすべてのチャンネルの（キロヘルツで）中心周波数を示す2オクテット値の可変数。
When this element is used in configuration and status messages, the Power Level field indicates the desired or current operating power level. The Channel field has exactly one 2-octet value indicating the desired or current operating frequency.
この要素は、構成およびステータスメッセージで使用されるとき、電力レベルフィールドは、所望の又は現在の動作電力レベルを示しています。チャネルフィールドは、所望の又は現在の動作周波数を示す正確に1つの2オクテットの値を有します。
In the capabilities message, this element contains the list of cryptographic algorithms that are supported by the WTP. This appears once for each instance of the WLAN interface present in the WTP. In configuration and status messages, this element is used to indicate the configured cryptographic capabilities at the WTP.
能力メッセージでは、この要素はWTPによってサポートされている暗号化アルゴリズムのリストが含まれています。これはWTPに存在するWLANインターフェースのインスタンスごとに一度表示されます。コンフィギュレーションおよびステータスメッセージでは、この要素は、WTPで構成された暗号機能を示すために使用されます。
Element ID : 8
エレメントID：8
Length : 1
長さ：1
Value : The following bits are defined:
値：次のビットが定義されています。
Bit 0 : WEP
ビット0：WEP
Bit 1 : TKIP
ビット1：TKIP
Bit 2 : AES-CCMP
ビット2：AES-CCMP
Bits 3-7 : Reserved
ビット3-7：予約済み
This element contains a bitmap indicating support at the WTP for various IEEE 802.11 standards.
この要素は、様々なIEEE 802.11規格のWTPでのサポートを示すビットマップが含まれています。
Element ID : 9
要素ID：9
Length : 4
長さ：4
Value : A bitmap as follows:
値：次のようにビットマップ：
Bit 0 : WPA
ビット0：WPA
Bit 1 : 802.11i
ビット1：802.11iの
Bit 2 : WMM
ビット2：WMM
Bit 3 : WMM-SA
ビット3：WMM-SA
Bit 4 : U-APSD
ビット4：U-APSD
Bits 5-32 : Reserved
ビット5-32：予約済み
In the capabilities message, this element is formatted as follows
次のように能力メッセージでは、この要素がフォーマットされています
Element ID : 10
要素ID：10
Length : 4
長さ：4
Value : Formatted as follows:
値：次のようにフォーマットされました：
Bits 0-7 : Number of Antennae
ビット0-7：アンテナの数
Bit 8 : Individually Configurable, 0 = No, 1 = Yes
ビット8：はい= 0 =いいえ、1、個別に設定
Bit 9 : Diversity support, 0 = No, 1 = Yes
ビット9：多様性のサポート、0 =いいえ、1 =はい
Bit 10 : 0 = Internal, 1 = External
ビット10：0 =内部、1 =外部
Bits 11-31 : Reserved
ビット11-31：予約
In configuration and status messages, this element is formatted as follows:
以下のような構成とステータスメッセージでは、この要素がフォーマットされます。
Element ID : 10
要素ID：10
Length : 4
長さ：4
Value : Formatted as follows:
値：次のようにフォーマットされました：
Bits 0-7 : Antenna Number - is a number between 0 and the number of antennae indicated by the WTP. The value is valid only if Bit 8 is set; otherwise, it MUST be ignored.
ビット0-7：アンテナ数 - 0の間の数とWTPで示されるアンテナの数です。値は、ビット8が設定されている場合にのみ有効です。そうでない場合は、それを無視しなければなりません。
Bit 8 : Antenna Select - if this bit is reset, then the antenna selection is left to the algorithm on the WTP. If this bit is set, then the Antenna Number field indicates the antenna that should be used for transmit and receive.
ビット8：アンテナの選択 - このビットがリセットされている場合は、アンテナの選択は、WTPのアルゴリズムに任されています。このビットが設定されている場合、アンテナ番号フィールドは、送信のために使用され、受信されるべきアンテナを示しています。
Bits 9-31 : Reserved
ビット9-31：予約済み
This element indicates the number of BSSIDs supported by the WLAN interface. This element is optional in the capabilities part of the registration request message, and if it is absent, then the number of BSSIDs is set to 1. This element appears once for each instance of a WLAN interface present in the WTP.
この要素は、WLANインタフェースによってサポートされるのBSSIDの数を示します。この要素は、登録要求メッセージの機能部分に任意であり、それが存在しない場合、その後のBSSIDの数が1に設定され、この要素は、WTPに存在するWLANインタフェースのインスタンスごとに一度表示されます。
Element ID : 11
要素ID：11
Length : 1
長さ：1
Value : The number of BSSIDs that the WLAN interface is capable of supporting.
値：WLANインタフェースがサポートすることができるのBSSIDの数。
This element is used when sending configuration or status specific to a certain BSSID in the WTP.
WTPで特定BSSIDに固有の設定またはステータスを送信するとき、この要素が使用されます。
Element ID : 12
要素ID：12
Length : 1
長さ：1
Valid values are from 0 to (Number of BSSIDs -1)
有効値は0から（のBSSIDの数-1）であります
This element is used in configuration and status messages to either configure the ESSID on a certain BSSID or report the current operating value.
この要素は、特定のBSSIDにESSIDを設定したり、現在のオペレーティング値を報告するいずれの構成とステータスメッセージで使用されます。
Element ID : 13
要素ID：13
Length : Variable, between 0 and 32 both inclusive.
長さ：可変、0〜32以下です。
Value : Variable, contains ASCII characters.
値：変数は、ASCII文字が含まれています。
There is no default value for this parameter.
このパラメータのデフォルト値はありません。
This element is used in configuration and status messages to control the announcement of the ESSID in 802.11 beacons. For the Local MAC modes of operation, this field is also used to control whether the WTP should respond to Probe Requests that have a NULL ESSID in them.
この要素は、802.11ビーコンにESSIDの発表を制御するための設定およびステータスメッセージで使用されます。操作のローカルMACモードの場合、このフィールドは、WTPがそれらにNULL ESSIDを持つプローブ要求に応答するかどうかを制御するために使用されます。
Element ID : 14
要素ID：14
Length : 1
長さ：1
Value : Defined as follows:
値：次のように定義されます：
Bit 0 : ESSID announcement, 0 = Hide ESSID, 1 = Display ESSID in 802.11 beacons. The default value for this bit is 1.
ビット0：ESSIDアナウンス、0 =非表示ESSID、802.11ビーコン1 =表示ESSID。このビットのデフォルト値は1です。
Bit 1 : Probe Response policy, 0 = Respond to Probe Requests that contain a NULL ESSID, 1 = Respond only to Probe Requests that match the configured ESSID. The default value for this bit is 0.
ビット1：プローブ応答ポリシー、0 =応答し、NULL ESSIDを含むプローブ要求1 =構成ESSIDと一致する要求をプローブにのみ応答します。このビットのデフォルト値は0です。
Bit 2-7 : Reserved
ビット2-7：予約済み
This element is used to configure the beacon interval on a BSSID on the WTP.
この要素は、WTPのBSSIDにビーコン間隔を設定するために使用されます。
Element ID : 15
要素ID：15
Length : 2
長さ：2
Value : Valid values for the beacon interval as allowed by IEEE 802.11
値：ビーコン間隔の有効な値は、IEEE 802.11によって許容されるよう
The default value for this parameter is 100.
このパラメータのデフォルト値は100です。
This element is used to configure the DTIM period on a BSSID present on the WTP.
この要素はWTPに存在BSSIDにDTIM期間を設定するために使用されます。
Element ID : 16
要素ID：16
Length : 2
長さ：2
Value : Valid values for the DTIM period as allowed by IEEE 802.11.
値：IEEE 802.11によって許可されたDTIM期間の有効な値。
The default value for this parameter is 1.
このパラメータのデフォルト値は1です。
Configure or report the configured set of basic rates.
基本料金の構成されたセットを設定したり報告しています。
Element ID : 17
要素ID：17
Length : 4
長さ：4
Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a basic rate. If the bit is reset, then the rate is not to be configured as a basic rate.
値は次のように次のリスト内のビットの各々は解釈されます。ビットが設定されている場合、その特定のレートは、基本レートとして構成されるべきです。ビットがリセットされる場合、レートは、基本レートとして構成されるべきではありません。
Bit 0 : 1 Mbps
ビット0：1 Mbpsの
Bit 1 : 2 Mbps
ビット1：2 Mbpsの
Bit 2 : 5.5 Mbps
ビット2：5.5 Mbpsの
Bit 3 : 11 Mbps
ビット3：11 Mbpsの
Bit 4 : 6 Mbps
ビット4：6 Mbpsの
Bit 5 : 9 Mbps
ビット5：9 Mbpsの
Bit 6 : 12 Mbps
ビット6：12 Mbpsの
Bit 7 : 18 Mbps
ビット7：18 Mbpsの
Bit 8 : 24 Mbps
ビット8：24 Mbpsの
Bit 9 : 36 Mbps
ビット9：36 Mbpsの
Bit 10 : 48 Mbps
ビット10：48 Mbpsの
Bit 11 : 54 Mbps
ビット11：54 Mbpsの
Bits 12-31 : Reserved
ビット12-31：予約
Configure or report the configured set of basic rates.
基本料金の構成されたセットを設定したり報告しています。
Element ID : 18
エレメントID：18
Length : 4
長さ：4
Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a supported rate. If the bit is reset, then the rate is not to be configured as a supported rate.
値は次のように次のリスト内のビットの各々は解釈されます。ビットが設定されている場合、その特定のレートがサポートされたレートとして構成されるべきです。ビットがリセットされると、その後、レートがサポートされたレートとして構成されるべきではありません。
Bit 0 : 1 Mbps
ビット0：1 Mbpsの
Bit 1 : 2 Mbps
ビット1：2 Mbpsの
Bit 2 : 5.5 Mbps
ビット2：5.5 Mbpsの
Bit 3 : 11 Mbps
ビット3：11 Mbpsの
Bit 4 : 6 Mbps
ビット4：6 Mbpsの
Bit 5 : 9 Mbps
ビット5：9 Mbpsの
Bit 6 : 12 Mbps
ビット6：12 Mbpsの
Bit 7 : 18 Mbps
ビット7：18 Mbpsの
Bit 8 : 24 Mbps
ビット8：24 Mbpsの
Bit 9 : 36 Mbps
ビット9：36 Mbpsの
Bit 10 : 48 Mbps
ビット10：48 Mbpsの
Bit 11 : 54 Mbps
ビット11：54 Mbpsの
Bits 12-31 : Reserved
ビット12-31：予約
This element is used to configure long and short retries for each BSSID present on the WTP.
この要素はWTPに存在する各BSSIDのために長い及び短い再試行を設定するために使用されます。
Element ID : 19
要素ID：19
Length : 2
長さ：2
Value : as follows:
値：次のように：
Bits 0-7 : Short retry count, default value is 3.
ビット0-7：ショート再試行回数、デフォルト値は3です。
Bits 8-15 : Long retry count, default value is 3.
ビット8-15：ロング再試行回数、デフォルト値は3です。
This element is used to configure the fragmentation threshold on a BSSID present on the WTP.
この要素はWTPに存在BSSIDにフラグメンテーションしきい値を設定するために使用されます。
Element ID : 20
エレメントID：20
Length : 2
長さ：2
Value : Valid values for the fragmentation threshold as allowed by IEEE 802.11.
値：IEEE 802.11によって許可されフラグメンテーションしきい値の有効な値。
The default value for this parameter is 2346.
このパラメータのデフォルト値は2346です。
This element is used to configure the Request to Send (RTS) threshold on a BSSID present on the WTP.
この要素はWTPに存在BSSIDに（RTS）しきい値を送信するための要求を設定するために使用されます。
Element ID : 21
要素ID：21
Length : 2
長さ：2
Value : Valid values for RTS threshold as allowed by IEEE 802.11.
値：RTSしきい値の有効な値は、IEEE 802.11によって許可されました。
The default value for this parameter is 2346.
このパラメータのデフォルト値は2346です。
This element is used to configure the preamble type used for transmission in 802.11b mode.
この要素は、802.11bのモードでの伝送のために使用されるプリアンブル・タイプを設定するために使用されます。
Element ID : 22
要素ID：22
Length : 1
長さ：1
Value : Defined as follows:
値：次のように定義されます：
0 : Disable Short preamble
0：ショートプリアンブルを無効にします
1 : Enable Short preamble
1：ショートプリアンブルを有効にします
2-255 : Reserved
2-255：予約
The default value for this parameter is 0.
このパラメータのデフォルト値は0です。
This element is used to configure the tagging of packets belonging to a particular SSID when transferred between the AC and the WTP in CAPWAP modes 2-3, or before the WTP bridges the 802.3 frame to its wired interface when operating in CAPWAP mode 1.
この要素は、CAPWAPモード2-3 ACとWTPとの間で転送される場合、またはCAPWAPモード1で動作しているときWTPが有線インタフェースを802.3フレームをブリッジする前に、特定のSSIDに属するパケットのタグ付けを設定するために使用されます。
Element ID : 23
要素ID：23
Length : 2
長さ：2
Value : 802.1Q tag
値：802.1Qタグ
If this element is absent in the configuration, then the WTP MUST assume that no tagging is required and should expect to receive untagged frames on frames destined towards the wireless interface.
この要素は、構成に存在しない場合、WTPにはタグ付けが必要とされないと仮定しなければならなくて、無線インタフェース向かっ宛てのフレームにタグなしフレームを受信することを期待すべきです。
A successful registration response from an AC to a WTP MUST contain this element. It is used in messages between the WTP and the AC on all other messages during the duration for which the registration is active.
WTPにACから成功した登録応答は、この要素を含まなければなりません。これは、登録が有効な期間中、他のすべてのメッセージにWTPとACとの間のメッセージに使用されます。
Element ID : 24
要素ID：24
Length : 4
長さ：4
Value : A 32-bit unsigned number allocated by the AC
値：ACによって割り当てられた32ビットの符号なし数
The AC uses this element to assign a string of ASCII characters to the WTP.
ACは、WTPにASCII文字の文字列を割り当てるには、この要素を使用しています。
Element ID : 25
要素ID：25
Length : Variable, between 0 and 64 both inclusive
長さ：可変、0〜64の両方を含め
Value : A variable length string of ASCII characters
値：ASCII文字の可変長文字列
The AC uses this element to assign importance to events, enable or disable notification, and to configure the global event notification policy. When the Event Identifier is 0, this element serves as a global notification policy message. The bitmap indicates the types of events that require the WTP to generate a notification. When the Event Identifier is non-zero, this element is used to configure a specific event for notification and its importance level. The importance level is specified by setting exactly one bit in the bitmap. If none of the bits are set in the bitmap, the element should be interpreted as a cancellation request. The WTP should stop sending notifications for the corresponding event specified in the Element Identifier.
ACは、イベントへの重要性を割り当て、通知を有効化または無効化、およびグローバルイベント通知ポリシーを設定するには、この要素を使用しています。イベント識別子が0である場合、この要素は、グローバル通知ポリシーメッセージとして働きます。ビットマップは、通知を生成するためのWTPが必要なイベントの種類を示します。イベント識別子が非ゼロである場合、この要素は、通知とその重要度のために特定のイベントを構成するために使用されます。重要度は、ビットマップに正確に1ビットを設定することによって指定されます。ビットのどれがビットマップに設定されていない場合、要素は解除要求として解釈されるべきです。 WTPは、要素識別子で指定された対応するイベントの通知の送信を停止する必要があります。
Element ID : 26
要素ID：26
Length : 4
長さ：4
Value : Defined as follows:
値：次のように定義されます：
Bits 0 - 15: Event Identifier
イベント識別子：15 - ビット0
Bit 16: Fatal - The system is not usable.
ビット16：致命的 - システムが使用できません。
Bit 17: Alert - Immediate action is required.
ビット17：アラート - 即時アクションが必要です。
Bit 18: Critical
ビット18：クリティカル
Bit 19: Error
ビット19：エラー
Bit 20: Warning
ビット20：警告
Bit 21: Notification
ビット21：通知
Bit 22: Informational
ビット22：情報
Bit 23: Debug
ビット23：デバッグ
Bits 24 - 31: Reserved
ビット24から31：予約済み
The AC uses this element to indicate the mode of operation for the radio for each WLAN interface.
ACは、各WLANインタフェースのための無線の動作モードを示すために、この要素を使用します。
Element ID : 27
要素ID：27
Length : 1
長さ：1
Value : The following are valid values:
値：以下の有効な値は次のとおりです。
0 : Radio is disabled
0：ラジオは無効になっています
1 : Radio is enabled
1：ラジオが有効になっています
2-255 : Reserved
2-255：予約
The AC uses this element to configure 802.11e functions at the WTP.
ACは、WTPで802.11eの機能を設定するには、この要素を使用しています。
Element ID : 28
要素ID：28
Length : 4
長さ：4
Value : A bitmap as follows:
値：次のようにビットマップ：
Bit 0 : WMM
ビット0：WMM
Bit 1 : WMM-SA
ビット1：WMM-SA
Bit 2 : U-APSD
ビット2：U-APSD
Bits 3-32 : Reserved
ビット3-32：予約済み
This element defines the statistics relating to configuration and registration events as seen by the WTP.
この要素は、WTPによって見られるような構成と登録イベントに関する統計を定義します。
Element ID : 29
要素ID：29
Length : 32
長さ：32
Value : The value is as follows:
値は次のように値は次のとおりです。
* Configuration Requests : 4 octets - Number of Configuration Request messages sent by the WTP since the last reboot or reset of the counters.
*構成要求：4つのオクテット - カウンタの最後の再起動またはリセット以降WTPにより送信された構成要求メッセージの数。
* Configuration Responses : 4 octets
*設定の応答：4つのオクテット
* Configuration Updates : 4 octets
*設定更新：4つのオクテット
* Configuration ACKs : 4 octets
*設定のACK：4つのオクテット
* Registration Requests : 4 octets
*登録要求：4つのオクテット
* Registration Responses : 4 octets
*登録応答：4つのオクテット
* De-Registration Requests : 4 octets
*登録解除要求：4つのオクテット
* De-Registration Responses : 4 octets
*登録解除応答：4つのオクテット
This information element contains a set of counters relating to the transmit side of the wireless link at the WTP. These counters apply to either a BSS or an Access Category (if Wireless Multimedia (WMM) is enabled).
この情報要素は、WTPでの無線リンクの送信側に関連するカウンタのセットが含まれています。これらのカウンタはBSSまたは（無線マルチメディア（WMM）が有効になっている場合）アクセスカテゴリのいずれかに適用されます。
Element ID : 30
要素ID：30
Length : 112 octets
長さ：112個のオクテット
Value : The value of this element is defined as follows:
値は以下のように、この要素の値が定義されています。
* Total received from the network : 4 octets
*合計は、ネットワークから受信：4つのオクテット
* Successfully transmitted frames (total) : 4 octets
*正常に送信されたフレーム（合計）：4つのオクテット
* Successfully transmitted 802.11 Mgmt frames : 4 octets
*正常に送信802.11 Mgmt（仮想ディスクの管理）フレーム：4つのオクテット
* Successfully transmitted 802.11 Data frames : 4 octets
*正常に送信802.11データフレーム：4つのオクテット
* Transmitted 802.11 Control frames : 4 octets
*透過802.11制御フレーム：4つのオクテット
* Frames that reached max-retry limit : 4 octets
MAX-再試行回数の上限に達した*フレーム：4つのオクテット
* Transmitted frames with 1 retry attempt : 4 octets
4つのオクテット：1回の再試行と*送信されたフレーム
* Transmitted frames with 2 retry attempts : 4 octets
4つのオクテット：2回の再試行と*送信されたフレーム
* Transmitted frames with more than 2 retry attempts : 4 octets
2回の以上の再試行を持つ*送信されたフレーム：4つのオクテット
* Frames transmitted at each 802.11 PHY rate : 12*4 octets - The counters indicate the number of frames at each of the following rates, respectively: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mbps.
*フレームは、それぞれ802.11 PHYレートで送信：12 * 4オクテット - カウンタは、それぞれ、以下のレートの各々でフレームの数を示します、1、2、5.5、11、6、9、12、18、24、36 48、54 Mbpsの。
* Total frame dropped : 4 octets
*合計フレームはドロップ：4つのオクテット
* Frames dropped due to insufficient resources : 4 octets
*フレームはリソース不足のため落とさ：4つのオクテット
* Frames dropped due to power-save timeouts : 4 octets
4つのオクテット：*フレームが原因節電タイムアウトに下がりました
* Frames dropped due to other reasons : 4 octets
*フレームは、その他の理由に下がっ：4つのオクテット
* Fragments transmitted : 4 octets
*フラグメント送信さ：4つのオクテット
* Fragments dropped : 4 octets
*フラグメントはドロップ：4つのオクテット
* Power-save multicast frames : 4 octets
*パワーセーブマルチキャストフレーム：4つのオクテット
* Power-save unicast frames : 4 octets
*パワーセーブユニキャストフレーム：4つのオクテット
This information element includes all statistics related to the reception of the frames by WTP. These counters apply to either a BSS or an Access Category (if WMM is enabled).
この情報要素は、WTPにより、フレームの受信に関連するすべての統計情報が含まれています。これらのカウンタはBSSまたは（WMMが有効になっている場合）アクセスカテゴリのいずれかに適用されます。
Element ID : 31
要素ID：31
Length : 108 octets
長さ：108個のオクテット
Value : The value of this element is defined as follows:
値は以下のように、この要素の値が定義されています。
* Total Frames received : 4 octets
*合計フレームは受信：4つのオクテット
* Frames with the retry bit set : 4 octets
リトライビットがセットされた*フレーム：4つのオクテット
* 802.11 Data frames received : 4 octets
* 802.11データフレームは受信：4つのオクテット
* 802.11 Mgmt frames received : 4 octets
受信* 802.11 Mgmt（仮想ディスクの管理）フレーム：4つのオクテット
* 802.11 Control frames received : 4 octets
受信* 802.11制御フレーム：4つのオクテット
* Cyclic Redundancy Check (CRC) errors : 4 octets
*巡回冗長検査（CRC）エラー：4つのオクテット
* PHY errors : 4 octets
* PHYエラー：4つのオクテット
* Total Fragments received : 4 octets
*合計フラグメントは受信：4つのオクテット
* Reassembled frames : 4 octets
*再構築したフレーム：4つのオクテット
* Reassembly failures : 4 octets
*再構築の失敗：4つのオクテット
* Successful Decryption : 4 octets
*成功した復号化：4つのオクテット
* Decryption failures : 4 octets
*復号化の失敗：4つのオクテット
* Rate statistics : 48 octets - The number of frames received at each of the 802.11 PHY rates, respectively - 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 49, 54 Mbps.
*レート統計：48個のオクテット - それぞれ802.11 PHYレートの各々で受信されたフレームの数、 - 1、2、5.5、11、6、9、12、18、24、36、49、54 Mbpsの。
* Total frames dropped : 4 octets
*合計フレームは廃棄：4つのオクテット
* Frames dropped due to insufficient resources : 4 octets
*フレームはリソース不足のため落とさ：4つのオクテット
* Frames dropped due to other reasons : 4 octets
*フレームは、その他の理由に下がっ：4つのオクテット
This element includes information about the current stations associated with the BSS.
この要素は、BSSに関連付けられている現在のステーションについての情報を含んでいます。
Element ID : 32
要素ID：32
Length : Variable
長さ：可変
Value : The value is defined as follows:
値：次のように値が定義されます。
* Total association requests : 4 octets
*合計アソシエーション要求：4つのオクテット
* Total associations accepted : 4 octets
受け入れ*総協会：4つのオクテット
* Total associations rejected : 4 octets
*合計団体は拒否：4つのオクテット
* Current associations : 4 octets
*現在協会：4つのオクテット
* For each associated station,
*各関連局に対して、
+ Station MAC address : 6 octets
+駅MACアドレス：6つのオクテット
+ Power save state : 1 octet
+電源状態を保存する：1つのオクテットを
+ Current Tx rate : 1 octet
+現在の送信レート：1つのオクテット
+ Rate of last packet : 1 octet
最後のパケットの+率：1つのオクテット
+ Preamble type : 1 octet
+プリアンブルタイプ：1つのオクテット
+ WMM/U-APSD state : 1 octet
+ WMM / U-APSD状態：1オクテット
The status IE is included in the status response message sent by the WTP to the AC. It contains a set of fields that are used to indicate the status of various states at the WTP or each BSS configured in the WTP.
ステータスIEは、ACにWTPによって送信されたステータス応答メッセージに含まれています。これは、WTPまたはWTPで設定された各BSSにおける様々な状態のステータスを示すために使用されるフィールドのセットを含みます。
Element ID : 33
要素ID：33
Length : 2 octets
長さ：2つのオクテット
Value : The value is defined as follows:
値：次のように値が定義されます。
Enterprise Resource Planning (ERP) element, if applicable. If not applicable, then this field MUST be set to 0.
エンタープライズ・リソース・プランニング（ERP）要素、該当する場合。適用できない場合、このフィールドは0に設定しなければなりません。
Noise Floor : 1 octet
ノイズフロア：1つのオクテット
This element is used by the AC to configure the set of events that it wants to be notified by the WTP.
この要素は、WTPで通知することを希望する一連のイベントを構成するためにACで使用されています。
Element ID : 34
要素ID：34
Length : 4 octets
長さ：4つのオクテット
Value : The value is defined as follows:
値：次のように値が定義されます。
* Radar Detection - 1 octet
*レーダー検出 - 1つのオクテット
+ Bit 0 : 1 = notify on detecting radar interference, 0 otherwise.
+ビット0：1 =レーダー干渉、そうでなければ0を検出することに通知します。
+ Bit 1 : 1 = notify of channel change due to radar interference, 0 otherwise.
+ビット1：1 =さもなければによるレーダー干渉0にチャネル変更を通知します。
+ All other bits are reserved.
+他のすべてのビットは予約されています。
* Excessive Retry Event - 1 octet. Number of successive frames that have not been acknowledged by a client. A value of 0 disables notification.
*過度のリトライイベント - 1つのオクテット。クライアントによって承認されていない連続したフレームの数。 0の値は、通知を無効にします。
* Noise Floor Threshold - 1 octet. Defines the threshold above which an event would be generated by the WTP.
*ノイズフロア・スレッショルド - 1つのオクテット。イベントはWTPによって生成されるであろう上記のしきい値を定義します。
* 802.11 Management and Action Frame Notification - 1 octet.
* 802.11管理およびアクションフレームの通知 - 1つのオクテット。
+ Bit 0 : If set, notify the AC of Probe Requests from stations (please use with caution). If reset, then no Probe Response notification is needed.
+ビット0：セットは、局からのプローブ要求のACを通知した場合（注意して使用してください）。リセットした場合、その後、何のプローブ応答通知は必要ありません。
+ Bit 1 : If set, the WTP should notify the AC of all other management frames from stations.
+ビット1：設定されている場合、WTPは、ステーションからのすべての他の管理フレームの交流を通知しなければなりません。
+ All other bits are reserved.
+他のすべてのビットは予約されています。
This element is used by the WTP to notify the AC of the detection of radar interference and any channel changes as a result of this detection.
この要素は、この検出の結果として、レーダ干渉及び任意のチャネルの変化の検出のACを通知するためにWTPによって使用されます。
Element ID : 35
要素ID：35
Length : 10 octets
長さ：10個のオクテット
Value : Defined as follows:
値：次のように定義されます：
BSSID : 6 octets. The BSSID of the WLAN interface that detected the radar interference.
BSSID：6つのオクテット。レーダー干渉を検出し、WLANインタフェースのBSSID。
Channel : 2 octets. The channel on which radar interference was detected.
チャンネル：2つのオクテット。レーダー干渉が検出されたチャネル。
New Channel : 2 octets. The new channel to which the WTP moved as a result of the detection of radar interference.
新チャンネル：2つのオクテット。 WTPがレーダ干渉の検出の結果として、移動先の新しいチャネル。
This element is used by the WTP to indicate excessive retry events on transmission to an associated station.
この要素は、関連付けられた局への送信に過度のリトライイベントを示すために、WTPにより使用されます。
Element ID : 36
要素ID：36
Length : 14 octets
長さ：14個のオクテット
Value : Defined as follows:
値：次のように定義されます：
Station MAC : 6 octets
駅MAC：6つのオクテット
Associated BSSID : 6 octets
関連するBSSID：6つのオクテット
Length of last burst of excessive retries : 2 octets.
2つのオクテット：過度の再試行の最後のバーストの長さ。
This element is used by the WTP to notify the AC of the current noise floor at one of the WLAN interfaces exceeding the configured noise floor threshold.
この要素は、設定ノイズフロア閾値を超えるWLANインタフェースの一方に電流ノイズフロアのACを通知するためにWTPによって使用されます。
Element ID : 37
要素ID：37
Length : 10 octets
長さ：10個のオクテット
Value : Defined as follows:
値：次のように定義されます：
BSSID : 6 octets
BSSID：6つのバイト
Current Channel : 2 octets
現在のチャンネル：2つのオクテット
Current Noise Floor : 2 octets
電流ノイズフロア：2つのオクテット
This element provides a generic capability for either a WTP or an AC to send a raw 802.11 frame to the other party. For example, it can be used to notify the AC of station association/disassociation events in the case of Local MAC architectures.
この要素は、相手に生の802.11フレームを送信するためのWTPまたはACのいずれかのための汎用的な機能を提供します。例えば、ローカルMACアーキテクチャの場合のAC局の会合/解離イベントを通知するために使用することができます。
Element ID : 252
エレメントID：252
Length : Variable
長さ：可変
Value : A raw 802.11 frame
値：生の802.11フレーム
This element is used to transfer vendor-specific information between the WTP and the AC.
この要素は、WTPとACとの間のベンダー固有の情報を転送するために使用されます。
Element ID : 253
エレメントID：253
Length : Variable, > 3
長さ：可変、> 3
Value : This variable-length element starts with a 3-octet Organizationally Unique Identifier (OUI), followed by a series of octets that are specific to the vendor represented by the OUI.
値：この可変長要素は、OUIで表されるベンダーに固有のオクテットの一連続く3オクテット組織固有識別子（OUI）、始まります。
This element type can be used to recursively define a variable-length element that should be interpreted as a series of other elements defined in this section. It can be used to bound a set of elements as a unit.
この要素タイプは、再帰的に、このセクションで定義された他の一連の要素として解釈されるべき可変長の要素を定義するために使用することができます。これは、ユニットなどの要素の集合を結合するために使用することができます。
Element ID : 254
エレメントID：254
Length : Variable
長さ：可変
Value : A variable length element that contains a set of one or more elements defined in this section.
値：このセクションで定義された1つの以上の要素のセットを含む可変長素子。
This is a generic element type that can be used to pad the packets, if necessary.
これは、必要に応じて、パッドにパケットを使用することができる一般的な要素タイプです。
Element ID : 255
エレメントID：255
Length : Variable
長さ：可変
Value : A variable-length element that MUST be filled with all 0s at the source and MUST be ignored at the destination.
値：ソースにすべて0で充填しなければならなくて、先に無視しなければなりません可変長要素。
At the start of the SLAPP 802.11 Control Protocol, the WTP sends a registration request to the AC that it authenticated with. The registration request carries a list of information elements indicating the WTP's capabilities to the AC. The message starts with the SLAPP 802.11 Control Protocol header (Figure 8) with a SLAPP Control Protocol message type of 1.
SLAPP 802.11制御プロトコルの開始時に、WTPは、それがで認証することをACに登録要求を送信します。登録要求は、ACにWTPの能力を示す情報要素のリストを運びます。メッセージは、1のSLAPP制御プロトコルメッセージタイプとSLAPP 802.11制御プロトコル・ヘッダ（図8）から始まります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SLAPP 802.11 Registration Request
図9：SLAPP 802.11登録要求
Flags : Reserved
フラグ：予約
Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request.
トランザクションID：新規登録フェーズの開始時にWTPにより選択された32ビットの乱数。この番号は、対応する要求への応答を一致させるためにACによって登録応答に使用されます。
The following information elements are mandatory in the capabilities exchange:
以下の情報要素は、機能交換に必須です。
1 : CAPWAP mode
1：CAPWAPモード
2 : Number of WLAN interfaces
2：WLANインターフェイスの数
For each WLAN interface:
各WLANインタフェースの場合：
7 : 802.11 PHY mode and Channel Information
7：802.11 PHYモードとチャネル情報
8 : Cryptographic Capability
8：暗号化機能
9 : Other 802.11 standards support
9：他の802.11規格のサポート
The following information elements may be optionally included in the registration request:
以下の情報要素は、必要に応じて、登録要求に含まれていてもよいです。
For each WLAN interface:
各WLANインタフェースの場合：
4 : WLAN Interface HW Vendor ID
4：WLANインターフェースHWベンダーID
5 : WLAN Interface Type ID
5：WLANインターフェイスタイプID
6 : Regulatory Domain
6：規制区域
10 : Antenna Information Element
10：アンテナ情報要素
11 : Number of BSSIDs
11：のBSSIDの数
253 : Vendor-Specific Element
253：ベンダー固有の要素
Upon receiving a registration request, the AC may either chose to accept the WTP or reject its registration request.
登録要求を受信すると、ACは、WTPを受け入れるか、その登録要求を拒否することを選択したのいずれかでよいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SLAPP 802.11 Registration Response
図10：SLAPP 802.11登録応答
Flags :
フラグ：
Bit 0 : Indicates the status of the transaction, 0 = successful response from the AC, 1 = the registration request is being rejected by the AC.
ビット0：ACから0 =正常な応答、1 =登録要求がACによって拒否され、トランザクションの状態を示します。
Bits 1-7 : Reserved
ビット1-7：予約済み
Bits 8-15 : If bit 0 = 1 (i.e., the registration request is being rejected by the AC), then this field contains a reason code. Otherwise, these bits are currently set to 0. The following reason codes are currently defined:
ビット8-15は：ビット0 = 1（すなわち、登録要求はACによって拒否されている）場合、このフィールドは、理由コードを含みます。そうでなければ、これらのビットは現在、以下の理由コードは、現在定義されて0に設定されています。
0 : Reserved
0：予約済み
1 : Unspecified reason
1：未指定の理由
2 : Unable to handle more WTPs
2：より多くのWTPsを処理することができません。
3 : Incompatible capabilities
3：互換性のない機能
4-255 : Reserved
4-255：予約
Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request.
トランザクションID：新規登録フェーズの開始時にWTPにより選択された32ビットの乱数。この番号は、対応する要求への応答を一致させるためにACによって登録応答に使用されます。
The following information elements are mandatory if the transaction is successful:
トランザクションが成功した場合、以下の情報要素は必須です。
1 : CAPWAP mode - the mode that the AC chooses from among the list of supported modes sent by the WTP in the registration request.
1：CAPWAPモード - ACは、登録要求にWTPによって送信されたサポートされるモードのリストの中から選択するモード。
24 : SLAPP registration ID
24：登録IDをRELAX
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SLAPP 802.11 De-Registration Request
図11：SLAPP 802.11登録解除要求
Flags : Reserved
フラグ：予約
SLAPP Registration ID : The registration ID assigned by the AC upon successful registration.
SLAPP登録ID：成功登録時にACによって割り当てられた登録ID。
Reason Code : The following are valid values:
理由コード：以下の有効な値は次のとおりです。
0 : Unspecified reason
0：未指定の理由
1 : The device that is the source of the frame is going down.
1：フレームの送信元であるデバイスが下がっています。
All other values are reserved.
その他の値はすべて予約されています。
The De-Registration Response is a simple ACK from the recipient of the corresponding De-Registration Request.
登録解除応答は、対応する登録解除要求の受信者からの簡単なACKです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SLAPP 802.11 De-Registration Response
図12：SLAPP 802.11登録解除応答
Flags : Reserved
フラグ：予約
SLAPP Registration ID : The registration ID assigned by the AC upon successful registration.
SLAPP登録ID：成功登録時にACによって割り当てられた登録ID。
Reason Code : The same reason code used in the corresponding request.
理由コード：対応する要求に使用したのと同じ理由コード。
The Configuration Request message is used by the WTP to request a set of configurations for each BSS that the AC wishes to configure at the WTP.
構成要求メッセージは、ACがWTPに設定することを望む各BSSのためのコンフィギュレーションのセットを要求するためにWTPによって使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: SLAPP 802.11 Configuration Request
図13：SLAPP 802.11構成要求
The Information Element ID list field contains the list of IEs that the WTP is interested in obtaining configuration information for.
情報要素IDリストフィールドは、WTPがために、構成情報を得ることに興味を持っているのIEのリストが含まれています。
The Configuration Response message is used by the AC to respond to a Configuration Request by the WTP.
構成応答メッセージは、WTPによって構成要求に応答するためにACで使用されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SLAPP 802.11 Configuration Response
図14：SLAPP 802.11構成応答
The following information elements are mandatory in the Configuration Response:
以下の情報要素は、構成応答に必須です。
01: CAPWAP mode
01：CAPWAPモード
For each WLAN interface:
各WLANインタフェースの場合：
03: WLAN Interface Index
03：WLANインタフェースのインデックス
27: Radio Mode
27：ラジオモード
07: 802.11 PHY mode and Channel Selection
07：802.11 PHYモードとチャネルの選択
For each BSSID:
各BSSIDの場合：
12: BSSID Index
12：BSSIDインデックス
13: ESSID
13：ESSID
08: Cryptographic Selection
08：暗号セレクション
The following information elements may be optionally included in the Configuration Response:
以下の情報要素は、必要に応じて構成応答に含まれていてもよいです。
10: Antenna Information Element
10：アンテナ情報要素
25: WTP Name
25：WTPの名前
For each WLAN interface:
各WLANインタフェースの場合：
For each BSSID:
各BSSIDの場合：
14: ESSID Announcement Policy
14：ESSIDのお知らせ方針
15: Beacon Interval
15：ビーコン間隔
16: DTIM Period
16：DUMピリオド
17: Basic Rates
17：基本料金
18: Supported Rates
18：サポートされている料金
19: Retry Count
19：再試行回数
20: Fragmentation Threshold
20：フラグメンテーションしきい値
21: RTS Threshold
21：RTSしきい値
22: Short/Long Preamble
22：ショート/ロングプリアンブル
23: 802.1Q Tag
23：802.1Qタグ
253: Vendor-Specific Element
253：ベンダー固有の要素
If any of the optional IEs is absent in the Configuration Response message, then their default values are applied by the WTP.
オプションのIEのいずれかが設定応答メッセージに存在しない場合は、そのデフォルト値はWTPによって適用されます。
The Configuration Update message is initiated by the AC to push modified or updated configuration to the WTP. It has a format similar to that of the Configuration Response message defined above.
構成更新メッセージがWTPに変更または更新された設定をプッシュするACによって開始されます。これは、上記で定義されたコンフィギュレーション応答メッセージと同様の形式を持っています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: SLAPP 802.11 Configuration Update
図15：SLAPP 802.11設定の更新
The list of mandatory and optional IEs for the Configuration Update message is the same as that for the Configuration Response message.
設定Updateメッセージのための必須およびオプションのIEのリストは、構成応答メッセージのためのものと同じです。
The Configuration Acknowledgment message is used by the WTP to inform the AC whether it has accepted the prior Configuration Update or Configuration Response message. The WTP can reject the configuration sent by the AC, in which case it MUST return to the discovery state.
設定の確認応答メッセージは、それが前の設定の更新や設定の応答メッセージを受け入れたかどうかをACに通知するために、WTPで使用されています。 WTPは、それが発見状態に戻る必要があり、その場合、ACによって送信されたコンフィギュレーションを、拒否することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: SLAPP 802.11 Configuration ACK
図16：802.11設定ACKをRELAX
The Status Code field contains one of the following values:
ステータスコードフィールドには、次のいずれかの値が含まれています。
0 : Success - The WTP accepts that the configuration pushed by the AC and has applied it.
0：成功 - WTP構成がACに押されていることを受け入れ、それを適用しました。
1 : Failure - The WTP did not accept the configuration pushed by the AC and MUST be de-registered at the AC.
1：失敗 - WTPはACによって押さ構成を受け入れなかったとACに登録解除されなければなりません。
The status request message is used by the AC to request the configuration and operational status from the WTP.
ステータス要求メッセージは、WTPの構成及び動作状態を要求するためにACによって使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SLAPP 802.11 Status Request
図17：SLAPP 802.11ステータス要求
The Information Element ID list contains the list of IEs for which the AC requests status.
情報要素IDリストは、ACがステータスを要求するためのIEのリストが含まれています。
The status response message is used by the WTP to respond to a status request from the AC.
状態応答メッセージは、ACからのステータス要求に応答するためにWTPによって使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SLAPP 802.11 Status Response
図18：SLAPP 802.11ステータス応答
The Flags field contains one of the following values:
Flagsフィールドには、次のいずれかの値が含まれています。
Bit 0 : If set, Unknown AC or SLAPP registration ID. If this bit is reset, then this indicates a successful response.
ビット0：設定した場合、不明なACまたはSLAPP登録ID。このビットがリセットされている場合、これは正常な応答を示します。
Bit 1 : If set, the WTP indicates that it has not been configured yet; otherwise, the WTP is in a configured state.
ビット1：設定した場合は、WTPは、それがまだ構成されていないことを示します。そうでない場合、WTPは、構成状態にあります。
All other values are reserved.
その他の値はすべて予約されています。
The status IE is mandatory in a status response message.
ステータスIEは、ステータス応答メッセージで必須です。
The Statistics request message is used by the AC to request statistics information from the WTP.
統計要請メッセージは、WTPから統計情報を要求するためにACによって使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SLAPP 802.11 Statistics Request
図19：SLAPP 802.11統計リクエスト
The Flags field contains the following bits:
Flagsフィールドには、次のビットが含まれています。
Bit 0 : If set to 1, then the WTP should reset the counters after sending the statistics response message.
ビット0：1に設定されている場合、WTPが統計応答メッセージを送信した後にカウンタをリセットする必要があります。
All other bits are reserved and MUST be set to 0 by the source and ignored by the destination.
他のすべてのビットは予約されており、ソースによって0に設定され、宛先で無視しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: SLAPP 802.11 Statistics Response
図20：SLAPP 802.11統計レスポンス
The Flags field contains the following bits:
Flagsフィールドには、次のビットが含まれています。
Bit 0 : If set, then the counters have been reset as requested by the AC.
ビット0：設定した場合、ACからの要求に応じて、その後、カウンタがリセットされました。
Bit 1 : If set, then the WTP has encountered a statistics request from either an unknown AC or with an unknown SLAPP registration ID.
ビット1：設定した場合は、WTPはどちらか不明ACからか不明SLAPP登録IDと統計の要求を検出しました。
Bit 2 : If set, WTP indicates that it has not been configured yet; otherwise, the WTP is in a configured state.
ビット2：設定されている場合、WTPは、それがまだ構成されていないことを示します。そうでない場合、WTPは、構成状態にあります。
All other bits are reserved.
他のすべてのビットは予約されています。
The keepalive messages can be initiated by either the WTP or the AC. It is used to probe the availability of the other party and the path between them. The initial message is termed the keepalive request, while the response to that message is termed the keepalive response.
キープアライブメッセージは、WTPまたはACのいずれかによって開始することができます。相手の可用性とそれらの間のパスをプローブするために使用されます。そのメッセージへの応答がキープアライブ応答と呼ばれながら、最初のメッセージは、キープアライブ要求と呼ばれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: SLAPP Keepalive Packet
図21：SLAPPキープアライブパケット
The Flags field has the following values:
Flagsフィールドには、次の値があります。
Bit 0 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message.
ビット0：キープアライブ応答メッセージに1に設定、キープアライブ要求メッセージに0に設定します。
Bit 1 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message if the initiator of the keepalive request is unknown or the SLAPP registration ID is incorrect, and set to 0 otherwise.
ビット1：キープアライブ要求のイニシエータが未知であるか、SLAPP登録IDが正しくない、そうでなければ0に設定されている場合、キープアライブ応答メッセージに1に設定され、キープアライブ要求メッセージに0に設定します。
All other bits are reserved and must be set to 0 by the source and ignored at the destination.
他のすべてのビットは予約されており、ソースによって0に設定され、先に無視されなければなりません。
In CAPWAP mode 5, the 802.11 crypto functions are performed at the AC. So there is no need for the AC to send PTKs/GTKs to the WTP. When one of the CAPWAP Modes 1-4 has been negotiated between the AC and WTP, it is necessary for the AC to send both unicast and broadcast/multicast keys to the WTP. This is accomplished after the 802.1x authenticator (which resides on the AC) has successfully authenticated the supplicant. Key Configuration Requests are differentiated -- unicast or broadcast -- by setting or clearing the high-order bit of the "Flags" field. The setting of this bit determines the contents of the Key Configuration Request following the SLAPP Registration ID.
CAPWAPモード5においては、802.11暗号機能はACで行われます。だから、ACはWTPにのPTK / GTKsを送信するために必要はありません。 CAPWAPモード1-4の一方はACとWTPの間でネゴシエートされたときにACはWTPの両方ユニキャスト及びブロードキャスト/マルチキャストキーを送信することが必要です。 （ACに存在する）802.1X認証は、サプリカントが認証に成功した後にこれが達成されます。主な構成要求が区別されている - ユニキャストまたはブロードキャスト - 「フラグ」フィールドの上位ビットをセットまたはクリアすることによって。このビットの設定はSLAPP登録ID、次のキー構成要求の内容を決定します。
The Unicast Key Configuration Request is used by the AC to inform the WTP of the key to use when protecting unicast frames to and from a specified supplicant.
ユニキャスト鍵構成要求は、指定されたサプリカントにしてからユニキャストフレームを保護するときに使用するキーのWTPを知らせるためにACで使用されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast key length | unicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Unicast Key Configuration Request
図22：ユニキャスト鍵構成要求
Note the high-order bit of the "Flags" field is cleared to indicate a unicast key is being sent. The 802.1Q tag field is used to indicate to the WTP which VLAN this supplicant is in and which broadcast/ multicast key to use when communicating to it with broadcast/ multicast frames.
「フラグ」フィールドの上位ビットが送信されるユニキャスト鍵を示すためにクリアされます。 802.1QタグフィールドはVLANこのサプリカントWTPに示すために使用されている、かつブロードキャスト/マルチキャストフレームとそれと通信するときに使用する/マルチキャストキーをブロードキャスト。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |1| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD | broadcast/multicast key length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ broadcast/multicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Group Key Configuration Request
図23：グループの主要構成要求
Note the high-order bit of the "Flags" field is set, indicating a broadcast/multicast key is being sent. The bits marked "RSVD" are reserved and MUST be set to zero by the AC and ignored by the WTP.
「フラグ」フィールドの上位ビットは、ブロードキャスト/マルチキャストキーが送信されている指示、設定されます。ビットが「RSVD」が予約されており、WTPによりACによってゼロに設定され、無視されなければならないマーク。
The WTP acknowledges receipt of a Unicast Key Configuration Request by sending a Unicast Key Configuration Response. This response mirrors the request but does not send back the key length or the key itself. (The RSVD bits are returned for alignment purposes and MUST be set to zero by the WTP and ignored by the AC.)
WTPは、ユニキャスト鍵構成応答を送信することにより、ユニキャスト鍵構成要求の受信を確認します。この応答は、要求を反映しますが、キーの長さやキー自体を返送しません。 （RSVDビットは、位置合わせの目的のために戻され、WTPによってゼロに設定され、ACで無視しなければなりません。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Unicast Key Configuration Response
図24：ユニキャストキーの設定レスポンス
The WTP acknowledges receipt of a Multicast Key Configuration Request by sending a Multicast Key Configuration Response. This response mirrors the request, but it does not send back the key length or the key itself. (The RSVD bits are returned for alignment purposes and MUST be set to zero by the WTP and ignored by the AC.)
WTPは、マルチキャスト鍵構成応答を送信することにより、マルチキャスト鍵構成要求の受信を確認します。この応答は、要求を反映したが、それは、キーの長さやキー自体を返送しません。 （RSVDビットは、位置合わせの目的のために戻され、WTPによってゼロに設定され、ACで無視しなければなりません。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Group Key Configuration Response
図25：グループキーの設定レスポンス
An AC may want to periodically monitor the health of a WTP, collect the necessary information for diagnostics, and get notifications on pre-defined events at the WTP that may be of interest. This section defines a set of WTP statistics and events and describes the process of collecting statistics from WTPs and configuring the event notification mechanism at the WTP. It is beyond the scope of this document to describe what should/could be done with the collected information.
ACは、定期的に、WTPの健康状態を監視し、診断に必要な情報を収集し、興味のあるWTPで事前に定義されたイベントの通知を取得することができます。このセクションでは、WTP統計とイベントのセットを定義し、WTPsから統計情報を収集し、WTPでのイベント通知メカニズムを設定するプロセスを説明します。これは、/収集した情報を使って行うことができなければならないかを説明するために、このドキュメントの範囲を超えています。
The simple statistics collection procedure defined here does not require the WTP to maintain any timers or any similar mechanisms. A WTP is responsible only for maintaining the statistics defined in Information Elements 29, 30, 31, and 32. The WTP must also respond to a statistics request message from the AC by delivering the appropriate statistics to the AC using a statistics response message. For example, if an AC is interested in gathering periodic statistics about some specific statistics, it is the responsibility of the AC to poll the WTP at the appropriate intervals.
ここで定義されたシンプルな統計収集の手順は、任意のタイマーまたは任意の同様のメカニズムを維持するために、WTPを必要としません。 WTPは、情報要素29、30、31で定義された統計を維持する責任があり、および32 WTPも統計応答メッセージを使用してACに適切な統計を提供することにより、ACから統計要請メッセージに応答しなければなりません。 ACは、いくつかの特定の統計に関する定期的な統計情報を収集に興味がある場合、適切な間隔でWTPをポーリングするACの責任です。
The event notification process includes the following: 1) Event Registration: the registration of events of interest at the WTP by the AC and 2) Notification: The communication of event-related information by the WTP to the AC whenever the conditions for a specific registered event has occurred. The set of events supported by a WTP and the event-specific parameters that may be configured as part of a event registration are given in Section 6.1.3.3.3.
1）イベント登録：ACによってWTPにおける関心のイベントの登録及び2）通知：ACへWTPによりイベント関連情報の通信特定の条件が登録されたときはいつでもイベント通知方法は、以下を含みますイベントが発生しました。 WTPとイベント登録の一部として構成することができるイベント固有のパラメータでサポートされているイベントのセットは、セクション6.1.3.3.3に記載されています。
This section defines a set of WTP events along with the event-specific parameters that may be configured by ACs and the event-related information that should be delivered to the ACs by WTPs when the conditions for a particular configured event have occurred.
このセクションでは、ACSと特定の設定したイベント条件が発生した場合WTPsによってACSに配信すべきイベントに関連する情報によって構成されてもよいイベント固有のパラメータと共にWTPイベントのセットを定義します。
Radar Detection Event: Configure whether the AC is interested in receiving a notification whenever a radar event is detected. The WTP may notify the AC about the type of radar interference and the new channel that the WTP has moved to as a result, if any, using the Radar Detection Event Element (element ID: 35).
レーダ検出イベント：ACレーダーイベントが検出されるたびに通知を受信することに関心があるかどうかを設定します。 WTPは、レーダ干渉の種類と、もしあればWTPがレーダ検出イベント要素（35要素ID）を使用して、結果として移動した新しいチャネルに関するACを通知してもよいです。
Excessive Retry Event: Configure the number of consecutive transmission failures before a notification is generated. The WTP may notify the MAC address of the station (STA) and the number of consecutive unacknowledged frames so far using the Excessive Retry Event Element (element ID : 36).
過度の再試行のイベント：通知が生成される前に、連続送信の失敗回数を設定します。 WTPは、ステーション（STA）のMACアドレスと、これまで過剰リトライイベント要素（36要素ID）を用いて連続未確認フレームの数を通知してもよいです。
Noise Floor Event: Configure the noise floor threshold above which an event notification would be generated by the WTP. The WTP may notify the AC with the most recent measured noise floor that exceeded the configured threshold using the Noise Floor Event Element (element ID : 37).
ノイズフロアイベント：イベント通知はWTPによって生成されるその上ノイズフロア閾値を設定します。 WTPは、ノイズフロアイベント要素（37要素ID）を使用して設定されたしきい値を超えた最新の測定されたノイズフロアとACを通知してもよいです。
De-Authentication Event: Configure whether the AC is interested in receiving a notification whenever a station has been de-authenticated by the WTP. The WTP may notify the AC with the MAC address of the STA along with a reason code (inactivity, etc.).
デ認証イベント：ACステーションはWTPにより解除認証されたときはいつでも通知を受信することに関心があるかどうかを設定します。 WTPは、理由コード（非アクティブ、等）とともにSTAのMACアドレスを使用してACを通知してもよいです。
Association Event: Needed in Local MAC architecture.
協会のイベント：ローカルMACアーキテクチャに必要。
Disassociation Event: Needed in Local MAC architecture.
解離イベント：ローカルMACアーキテクチャに必要。
The SLAPP 802.11 Control Protocol operation is described in this section.
SLAPP 802.11制御プロトコル操作は、このセクションで説明されています。
+-------------+
| discovering |<-------------------------------+<----+
+-------------+ | |
^ ^ | |
| | +-----------+ | |
| | | securing | | |
| | +----+------+ | |
| | | | |
| | v | |
| | +--------------+ | |
| | +--->| Unregistered | | |
| | | +------+-------+ | |
| | | | | |
| | | |Registration | |
| | |Timeout |Request | |
| | | | | |
| | | v | |
| | | +--------------+ | |
| | +----+ Registration | | |
| | | | | |
| | Reject | | | |
| +--------+ Pending | | |
| nTimeout>3| | | |
| | | | |
| +------+-------+ | |
| | | |
| |Accept | |
| | | |
| | | |
| v | |
| +------+-------+ | |
| | Registered | | |
| +--->| | | |
| | +------+-------+ | |
| | | | |
| |Timeout |Config | |
| | |Request | |
| | | | |
| | v | |
| | +------+-------+ | |
| +----+ | Reject| |
| |Configuration | | |
| Reject | Pending | | |
+-----------+ | | |
^ nTimeout>3+------+-------+ | |
| | | |
| | | |
De-reg| | +----------------+ | |
resp | | v Accept | | |
+----+---+ +------+----+--+ +-+---+--+ |
| | De-reg| | | Update | |
| De +<------+ Configured +-----------+ | |
|Register| req | | | Pending| |
| | | | +----+---+ |
+--------+ +------+-------+ |
| |
| |
| |
Too |Many |
Keepalive |
Failures |
| |
| |
| De-Register |
+-------------------------------+
In Configured and/or Registered states, respond to Status Requests, Statistics Requests, Keepalives, Key Config
設定済みおよび/または登録状態では、ステータス要求、統計要求、キープアライブ、キーコンフィグへの対応
Figure 26: SLAPP 802.11 Control Protocol at the WTP
図26：WTPでSLAPP 802.11制御プロトコル
Unregistered: The transition into this state is from the securing state (Figure 3). Send registration request message to move to Registration Pending state, set timer for registration response.
未登録：この状態への遷移は、固定状態（図3）からのものです。登録応答のためのタイマーを設定し、登録保留状態に移行する登録要求メッセージを送信します。
Registration Pending: On a registration response from the AC, cancel registration timer. If the response is successful, move to Registered state. If not, move to discovering state (Figure 3). If timer expires, if nTimeout >3, then move to discovering state. If not, return to Unregistered state.
登録保留中：ACからの登録応答では、登録タイマーを取り消します。応答が成功した場合は、登録状態に移行します。そうでない場合、状態（図3）を発見に移動します。タイマーが期限切れになった場合、nTimeout> 3なら、状態を発見するまで移動。ない場合は、未登録の状態に戻ります。
Registered: Send Configuration Request message to AC to move to Configuration Pending state, and set timer for Configuration Response. In this state, respond to status request, statistics request, and keepalive messages from the AC.
登録：設定保留状態に移動し、コンフィギュレーション応答のためのタイマーを設定するためにACに設定要求メッセージを送信します。この状態で、ACからのステータス要求、統計要求、およびキープアライブメッセージに応答します。
Configuration Pending: If a Configuration Response is received from the AC, cancel the Configuration Response timer. If the response is successful and the configuration is acceptable, then send the Configuration ACK message to AC, and move to Configured state. If the Configuration Request is rejected or the configuration is not acceptable, then send a de-register request to the AC and move to discovering. If the Configuration Response timer expires, move to Registered state unless nTimeout >3, in which case move to discovering state.
設定保留：構成応答は、ACから受信した場合、構成応答タイマーをキャンセルします。応答が成功すると設定が受け入れ可能である場合には、ACに設定ACKメッセージを送信し、設定された状態に移行します。構成要求が拒否または設定が受け入れられないされている場合は、ACに登録解除要求を送信し、発見に移動します。設定応答タイマが満了した場合は、その場合の状態を発見への移行で、nTimeout> 3ない限り、登録状態に移行します。
Configured: In the Configured state, the WTP responds to the status request, statistics request, and keepalive messages from the AC. If it receives a de-register request message from the AC, then it sends a de-register response to the AC and moves to the discovering state. If the WTP receives a Configuration Update message, then it moves to the Update Pending state. If it receives too many consecutive keepalive failures (no responses from the AC to keepalive requests), then it sends a de-register message to the AC and moves to the discovering state.
設定済み：設定済みの状態では、WTPは、ステータス要求、統計要求、およびACからのキープアライブメッセージに応答します。それはACから登録解除要請メッセージを受信した場合、それは発見状態にACと移動するデ登録応答を送信します。 WTPは、Configuration Updateメッセージを受信した場合、それは更新保留状態に移行します。それはあまりにも多くの連続キープアライブ障害を受信した場合（ACからの応答が要求をキープアライブないように）、それはACと発見状態に移るに登録解除メッセージを送信します。
Update Pending: In the Update Pending state, the WTP analyzes the configuration information received in the Configuration Update message. If the configuration is found to be acceptable, then it applies the configuration and returns to the Configured state. If the WTP chooses to reject the configuration update, then it sends a de-register request to the AC and moves to the discovering state.
更新保留中：更新保留状態において、WTPは、構成更新メッセージで受信した設定情報を解析します。構成が許容されることが判明した場合、それはコンフィギュレーションを適用し、設定された状態に戻ります。 WTPは、構成更新を拒否することを選択した場合、それは発見状態にACと移動する登録解除要求を送信します。
De-register: From the Configured state, the WTP moves to the De-register state when it receives a de-register request message from the AC. It sends a de-register response to the AC and moves to the discovering state.
登録解除：それはACから登録解除要請メッセージを受信した時に設定状態から、WTPは、登録解除状態に移行します。これは、ACにデ登録応答を送信し、発見状態に移行します。
+----------+
| securing |
+----+-----+
|
|
|
v
+--------------+
+--------| Unregistered |
| +----+---------+
| |
|Timeout |Register
| |request
| v +-------------+
| +----------+ Accept | Registration|
| +---+Register +----------->| Pending |
| | |Processing| +-+-----+-----+
| | +----------+ | |
| | | |
| |Reject Timeout |
| | | |Config
| | | |Request
| | +--------------+ | |
| +----->| |<------+ |
| | discovering | v
+----------->| | +------------+
+--------------+ | Registered |
^ ^ ^ +----+-------+
| | | |
| | | |Config
| | | |Response
| | | v
| | | Timeout +------------+
| | +----------| Config |
| | or Reject | Pending |
| | +----+-------+
| | |
| | |Config ACK
| | v
| |De-Register +------------+
| +-------------| |
| or Keepalive | Configured |<--+
| failures | | |
| +----+-------+ |
Reject| | |
or| | |
Timeout +-----------+ |Config |
| | Update | |Update |
+-----| Pending |<-----+ |
+----+------+ |
| Accept |
+-------------------------+
Figure 27: SLAPP 802.11 Control Protocol at the AC
図27：ACでSLAPP 802.11制御プロトコル
The states "securing" and "discovering" are described in Figure 3.
そして「発見」「固定」状態は、図3に記載されています。
Unregistered: This state is entered from the securing state described in Figure 3. In this state, the AC is waiting for a registration request message from the WTP. Upon receiving the registration request message, it moves into the Registration Processing state.
未登録：この状態は、この状態では、図3で説明した固定状態から入力され、ACはWTPから登録要求メッセージを待っています。登録要求メッセージを受信すると、それは登録処理状態に移行します。
Registration Processing: In this state, the AC must determine whether or not it can accept the new WTP. If the AC decides to accept the WTP, it must pick a CAPWAP mode to operate in and send a registration response message with a success code and moves to the Registration Pending state. If the AC chooses to reject the current registration request from the WTP, it must send a registration response with a failure code and move to the discovering state.
登録処理：この状態では、ACは、それが新しいWTPを受け入れることができるかどうかを決定しなければなりません。 ACは、WTPを受け入れることを決定した場合、それはで動作するようにCAPWAPモードを選択し、成功コードおよび登録保留状態に移行して登録応答メッセージを送信する必要があります。 ACはWTPから現在の登録要求を拒否することを選択した場合は、故障コードに登録応答を送信し、発見状態に移動しなければなりません。
Registration Pending: If the timer expires before a response from the WTP is received, then the AC destroys the registration state and moves to the discovering state. If a Configuration Request message is received from the WTP, then the AC moves into the Registered state and processes the Configuration Request message. It sends a Configuration Response message to the WTP with the appropriate IEs and moves into the Configuration Pending state.
登録保留中：WTPからの応答が受信される前にタイマーが満了した場合、ACは、登録状態を破壊し、発見状態に移行します。構成要求メッセージは、WTPから受信された場合、ACは、登録状態に移行し、設定要求メッセージを処理します。これは、コンフィギュレーション保留状態に適切なのIEと移動してWTPに構成応答メッセージを送信します。
Configuration Pending: If the timer expires before a response is received from the WTP, then the AC destroys the current registration and moves into the discovering state. If a Configuration ACK is received from the WTP, but contains a failure code, then the AC again destroys the registration state and moves into the discovering state. If the Configuration ACK from the WTP is successful, then the AC moves to the Configured state.
設定保留中：応答がWTPから受信する前にタイマーが満了した場合、ACは、現在の登録を破壊し、発見状態に移行します。構成ACKがWTPから受信したが、故障コードが含まれている場合、ACは、再度登録状態を破壊し、発見状態に移行します。 WTPからの設定ACKが成功した場合、ACは、設定済みの状態に移行します。
Configured: In the Configured state, the AC can send a status request, statistics request, keepalive, and Key Configuration messages to the WTP. Any response to these messages from the WTP that indicates an unknown SLAPP registration ID or an unknown AC causes the AC to destroy any registration or configuration state and move to the discovering state. From the configured state, the AC can send a Configuration Update message and move into the Update Pending state. If it receives a de-register request from the WTP, then it destroys all current registration and configuration state and moves into the discovering state. If a number of successive keepalive messages go unacknowledged by the WTP, then the AC moves into the discovering state.
設定済み：設定済みの状態で、ACは、WTPにステータス要求、統計要求、キープアライブ、およびキー設定メッセージを送信することができます。未知SLAPP登録IDまたは未知のACを示しWTPからこれらのメッセージへの応答は、ACは、任意の登録や設定状態を破壊し、発見状態に移動させます。構成された状態から、ACは、Configuration Updateメッセージを送ることができますし、更新保留状態に移動します。それはWTPからデレジスタリクエストを受信した場合、それはすべての現在の登録及び設定状態を破壊し、発見状態に移行します。連続したキープアライブメッセージの数はWTPによって未確認行く場合は、ACは発見状態に移行します。
Update Pending: When the AC receives a Configuration ACK message with a success code, then it returns to the Configured state. If the status code is a failure or if the timer expires before the Configuration ACK is received from the WTP, the AC destroys all registration and configuration state for the WTP and moves into the discovering state.
更新保留：ACは成功コードを設定ACKメッセージを受信し、それが設定された状態に戻ります。ステータスコードは失敗であるかの設定ACKがWTPから受信する前にタイマーが満了した場合、ACは、WTPのために、すべての登録と設定状態を破壊し、発見状態に移行した場合。
The Image Download protocol is a control protocol defined in this document that is generic enough to be agnostic to the underlying technology.
イメージのダウンロードプロトコルは、基礎となる技術にとらわれないように十分一般的であり、この文書で定義された制御プロトコルです。
In the Image Download protocol, the WTP obtains a bootable image from the AC by receiving a series of image transfer packets. Missed image data packets are re-requested by the WTP by sending image data request packets indicating the missing packets.
イメージのダウンロードプロトコルでは、WTPは、画像転送一連のパケットを受信することによりACから起動可能な画像を取得します。逃した画像データパケットが欠落しているパケットを示す画像データ要求パケットを送信することにより、WTPにより再要求されます。
The image to download is divided into slices of equal size (except for the last slice, which can be less than the slice size provided, it is also greater than zero). The size of each slice depends on the MTU determined by the DTLS exchange and SHOULD be the realized MTU minus the size of an Image Download Request (Figure 29).
ダウンロードの画像は同じサイズのスライスに分割されている（設けスライスサイズよりも小さくすることができる最後のスライスを除いて、それはまた、ゼロよりも大きいです）。各スライスのサイズは、DTLS交換によって決定MTUに依存し、実現MTUマイナスイメージダウンロード要求（図29）の大きさであるべきです。
Note that the Image Download packet and Image Download Request is encapsulated in a DTLS header that secures the image download.
イメージのダウンロードパケットとイメージのダウンロード要求が画像のダウンロードを確保DTLSヘッダでカプセル化されることに注意してください。
The format of an Image Download packet is shown in Figure 28.
イメージのダウンロードパケットのフォーマットは、図28に示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ image data slice ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: SLAPP Image Download Packet
図28：SLAPPイメージのダウンロードパケット
where:
どこ：
length: variable
長さ：変数
RESERVED: Unused in this version of SLAPP, MUST be zero (0) on transmission and ignored upon receipt.
RESERVED：未使用SLAPPのこのバージョンでは、送信に及び受信時に無視され、ゼロ（0）でなければなりません。
M: The "More" bit indicating that the current packet is not the final one.
M：現在のパケットが最終的なものではないことを示す「詳細」ビット。
R: The "Request" bit. This bit MUST be set to one (1) when the packet is the response to a request and zero (0) otherwise.
R：「要求」ビット。パケットが要求とそうでない場合はゼロ（0）に対する応答である場合、このビットが1（1）に設定しなければなりません。
packet sequence number: A monotonically increasing counter that assigns a unique number to each slice of the image.
パケットシーケンス番号：画像の各スライスに固有の番号を割り当てる単調増加カウンタ。
image data slice: A portion of the bootable image.
画像データスライス：ブート可能なイメージの部分。
The format of an Image Download Request is shown in Figure 29.
イメージのダウンロード要求のフォーマットは、図29に示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |M|R| packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: SLAPP Image Download Request Packet
図29：SLAPPイメージのダウンロード要求パケット
where:
どこ：
length: eight (8) octets
長さ：8（8）オクテット
RESERVED: Unused in this version of SLAPP, MUST be zero on transmission and ignored upon receipt.
RESERVED：未使用SLAPPのこのバージョンでは、伝送上のゼロになると、領収書で無視しなければなりません。
M: The "More" bit. This MUST be equal to the one (1) when negatively acknowledging a missed packet and set to zero (0) when indicating the end of the Image Download protocol.
M：「より多くの」ビット。負逃したパケットを認めると（0）イメージのダウンロードプロトコルの終了を示す場合にゼロに設定されている場合これは、1（1）に等しくなければなりません。
R: the "Request" bit. This MUST be one in an Image Download Request.
R：「要求」ビット。これは、イメージのダウンロード要求の1でなければなりません。
packet sequence number: The packet sequence number of the missing image data slice.
パケットシーケンス番号：欠落している画像データのスライスのパケットシーケンス番号。
The AC will divide the bootable image into a series of slices and send each slice as an Image Download packet. The size of each image data slice (and therefore the size of each Image Download packet) depends on the MTU of the connection determined during the DTLS handshake. With the transmission of each slice, the AC MUST increment the packet sequence number.
ACは、一連のスライスに起動可能なイメージを分割し、イメージのダウンロードパケットとして各スライスを送信します。各画像データのスライスのサイズ（各画像のダウンロードパケットのゆえサイズ）DTLSハンドシェイク時に決定された接続のMTUに依存します。各スライスの送信と、ACは、パケットシーケンス番号をインクリメントしなければなりません。
Image Download packets are negatively ACK'd. An AC MUST NOT assume anything about the reception of packets; it sends based upon negative ACKs. One could naively assume that since the packets are sent sequentially, that all packets with a sequence number of "n - 1" are implicitly ack'd by the receipt of a request for the packet with sequence number "n" to be retransmitted. Such an assumption would be incorrect since previous requests could, themselves, have been dropped.
画像ダウンロードパケットは負ACK'dされています。 ACは、パケットの受信については何も仮定してはいけません。それは負のACKに基づいて送信します。暗黙のうちに再送するシーケンス番号「N」のパケットに対する要求の受信によってack'dれる - 一つは、単純に「1 N」のシーケンス番号を有するすべてのパケットは、そのパケットが順次送信されるためと想定できました。以前の要求は、自身が、削除された可能性があるため、このような仮定は正しくないだろう。
The Image Download process is initiated by the WTP requesting a packet with the packet sequence number of zero (0). The AC sets the packet sequence counter for this WTP to one (1) and sends the first slice. The "Request" bit for the first slice sent by the AC MUST be set to zero (0) since the first slice was technically not requested.
イメージのダウンロードプロセスがゼロのパケットシーケンス番号（0）でパケットを要求WTPによって開始されます。 ACは、一（1）このWTPのパケットシーケンスカウンタを設定し、最初のスライスを送信します。最初のスライスは、技術的に要求されなかったので、ACによって送信された最初のスライスの「要求」ビット（0）はゼロに設定しなければなりません。
The WTP sets a periodic timer that, when it fires, causes the WTP to send Image Download Requests for slices that have been missed since the last periodic timer had fired. Since individual Image Download packets are not ack'd, the AC MUST NOT set a timer when each one is sent.
WTPは、それが発火するとき、WTPが最後の周期タイマーが起動していたので、見逃されているスライス用画像のダウンロード要求を送信するようになり、定期的にタイマーを設定します。個々のイメージのダウンロードパケットがack'dされていないので、一つ一つが送信されたとき、ACは、タイマーを設定してはいけません。
If a WTP notices missed image transfer packets -- when the difference between the packet sequence number of a received image transfer packet and the packet sequence number of the last image transfer packet previously received is greater than one -- it will note that fact in a bitmask. When the periodic timer fires, the WTP will request the slices that are absent from that bitmask. Each slice will be requested by sending a Download Request with a length of eight (8) and indicating the sequence number of the packet requested. The AC MUST interleave these retransmissions with packets in the sequence.
WTPの通知が画像転送パケットを逃した場合 - 受信した画像転送パケットのパケットシーケンス番号と以前に受信した最後の画像転送パケットのパケットシーケンス番号との差が1よりも大きい場合 - それは、その事実に注意しますビットマスク。場合は定期的なタイマー火災は、WTPはそのビットマスクは存在しないスライスを要求します。各スライスは、8つ（8）の長さのダウンロード要求を送信し、要求されたパケットのシーケンス番号を示すことにより、要求されるであろう。 ACは、シーケンス内のパケットでこれらの再送信をインタリーブしなければなりません。
Since both sides implicitly agree upon the MTU of the link, the WTP will know the slice size that the AC will use during the Image Download process. A dropped packet will therefore result in an internal buffer pointer on the WTP being incremented by the slice size and the lost packet requested. When the lost packet is received, it can be inserted into the buffer in the space provided by the pointer increment when its loss was first detected. That is, loss of packet <n> will result in packet <n> being re-requested and when received inserted into the buffer at an offset of <n-1> * <slicesize> from the start of the buffer.
両側が暗黙的にリンクのMTU合意以来、WTPは、ACは、イメージのダウンロードプロセス中に使用するスライスのサイズを知っているだろう。ドロップされたパケットは、したがって、スライスのサイズと要求された失われたパケットだけインクリメントされるWTPに内部バッファポインタをもたらすであろう。失われたパケットを受信したときは、その損失が最初に検出されたときにポインタ増分によって提供される空間内のバッファに挿入することができます。すなわち、パケットの損失<n>が再要求されているとき、バッファの先頭から<N-1> * <slicesize>のオフセットでバッファに挿入受信<N>パケットをもたらすです。
The final packet sent by the AC will not have the "more" bit set, and this indicates to the WTP that the end of the image has been received. This final packet is acknowledged by the WTP indicating the end of the Image Download process.
ACによって送信された最後のパケットは、「より多くの」ビットが設定されていません、これは画像の端部が受信したことWTPに示します。この最後のパケットは、イメージのダウンロードプロセスの終了を示すWTPによって確認されました。
A lost final packet will result in the AC resending the final packet again (see Section 4.4).
失われた最後のパケットが再び最後のパケットを再送するACになります（4.4節を参照してください）。
The Image Download protocol is a Negotiated Control Protocol defined for SLAPP. Transitions to it come from the "secure" state and transitions out of it go to the "acquire" state. See Figure 3.
イメージのダウンロードプロトコルはSLAPP用に定義された交渉制御プロトコルです。それへの遷移は、「取得」状態になり、それのうち「安全な」状態と遷移から来ます。図3を参照してください。
The AC's state machine for the Image Download protocol is shown in Figure 30. The AC maintains the following variables for its state machine:
イメージのダウンロードプロトコルのACのステートマシンは、ACは、その状態マシンの以下の変数を保持し、図30に示します。
seq_num: The current slice that is being sent.
SEQ_NUM：送信されている現在のスライス。
nslices: The total number of slices in the image.
nslices：画像内のスライスの総数。
req_num: The number of the slice that was requested.
REQ_NUM：要求されたスライスの数。
more: Whether the "More bit" in the packet should be set.
より：パケット内の「その他のビットは」設定されるべきであるかどうか。
starved: A timer that sets the maximum amount of time in which an AC will attempt to download an image.
飢えた：ACイメージをダウンロードしようとしている時間の最大量を設定し、タイマー。
Note: The symbol "C" indicates an event in a state that results in the state remaining the same.
注：記号「C」は同じままの状態になる状態でイベントを示しています。
|
v
+----------+
| waiting |
+----------+
|
| seq_num = 1, more = 1,
| nslices = x, starved = t
M bit v
+----------+ is 0 +-------------+
| finished |<-------| received |<------\
+----------+ | |<----\ |
+-------------+ | |
req_num = requested | | |
packet | M bit is 1 | |
V | |
+----------+ | |
seq_num++, C| sending |------/ |
req_num=0 +----------+ |
| |
| | |
+-------------+ | | |
| discovering |<----/ | |
| |<----\ | |
+-------------+ | | |
| v v
+--------+ |
| idle |---------/
+--------+
Figure 30: SLAPP Image Download Protocol State Machine at the AC
図30：SLAPPイメージはACでプロトコルステートマシンをダウンロード
The following states are defined:
以下の状態が定義されています。
Waiting: When the AC leaves the SLAPP state of "Secure", it enters the "Waiting" state of the Image Download protocol. seq_num is set to one (1), more is set to one (1), nslices is set to the number of slices in the particular image to download, and starved is set to the maximum amount of time the AC will devote to downloading a particular image.
待機中：ACは、「セキュア」のSLAPP状態を離れたとき、それはイメージのダウンロードプロトコルの「待機」状態になります。 SEQ_NUMは1に設定されている（1）より（1）、nslicesをダウンロードするために、特定の画像内のスライスの数に設定され、飢餓されたものに設定されているACのダウンロードに専念する時間の最大量に設定されています特定の画像。
Received: The AC enters this state when it has received an Image Download Request. If the sequence number of the packet is zero (0), it sets seq_num to one (1) and transitions to Sending; else, if the M bit is set, it sets req_num to the sequence number of the request and transitions to Sending; else, (if the M bit is clear) it transitions to Finished.
受信：ACは、それがイメージのダウンロード要求を受信したこの状態に入ります。パケットのシーケンス番号はゼロ（0）は、送信する（1）〜SEQ_NUMとトランジションを設定している場合。 Mビットが設定されている場合はそう、それが送信するリクエスト及び遷移のシーケンス番号にREQ_NUMを設定します。他に、（Mビットがクリアされている場合）には、仕上がりに移行します。
Sending: The AC is sending a slice to the WTP. If req_num is equal to zero (0), it sends the slice indicated by seq_num and increments seq_num. If req_num is greater than zero (0), it sends the slice indicated by req_num and sets req_num to zero (0). The "More" bit in either case is set depending on the value of more. As long as no request packets are received Sending transitions to Sending. When seq_num equals nslices "More" is set to zero (0) and the state transitions to Idle. If the starved timer expires, the AC transitions to the SLAPP state of Discovering.
送信：ACはWTPにスライスを送信しています。 REQ_NUMがゼロ（0）に等しい場合、それはSEQ_NUMによって示されるスライスを送信しSEQ_NUMをインクリメントします。 REQ_NUM（0）がゼロより大きい場合、それはREQ_NUMによって示されるスライスを送信し、ゼロ（0）にREQ_NUMを設定します。いずれの場合も「その他」ビットがよりの値に応じて設定されます。限り何の要求パケットを送信するトランジションを送信する受信されないよう。 SEQ_NUMはnslicesに等しいとき、「詳細」がゼロ（0）に設定され、状態遷移はアイドルします。飢えたタイマーが満了した場合、ACは発見のSLAPP状態に移行します。
Idle: The AC has sent all the slices in the image and is just waiting for requests. If the starved timer expires the AC transitions to the SLAPP state of Discovering.
アイドル：ACは、画像内のすべてのスライスを送信しただけの要求を待っています。飢えたタイマーは、発見のSLAPP状態にAC遷移を期限切れになった場合。
Finished: The Image Download protocol has terminated. The starved timer is canceled.
終了：イメージのダウンロードプロトコルが終了しました。飢えたタイマーは解除されます。
The WTP's state machine for the Image Download protocol is shown in Figure 31. The WTP maintains the following variables for its state machine:
イメージのダウンロードプロトコルのWTPのステートマシンは、WTPがその状態マシンの以下の変数を保持し、図31に示します。
recv_num: The sequence number of the last received slice.
recv_num：最後に受信したスライスのシーケンス番号。
req: A bitmask whose length equals the number of slices in the image.
REQ：長さが画像内のスライスの数に等しいビットマスク。
retry: A timer.
再試行：タイマーを。
giveup: A timer.
ギブアップ：タイマーを。
final: The sequence number of the last slice.
最終：最後のスライスのシーケンス番号。
Note: The symbol "C" indicates an event in a state that results in the state remaining the same.
注：記号「C」は同じままの状態になる状態でイベントを示しています。
|
v
+----------+
| init | recv_num = 0,
+----------+ final = 0, req = 0,
| giveup = t
v
+----------+ +-----------+
| finished |<------- | sending |<-------\
+----------+ +-----------+ |
| | retry fires
v |
+--------------+ |
bit in req = C| receiving |------/
seq_num in packet +--------------+
is set |
| giveup fires
v
+-------------+
| discovering |
+-------------+
Figure 31: SLAPP Image Download Protocol State Machine at the WTP
図31：SLAPPイメージはWTPでプロトコルステートマシンをダウンロード
The following states are defined:
以下の状態が定義されています。
Init:
初期化：
When the WTP leaves the SLAPP state of "Secure", it enters the "Init" state of the Image Download protocol. recv_num, final, and the req bitmask are set to zero (0), and the giveup timer is set to a suitably large number. The WTP transitions directly to Sending.
WTPは、「セキュア」のSLAPP状態を離れたとき、それはイメージのダウンロードプロトコルの「初期化」状態になります。 recv_num、最終的な、及びREQビットマスクは、ゼロ（0）に設定され、GIVEUPタイマが適切多数に設定されています。 WTPは、送信に直接遷移します。
Sending:
送信：
If recv_num is zero (0) the WTP sends a request for a packet with sequence number of zero (0) and the "More" bit set to one (1). Otherwise, for every unset bit in req between one (1) and recv_num, a request packet is sent with the sequence number corresponding to the unset bit in req and the "More" bit set to more.
recv_numがゼロである場合（0）WTPシーケンスゼロ（0）の数と一つ（1）に設定され、「詳細」ビットを有するパケットを要求します。そうでない場合、一方（1）との間のrecv_num REQ内のすべての未設定ビットについて、要求パケットがREQにおける未設定ビットおよびそれ以上に設定された「詳細」ビットに対応するシーケンス番号と共に送信されます。
If there are no unset bits in req and final is non-zero, a request packet is sent for the sequence number represented by final with the "More" bit cleared, giveup is cleared and the state machine transitions to Finished. Otherwise, retry is set to a suitable value and the WTP transitions to Receiving.
全く未設定REQのビットと最後が存在しない場合は非ゼロであり、要求パケットがクリアされ、「詳細」ビットを有する最終によって表される配列番号に送られ、GIVEUPクリアされ、ステートマシン遷移を終了します。そうでない場合は、再試行を受信するのに適した値とWTPの遷移に設定されています。
Receiving:
受信：
In this state, the WTP receives Image Download packets. The bit in req corresponding to the sequence number in the received packet is set, indicating this packet has been received. If the sequence number of the received packet has already been received, the packet is silently dropped; otherwise, the data in the packet is stored as the indicated slice in a file that represents the downloaded image. If the received packet has the "More" bit cleared, final is set to the sequence number in that packet. When the retry timer fires, the WTP transitions to Sending. If the giveup timer fires, the WTP transitions to the SLAPP state of Discovering.
この状態では、WTPは、イメージのダウンロードパケットを受信します。受信したパケットのシーケンス番号に対応REQ内のビットは、このパケットを受信したことを示す、設定されています。受信したパケットのシーケンス番号がすでに受信されている場合、パケットは黙って落とされます。そうでない場合は、パケット内のデータがダウンロードされたイメージを表すファイルに示されているスライスとして格納されます。受信したパケットは、「より多くの」ビットがクリアされた場合は、最終的にはそのパケット内のシーケンス番号に設定されています。ときに、リトライタイマー火災、WTPは、送信に移行します。 GIVEUPタイマーが起動した場合、WTPは発見のSLAPP状態に移行します。
Finished:
終了：
The Image Download protocol has finished.
イメージのダウンロードプロトコルが完了しました。
This document describes a protocol, SLAPP, which uses a different protocol, DTLS, to provide for authentication, key exchange, and bulk data encryption of a Negotiated Control Protocol. Its security considerations are therefore those of DTLS.
この文書は、認証、鍵交換、および交渉制御プロトコルのバルクデータの暗号化を提供するために、異なるプロトコル、DTLSを使用するプロトコル、SLAPPを、説明しています。そのセキュリティの考慮事項は、したがって、DTLSのものです。
The AC creates state upon receipt of an acceptable Discover Request. AC implementations of SLAPP SHOULD therefore take measures to protect themselves from denial-of-service attacks that attempt to exhaust resources on target machines. These measures could take the form of randomly dropping connections when the number of open connections reaches a certain threshold.
ACは、許容可能な検出要求の受信時に状態を作成します。 SLAPPのAC実装は、したがって、ターゲット・マシンにリソースを使い果たしにしようとするサービス拒否攻撃から身を守るための措置をとるべきです。オープン接続の数が一定のしきい値に達したときにこれらの対策は、ランダムにドロップ接続の形を取ることができます。
The WTP exposes information about itself during the discovery phase. Some of this information could not be gleaned by other means.
WTPは、発見フェーズ中に自分自身についての情報を公開します。この情報の一部は、他の手段によって収集することができませんでした。
The SLAPP protocol can be considered to be a technology-independent protocol that can be extended with technology-specific components to solve an interoperability problem where a central controller from one vendor is expected to control and manage network elements from a different vendor.
SLAPPプロトコルは、あるベンダーから中央制御装置は、異なるベンダーからのネットワーク要素を制御および管理することが期待される相互運用性の問題を解決する技術に固有の構成要素で拡張することができる技術に依存しないプロトコルであると考えることができます。
While the description of the SLAPP protocol in this document assumes that it is meant to solve the multi-vendor interoperability problem, as defined in the CAPWAP problem statement [3], splitting the
CAPWAP問題文で定義されるように本書でSLAPPプロトコルの説明は、マルチベンダ相互運用性の問題を解決することを意図されていることを前提としながら、[3]、分割
solution to two components where technology-dependent control protocols are negotiated using a technology-independent framework enables the use of SLAPP as the common framework for multiple underlying technologies that are vastly different from one another.
技術に依存する制御プロトコルは技術に依存しないフレームワークを使用してネゴシエートされた2つの構成要素への解決策は、互いに大きく異なる複数の基礎となる技術のための共通の枠組みとしてSLAPPの使用を可能にします。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[2]ヤン、L.、Zerfos、P.、およびE. Sadot、 "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のためのアーキテクチャ分類"、RFC 4118、2005年6月。
[3] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[3]オハラ、B.、カルフーン、P.、およびJ.ケンフ、 "ワイヤレスアクセスポイント（CAPWAP）問題文の構成およびプロビジョニング"、RFC 3990、2005年2月。
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[4]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[5] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[5]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[6] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[6]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[7]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[8] Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", <http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>.
[8] Modadugu、N.およびE.レスコラ、 "データグラムTLSの設計と実装"、<http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>。
[9] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader Protocol", Work in Progress, August 2005.
[9]クリシュナ、P。およびD. Husak、 "シンプル・軽量のRFIDリーダープロトコル"、進歩、2005年8月の作業。
Authors' Addresses
著者のアドレス
Partha Narasimhan Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
94089のPartha Narasimhanアルバネットワークス1322 Crosmanアベニューサニーベール、
Phone: +1 408-480-4716 EMail: partha@arubanetworks.com
電話：+1 408-480-4716電子メール：partha@arubanetworks.com
Dan Harkins Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
ダンハーキンズアルバネットワークス1322クロスマンアベニューサニーベール、CA 94089
EMail: dharkins@arubanetworks.com
メールアドレス：dharkins@arubanetworks.com
Subbu Ponnuswamy Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
Subbu Ponnuswamyアルバネットワークス1322クロスマンアベニューサニーベール、CA 94089
Phone: +1 408-754-1213 EMail: subbu@arubanetworks.com
電話：+1 408-754-1213電子メール：subbu@arubanetworks.com