[要約] RFC 5413は、セキュアな軽量アクセスポイントプロトコル（SLAPP）に関するものであり、無線アクセスポイントとコントローラ間のセキュアな通信を提供することを目的としています。
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
SLAPP：安全なライトアクセスポイントプロトコル
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）問題ステートメントの制御とプロビジョニングは、ワイヤレスLAN（WLAN）ネットワークデザイナーが複数のワイヤレス終了ポイント（WTP）とアクセスコントローラー（AC）で構成されるソリューションを構築する前に対処する必要がある問題を説明しています。、さまざまなベンダー。主な目標の1つは、2つのクラスのデバイス（WTPとACS）間の相互運用性を解決するソリューションを見つけることで、あるベンダーからのACが別のベンダーからWTPを制御および管理できるようにします。
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コントロールプロトコルと、もう1つのより一般的な画像ダウンロードプロトコルを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に記載されている問題に特に対処するために書かれていますが、ソリューションは、1つ以上のネットワーク要素（WTPに相当）を管理するコントローラー（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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
このRFCは、CAPWAPワーキンググループでのさらなる作業の基礎としてIETFに提出されたときのSLAPPプロトコルを文書化しているため、RFC 5415および他のIETF作業のCapWapプロトコル仕様に似ている可能性があります。この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は、インターネット標準のレベルの候補者ではなく、いかなる種類のインターネット展開の基礎として使用すべきではありません。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http //：trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
Wireless 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つの方法は、1つのベンダーからのACが別のベンダーからWTPを制御および管理できるようにする完全な制御プロトコルを定義することです。しかし、主に特定の基礎となるテクノロジー（この場合はIEEE 802.11）の問題を解決することに焦点を当てているソリューションは、他の基礎となるテクノロジーに対処することが難しいと感じるかもしれません。構成可能なオプションのセットと、その基礎となるテクノロジーに固有の異なるアーキテクチャの選択（802.11の分割MACアーキテクチャに類似）で、さまざまな基礎となるテクノロジーが異なる場合があります。ある基礎となるテクノロジーに適したアーキテクチャの選択は、必ずしも別のテクノロジーでは機能するとは限りません。同じ基礎となるテクノロジーでも、複数の建築的選択[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.
この問題を解決する別の方法は、ソリューション空間を2つのコンポーネントに分割することです。1つはテクノロジーと独立したコンポーネントであり、もう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.
このドキュメントでは、コントローラーが中央に管理することを目的としたテクノロジーに依存しないプロトコルであるSecure Light Access Pointプロトコル（SLAPP）を提示します。制御プロトコルとプロビジョニングプロトコルのテクノロジー固有のコンポーネントを実行するために使用するコントロールプロトコルを交渉します。また、このドキュメントに2つの制御プロトコルを提示しました。802.11WTPSのセットをプロビジョニングおよび管理するための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コントロールプロトコル
+-------------------------+ +------------+
| | | |
| 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）[9]の定義につながった、無線周波数識別（RFID）スペースの同様の問題にかなりの関心がありました。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
The SLAPP protocol supports multiple topologies for interconnecting WTPs and ACs as indicated in Figure 2.
SLAPPプロトコルは、図2に示すように、WTPとACを相互接続するための複数のトポロジーをサポートしています。
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に直接接続されています。多くのWTPは、建物のプレナムに展開されており、ネットワークに接続しているイーサネットケーブルに電力を供給する必要があります。市場の多くの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つの異なるブロードキャストドメインにあり、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番目のケースは、WTPからACへのパス上の中間ノードが必ずしも同じ管理ドメインにあるとは限らないことを除いて、3番目のケースのサブセットです。また、中間ネットワークは、ACとWTPの両方が同じ建物またはキャンパス内にある場合よりも低い容量を持つ1つ以上のWANリンクにまたがる場合があります。
+-----------------+ +-------+
| | (1) | |
| AC +------------+ WTP |
| | | |
+--------+--------+ +-------+
|
|
|
+---+---+
(2) | |
+------+ L2 +--------+
| | | |
| +---+---+ |
| |
| |
+-----+-----+ +---+---+ +-------+
| | | | (3)| |
| WTP | | L3 +----+ WTP |
| | | | | |
+-----------+ +---+---+ +-------+
|
|
|
+---+----+ +-------+
| | (4)| |
|Internet+----+ WTP |
| | | |
+--------+ +-------+
Figure 2: SLAPP Topology
図2：SLAPPトポロジ
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状態マシンを図3に示します。WTPとACの両方が互いに発見し、コントロールプロトコルを交渉し、安全なチャネルを確立するために安全なハンドシェイクを実行し、その安全なチャネルを使用します。交渉された制御プロトコルを保護します。
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が最大時間を設定するタイマーは、取得したACがデータグラム輸送層セキュリティ（DTLS）のハンドシェイクを開始するのを待ちます。
/--------\ /-----------\
| | | |
| v v |
| +-------------+ |
| C| discovering |<-\ |
| +-------------+ | |
| | | |
| v | |
| +-----------+ | |
\--| acquiring | | |
+-----------+ | |
| | |
v | |
+----------+ | |
C| securing |-----/ |
+----------+ |
| |
v |
+----------------+ |
| negotiated | |
C| control |-----/
| protocol |
+----------------+
Figure 3: SLAPP State Machine
図3：Slapp Stateマシン
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はACを積極的に発見しています。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：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交換の「クライアントエンド」を実行します。DTLS交換のエラーは、ACが発見に移行することになります。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交換の「サーバーエンド」を実行します。DTLS交換のエラーは、WTPが発見に移行することになります。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.
すべてのSLAPPパケットは、図4に示すように同じヘッダーから始まります。
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：スラップヘッダー
Where:
ただし：
Maj (4 bits): the major number of the SLAPP version Min (4 bits): the minor number of the SLAPP version
Maj（4ビット）：Slappバージョンの主要な数min（4ビット）：Slappバージョンのわずかな数
Type (1 octet): the type of SLAPP message
タイプ（1オクテット）：スラップメッセージのタイプ
Length (two octets): the length of the SLAPP message, including the entire SLAPP header
長さ（2オクテット）：スラップヘッダー全体を含むスラップメッセージの長さ
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メッセージには、Major.Minorの形式のバージョンが含まれます。このドキュメントでは、1.0バージョンのSlappについて説明します。つまり、メジャーバージョンは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メッセージの形式や意味を変更しない方法で追加情報を伝えたりする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がサポートされていない場合、メッセージを削除する必要があります。ただし、ピアがサポートされているメジャーバージョンでスラップメッセージをドロップしたい正当な理由がある場合があります。
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（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つは、ネットワーク近隣で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広い地域のパブリックネットワーク）。したがって、提案された発見メカニズムには、WTPがこれらすべてのトポロジにわたってACを発見できるようにするための規定が必要です。
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 Discoverリクエストパケットを送信することにより、Slapp Discoveryプロセスが開始されます。パケットは、ブロードキャストIPアドレス、よく知られたマルチキャストアドレス、または（ACのIPアドレスがWTPブートアップの前に構成されているか、起動シーケンス中に学習される場合）にアドレス指定できます）。IPアドレス。1つの発見方法への応答がないと、WTPが別の発見方法を試すことになります。Slapp Discover Request Packetは、Slapp Discoveryポートとして指定されたポート[TBD]にアドレス指定されたUDPパケットです。ソースポートは、任意のランダムポートにすることができます。Slapp Discoverリクエストパケットのペイロードを図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は、ランダムに生成された32ビット番号であり、SLAPP発見プロセスの1つのフェーズで維持されます。発見プロセスを開始するWTPによって生成されます。1つのディスカバリーメソッドがACを見つけられず、WTPが別のディスカバリーメソッドを試みると、トランザクションIDを再利用してはなりません。Slapp Discoverリクエストに応答する予定のすべての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は、WTPでの構成に基づいて、または他の発見手段に基づいて、Unicastの場合、発見要求パケットがACに送信されているかどうかを示します。Slapp Discoverリクエストパケットがブロードキャストまたはマルチキャストアドレスのいずれかに送信されている場合、このビットは常に発見モードに設定する必要があります。フラグフィールド内のさまざまなビットの有効な値は次のとおりです。
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ビットフィールドは、WTPベンダーの管理情報構造（SMI）エンタープライズコードのネットワークオクテット順にあります（これらのエンタープライズコードは、IANAから取得し、登録できます）。
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ビットフィールドは、それに従う8ビット制御プロトコルインジケーターの数を示し、したがって、WTPがサポートできる異なる制御プロトコルの数を暗黙的に示します。この数値は少なくとも1つでなければなりません（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 Discoverリクエストには、複数の「制御タイプ」インジケーターがある場合があります。
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.
WTPからSlapp Discoverリクエストパケットを受信するACは、Slapp Discover応答パケットで応答することを選択できます。Slapp Discover応答パケットの形式を図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 Discover ResponseパケットはUDPパケットです。これは、常にWTPのIPアドレスのユニキャストです。ソースIPアドレスは、ACが応答を送信するものです。ソースポートはSlapp Discoverポート[TBD]であり、宛先ポートはSlapp Discoverリクエストで使用されているソースポートと同じです。WTPのMACアドレスとトランザクションIDは、Slapp Discoverリクエストに含まれる値と同一でなければなりません。ステータスフィールドは、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 Discoverリクエストパケットの値と同一である必要があります。
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.
ステータスフィールドの値が1であり、ACが成功した応答を送信していることを示している場合、このフィールドと次の2つの値が有効であることを示します。32ビットACベンダーIDは、ACのベンダーIDを指しています。ステータスフィールドの値が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.
ステータスフィールドの値が1の場合、この32ビットフィールドにはACのハードウェアバージョンの値が含まれます。この値は、ACベンダーによって選択されます。ステータスフィールドの値が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.
ステータスフィールドの値が1の場合、この32ビットフィールドにはACのソフトウェアバージョンの値が含まれます。この値は、ACベンダーによって選択されます。ステータスフィールドの値が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 Discoverリクエストで渡されたコントロールタイプの1つと一致する必要があります。
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 Discover Request Packetは設定された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サーバーはオプション43を使用して、WTPがSlapp Discoverリクエストパケットに対処するACのIPアドレスを配信するように構成できます。ACのIPアドレスがDHCP応答の一部としてWTPに渡される場合、WTPはこのIPアドレスへのSlapp Discoverリクエストパケットに対処する必要があります。
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 [TBD]の有名なFQDNのDNSサーバーを照会しようとする必要があります。。このDNSクエリが成功した場合、WTPはSlapp Discoverリクエストパケットに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 Discovery Start：静的IPアドレス構成オプション：ACの静的IPアドレスは構成されていますか？はいの場合、そのユニキャストIPアドレスにSLAPP発見要求を送信しますslapp slapp discovery_timer内で発見しますか？はいの場合、「done」に移動しない場合は、「static fqdn configオプション」に移動しない場合は、「static fqdn configオプション」に移動します。はいの場合、FQDNのIPアドレスのDNSクエリを送信します。DNSクエリは成功していますか？はいの場合、そのIPアドレスにSLAPP発見要求を送信しますSlapp Discovery Timer内のDiscover Response？はいの場合、「done」に移動しない場合は、「DHCPオプションオプション」に移動しない場合は、「DHCPオプションオプション」DHCPオプションオプションに移動します。はいの場合、ACのIPアドレスにSlapp Disking Requestを送信しますSlapp Discovery Timer内のDiscover Response？はいの場合は、「DONE」に移動しない場合は、「ブロードキャストオプション」に移動しない場合は、「ブロードキャストオプション」オプションに移動します。はいの場合は、「DONE」に移動しない場合は、「マルチキャストオプション」マルチキャストオプションに移動します。SlappMulticastアドレスにSlapp Discover Packetを送信しますSlapp Discover Response in in Discoveryタイマー？はいの場合、「DONE」に移動しない場合は、「DNS Discoveryオプション」に移動します。DNSディスカバリーオプション：よく知られているDNS名のDNSサーバーをクエリします。DNSディスカバリーは成功しましたか？はいの場合、そのIPアドレスにSLAPP発見要求を送信しますSlapp Discovery Timer内のDiscover Response？はいの場合は、そうでない場合は「Done」に移動します。「Slapp Discovery Restart」に移動しても、「Slapp Discovery Restart」に移動します
SLAPP discovery restart: Set timer for SLAPP discovery idle timer When timer expires, go to "SLAPP discovery start" done: Go to the next step
Slapp Discovery Restart：スラップディスカバリーアイドルタイマーのタイマーを設定するタイマーが期限切れになったら、「Slapp Discovery Start」に移動します。
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 Discoverリクエストを受信した場合、WTPを取得したいかどうかを判断する必要があります。ACは、WTP識別子が構成で静的に構成されているWTPを取得することにのみ同意する場合があります。または、WTPSを無償で取得する意思のあるACは、保留中の認証を受け入れることができます。ACは、一般的な交渉対象制御プロトコルを話すWTPを取得することのみを選択する必要がありますが、他の要因はその決定に影響を与える可能性があります。たとえば、ネゴシエートされたコントロールプロトコルがこのメモで定義されている画像ダウンロードプロトコルである場合、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は、WTPを取得するという合意を示すSLAPP発見応答を送信します。
2. The AC silently drops the SLAPP discover request and does not respond at all.
2. ACはSlapp Discoverリクエストを静かにドロップし、まったく応答しません。
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とのDTL [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は、広く受け入れられ、分析されたプロトコルを使用して安全で接続のないチャネルを提供するため、使用されます。さらに、DTLの無数の認証オプションにより、WTPとAC（相互および証明書ベース）の間のチャネルを保護するための幅広いオプションが可能になります。非対称または非単位認証。匿名認証など。さらに、DTLSは、独自の断片化と再組み立て技術、および効果的なMTUにピアが同意する方法を定義します。DTLを使用すると、プロトコルのこれらの側面を再定義する必要性がなく、したがって、同じ問題を別の場所で再び解決する必要がないため、コード膨満を減らします。
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は、SLAPPの発見状態に戻って、DTLS交換を開始する別の適切なACを見つける必要があります。
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関連の暗号スイートでさらにすべてのスラップメッセージを保護します。
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展開のゼロ-Config要件は、特定の認証オプションを述べ、他のものを排除することができます。
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] Exchangeで使用されています。
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.
この認証モデルはACを認証せず、Rogue ACは有効なWTPの制御を主張できます。ただし、これにより、WTPがRogue 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.
このセクションでは、Slappの2つの拡張機能を説明します。1つは802.11 WLANに固有のものと、ACがWTPに起動可能な画像をダウンロードできる技術中立プロトコルです。
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.
このセクションでは、IEEE 802.11 WLAN標準を実装するWTPSとACSを対象とする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: 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.
CapWap Architecture Taxonomy Document [2]は、WLAN業界で現在使用されている複数のアーキテクチャについて説明しています。これらの文書化されたアーキテクチャには幅広い変動性が存在しますが、すべてのバリエーションまたは選択をサポートすると、複雑なプロトコルとネゴシエーション段階につながります。802.11コンポーネントの複雑さを制限するために、以下にリストするように、交渉を4つの異なるアーキテクチャの選択に制限しています。ローカル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アーキテクチャにもあります。このモードと前のモードの違いは、このモードでは、セクション6.1.2で定義されているメカニズムを使用して、ACにWTPトンネル802.3フレームがACにフレームすることです。
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.
WTPのスプリットMAC、L2 Crypto：この操作モードは、スプリットMACアーキテクチャに該当します。802.11 MacはWTPとACの間で分割されます。分割の正確な性質については、セクション6.1.1.2で説明しています。L2 Crypto関数は、ACがこの関数の可能性があるかどうかに関係なく、この関数を満たすために使用されるWTPで実装されています。セクション6.1.2で定義されたメカニズムを使用して、ACにWTPトンネル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.
ACのスプリットMAC、L2 Crypto：この動作モードは、スプリットMACアーキテクチャにも該当します。これと前のものの違いは、ACに実装されたL2暗号関数が、これらの関数がWTPでも利用可能かどうかに関係なく、この関数を満たすために使用されることです。セクション6.1.2で定義されたメカニズムを使用して、ACにWTPトンネル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.
CapWap Architecture Taxonomy Document [2]に記載されているローカルMacアーキテクチャは、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.11フレームを802.3フレームに変換します。これは、ACによって割り当てられたタグを使用して802.1Qタグ付けされる場合がありますが、これらのスプリットMACアーキテクチャの他のものは802.11フレーム全体をACにトンネルします。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で：
802.11 control frame processing
802.11制御フレーム処理
802.11 encryption and decryption
802.11暗号化と復号化
802.11 fragmentation and reassembly
802.11断片化と再組み立て
Rate Adaptation
レートの適応
802.11 beacon generation
802.11ビーコン生成
Power-save buffering and Traffic Indication Map (TIM) processing
パワーセーブバッファリングとトラフィック表示マップ（TIM）処理
At the AC:
ACで：
802.11 Management frame processing
802.11管理フレーム処理
802.11 DS and portal
802.11 DSおよびポータル
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で：
802.11 control frame processing
802.11制御フレーム処理
Rate Adaptation
レートの適応
802.11 beacon generation
802.11ビーコン生成
Power-save buffering and TIM processing
パワーセーブバッファリングとTIM処理
At the AC:
ACで：
802.11 Management frame processing
802.11管理フレーム処理
802.11 encryption and decryption
802.11暗号化と復号化
802.11 fragmentation and reassembly
802.11断片化と再組み立て
802.11 DS and portal
802.11 DSおよびポータル
Split MAC implementations of this kind tunnel 802.11 frames between the AC and the WTP.
この種のトンネル802.11フレームのMAC実装をACとWTPの間に分割します。
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つのコンポーネントがあります。1つは特定のコントロールとプロビジョニングメッセージを輸送するためのもので、もう1つはWTPからACへのデータトラフィックをトンネルします。
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コントロールプロトコルは、一般的なルーティングカプセル化（GRE）[4]を使用して、L2フレームをカプセル化します。アーキテクチャがMacを分割するかどうかと方法に応じて、一部のアーキテクチャは802.11フレームがACに直接トンネルをトンネルにしますが、他のアーキテクチャは802.3フレームをトンネルにします。
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プロトコルは47であり、GREヘッダーが続くことを示しています。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つのオクテットフィールドがSLAPPヘッダーに追加され、コントロールプロトコルタイプを示します。SLAPP802.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：登録リクエスト - WTPからACに送信
2 : Registration Response - sent from AC to WTP
2：登録応答 - ACからWTPに送信
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：構成要求-WTPからACに送信
6 : Configuration Response - sent by AC to WTP
6：構成応答 - ACによってWTPに送信
7 : Configuration Update - sent by AC to WTP
7：構成更新-ACからWTPに送信
8 : Configuration Acknowledgment - sent by the WTP to AC
9 : Status Request - sent by the AC to the WTP
10 : Status Response - sent by the WTP to the AC
10：ステータス応答 - WTPからACに送信
11 : Statistics Request - sent by the AC to the WTP
11：統計リクエスト - ACからWTPに送信
12 : Statistics Response - sent by the WTP to the AC
12：統計応答 - WTPからACに送信
13 : Event - sent by the WTP to the AC
13：イベント - WTPからACに送信
14 : Keepalive - sent either way
14：Keepalive-どちらの方法でも送信されます
15 : Key Config Request - sent by the AC to the WTP
15：キー構成要求 - ACからWTPに送信
16 : Key Config Response - sent by the WTP to the AC
16：キー構成応答 - WTPからACに送信
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ごとにサポートする場合がありますが、すべてのWTPは少なくとも1つのESSIDごとにサポートする必要があります。これは、複数のESSIDサポートの場合に主要な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は、機能ドメインだけでなく、機能ドメインによって制限されている機能を通知する必要があります。
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.
基本的なサービスセット識別子（BSSID）のプライマリインターフェイスおよび仮想アクセスポイント（AP）インターフェイスへの割り当てと割り当ては、サポートされている場合、このドキュメントの範囲外です。
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は、要素IDオクテットから始まり、その後に1オクテットの長さと、長さが長さフィールドに示されている要素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の1つを設定する必要があります。
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 Value : 0-255
長さ：1値：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)
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.
この要素は、WLANインターフェイスハードウェアベンダーのSMIエンタープライズコードであり、ネットワークOctet順序です（これらのエンタープライズコードは、IANAから取得して登録できます）。このフィールドは、WTPに存在するWLANインターフェイスの各インスタンスに対して1回表示されます。
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インターフェイスの各インスタンスに対して1回表示されます。
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インターフェイスの各インスタンスに対して1回表示されます。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.11g
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モードのすべてのサポートされているチャネルの中心周波数（KHz）を示す可変数の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オクセット値が正確に1つあります。
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インターフェイスの各インスタンスに1回表示されます。構成メッセージとステータスメッセージでは、この要素は、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
Bit 9 : Diversity support, 0 = No, 1 = Yes
Bit 10 : 0 = Internal, 1 = External
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：アンテナ数 - は、WTPで示される0からアンテナの数の数です。値は、ビット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インターフェイスの各インスタンスに対して1回表示されます。
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から（BSSIDS -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 = Hide Essid、1 = 802.11ビーコンに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を含むプローブリクエストに応答します。このビットのデフォルト値は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 Bit 5 : 9 Mbps
ビット4：6 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：retryカウントが短い、デフォルト値は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.
値：IEEE 802.11で許可されているRTSしきい値の有効な値。
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の間に転送されたときに特定の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.
ACからWTPへの登録応答の成功には、この要素が含まれている必要があります。登録がアクティブな期間中に、他のすべてのメッセージの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はこの要素を使用して、一連のASCII文字をWTPに割り当てます。
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
ビット0-15：イベント識別子
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 Bits 3-32 : Reserved
ビット2：U-APSDビット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
* 構成Acks：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-Retryの制限に達したフレーム：4オクテット
* Transmitted frames with 1 retry attempt : 4 octets
* 1回の再試行で送信されたフレーム：4オクテット
* Transmitted frames with 2 retry attempts : 4 octets
* 2回の再試行試行で送信されたフレーム：4オクテット
* 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
* retryビットセットを備えたフレーム：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
+ 現在のTXレート：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は、WTPからACに送信されたステータス応答メッセージに含まれています。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.
この要素は、ACがWTPから通知したいイベントのセットを構成するために使用されます。
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はステーションから他のすべての管理フレームのACに通知する必要があります。
+ 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.
この要素は、WTPによって使用されて、この検出の結果としてレーダー干渉の検出とチャネルの変更をACに通知します。
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.
この要素は、WTPによって使用され、構成されたノイズフロアのしきい値を超えるWLANインターフェイスの1つで現在のノイズフロアのACに通知します。
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.
この要素は、WTPまたはACのいずれかが生の802.11フレームを相手に送信できる一般的な機能を提供します。たとえば、ローカル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.
値：この可変長要素は、3-OCTETの組織的に一意の識別子（OUI）から始まり、その後、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.
値：ソースのすべての0Sで満たされ、目的地で無視する必要がある可変長要素。
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の機能を示す情報要素のリストが含まれています。メッセージは、SLAPP制御プロトコルメッセージタイプ1を使用して、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：トランザクションのステータス、0 = ACからの成功した応答を示します。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：より多くのWTPを処理できません
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モード - 登録要求でWTPによって送信されたサポートされているモードのリストの中からACが選択するモード。
24 : SLAPP registration ID
24：SLAPP登録ID
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 1 : The device that is the source of the frame is going down.
0：不特定の理由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.
構成応答メッセージは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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：DTIM期間
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.
設定応答メッセージにオプションのIESがない場合、そのデフォルト値は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.
構成更新メッセージは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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
構成更新メッセージの必須およびオプションの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.
構成承認メッセージは、WTPによって使用され、ACが以前の構成更新または構成応答メッセージを受け入れたかどうかを通知します。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：SLAPP 802.11構成ACK
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.
ステータス要求メッセージは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
フラグフィールドには、次の値のいずれかが含まれています。
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.
統計リクエストメッセージは、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
フラグフィールドには、次のビットが含まれています。
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:
フラグフィールドには、次のビットが含まれています。
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.
KeepAliveメッセージは、WTPまたはACのいずれかによって開始できます。相手の可用性とそれらの間のパスを調べるために使用されます。最初のメッセージはKeepAliveリクエストと呼ばれ、そのメッセージへの応答はKeepAlive Responseと呼ばれます。
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 Keepaliveパケット
The Flags field has the following values:
フラグフィールドには次の値があります。
Bit 0 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message.
ビット0：KeepAliveリクエストメッセージで0に設定され、KeepAlive応答メッセージで1に設定されています。
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：KeepALIVEリクエストメッセージで0に設定し、KeepALIVE RECOSSIONメッセージで1に設定されているKeepALIVEリクエストのイニシエーターが不明な場合、またはSLAPP登録IDが正しくない場合、それ以外の場合は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/GTKを送信する必要はありません。CAPWAPモード1〜4の1つがACとWTPの間で交渉された場合、ACがUnicastとBroadcast/Multicastキーの両方をWTPに送信する必要があります。これは、802.1x Authenticator（ACに存在する）がサプリカントの認証に成功した後に達成されます。キー構成要求は、「フラグ」フィールドの高次ビットを設定またはクリアすることにより、差別化されます - ユニキャストまたはブロードキャスト - 。このビットの設定により、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.
Unicastキー構成要求は、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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」とマークされたビットは予約されており、ACによってゼロに設定され、WTPで無視する必要があります。
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統計とイベントを定義し、WTPから統計を収集し、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および2）通知：特定の登録済みの条件がいつでもACへのイベント関連情報の通信：通知：2）通知：イベントが発生しました。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は、レーダー干渉の種類と、その結果、レーダー検出イベント要素（要素ID：35）を使用して、WTPがその結果として移動した新しいチャネルについて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は、ステーションのMACアドレス（STA）と、過剰な再試行イベント要素（要素ID：36）を使用して、これまでに連続して承認されていないフレームの数を通知する場合があります。
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は、ノイズフロアイベント要素（要素ID：37）を使用して構成されたしきい値を超える最新の測定ノイズフロアで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でのSLAPP802.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からのステータスリクエスト、統計リクエスト、およびKeepaliveメッセージに応答します。
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から構成応答が受信された場合、構成応答タイマーをキャンセルします。応答が成功し、構成が許容される場合は、構成ACKメッセージをACに送信し、構成状態に移動します。構成要求が拒否された場合、または構成が許容されない場合は、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からのステータスリクエスト、統計リクエスト、およびKeepAliveメッセージに応答します。ACから登録解除リクエストメッセージを受信した場合、ACへの登録解除応答を送信し、発見状態に移動します。WTPが構成更新メッセージを受信した場合、保留中の状態に更新に移動します。連続したkeepALIVE障害が多すぎる場合（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.
De-Register：構成された状態から、WTPはACから登録リクエストメッセージを受信すると、登録状態に移動します。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：SLAPP 802.11 ACでの制御プロトコル
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は登録状態に移動し、構成要求メッセージを処理します。適切なIESを使用して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はステータス要求、統計リクエスト、KeepAlive、およびKey構成メッセージをWTPに送信できます。未知のSLAPP登録IDまたは未知のACを示すWTPからのこれらのメッセージへの応答により、ACは登録または構成状態を破壊し、発見状態に移動します。構成された状態から、ACは構成更新メッセージを送信し、保留中の更新状態に移動できます。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：スラップ画像ダウンロードパケット
where:
ただし：
length: variable
長さ：変数
RESERVED: Unused in this version of SLAPP, MUST be zero (0) on transmission and ignored upon receipt.
予約済み：このバージョンの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：スラップ画像ダウンロードリクエストパケット
where:
ただし：
length: eight (8) octets RESERVED: Unused in this version of SLAPP, MUST be zero on transmission and ignored upon receipt.
長さ：8（8）オクテットは予約されています：このバージョンの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は、パケットの受信について何も想定してはなりません。ネガティブアクックに基づいて送信されます。パケットは順番に送信されるため、シーケンス番号の「n -1」を持つすべてのパケットが、再送信されるシーケンス番号「n」のパケットの要求を受け取ることにより暗黙的にAck'dされると素朴に想定することができます。このような仮定は、以前の要求自体が削除される可能性があるため、間違っています。
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は、このWTPのパケットシーケンスカウンターを1つ（1）に設定し、最初のスライスを送信します。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が送信されたときに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>が再リケストされ、受信した場合、バッファの開始時から<n-1> * <slicesize>のオフセットでバッファーに挿入されます。
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の状態マシンを図30に示します。ACは、その状態マシンの次の変数を維持しています。
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.
飢ved：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：ACでSlapp画像ダウンロードプロトコル状態マシン
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が「セキュア」のスラップ状態を離れると、画像ダウンロードプロトコルの「待機」状態に入ります。seq_numは1つに設定され、さらには1つ（1）に設定され、nslicesは特定の画像のスライス数にダウンロードするスライス数に設定され、飢vedは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）の場合、SEQ_NUMを1つ（1）に設定し、送信に遷移します。それ以外の場合、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で示されたスライスを送信し、req_numをゼロ（0）に設定します。どちらの場合でも「より多く」ビットは、より多くの値に応じて設定されます。リクエストパケットが受信されていない限り、送信への移行を送信します。SEQ_NUMがNSLICESの「more」に等しい場合、ゼロ（0）に設定され、状態がアイドル状態に移行します。飢えたタイマーの有効期限が切れた場合、ACは発見のスラップ状態に移行します。
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は画像内のすべてのスライスを送信し、リクエストを待っています。飢えたタイマーが期限切れになった場合、ACは発見のSLAPP状態に移行します。
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の状態マシンを図31に示します。WTPは、その状態マシンの次の変数を維持しています。
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：WTPでSLAPP画像ダウンロードプロトコル状態マシン
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が「セキュア」のスラップ状態を離れると、画像ダウンロードプロトコルの「init」状態に入ります。recv_num、final、および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）のシーケンス数を持つパケットのリクエストを送信し、「more」ビットが1（1）に設定されます。それ以外の場合、1つの（1）とrecv_numの間のReqのすべての非セットビットについて、要求パケットは、REQのUnset Bitと「More」ビットに対応するシーケンス番号で送信されます。
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 Timerが発砲する場合、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について説明します。したがって、そのセキュリティ上の考慮事項はDTLのものです。
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プロトコルは、1つのベンダーからの中央コントローラーが異なるベンダーのネットワーク要素を制御および管理することが期待される相互運用性の問題を解決するために、テクノロジー固有のコンポーネントで拡張できる技術に依存しないプロトコルと見なすことができます。
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 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.
このドキュメントのSLAPPプロトコルの説明は、CAPWAP問題ステートメント[3]で定義されているように、マルチベンダーの相互運用性の問題を解決することを目的としているが、技術依存の制御プロトコルが使用されている2つのコンポーネントにソリューションを分割することを目的としている一方テクノロジーに依存しないフレームワークにより、SLAPPを互いに大きく異なる複数の基礎となるテクノロジーの共通フレームワークとして使用できます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[2] Yang、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] O'Hara、B.、Calhoun、P。、およびJ. Kempf、「ワイヤレスアクセスポイント（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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[6] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[6] Rescorla、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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. Rescorla、「データグラム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] Krishna、P。およびD. Husak、「Simple Lightweight RFID Reader Protocol」、2005年8月の作業。
Authors' Addresses
著者のアドレス
Partha Narasimhan Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
Partha Narasimhan Aruba Networks 1322 Crossman Ave Sunnyvale、CA 94089
Phone: +1 408-480-4716
EMail: partha@arubanetworks.com
Dan Harkins Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
ダンハーキンスアルバネットワーク1322クロスマンアベニューサニーベール、カリフォルニア94089
EMail: dharkins@arubanetworks.com
Subbu Ponnuswamy Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089
Subbu Ponnuswamy Aruba Networks 1322 Crossman Ave Sunnyvale、CA 94089
Phone: +1 408-754-1213
EMail: subbu@arubanetworks.com