[要約] RFC 5412は、軽量アクセスポイントプロトコル（LWAPP）に関する規格であり、無線アクセスポイントとワイヤレスコントローラ間の通信を管理するためのプロトコルを定義しています。その目的は、ワイヤレスネットワークのセキュリティ、管理、および運用を効率化することです。
Independent Submission P. Calhoun
Request for Comments: 5412 R. Suri
Category: Historic N. Cam-Winget
ISSN: 2070-1721 Cisco Systems, Inc.
M. Williams
GWhiz Arts & Sciences
S. Hares
B. O'Hara
S.Kelly
February 2010
Lightweight Access Point Protocol
軽量アクセスポイントプロトコル
Abstract
概要
In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.
近年、自律アクセスポイントから軽量アクセスポイントの集中制御へのワイヤレスLAN（WLAN）製品アーキテクチャにシフトがありました。一般的な目標は、アクセス制御（ユーザー認証と承認）、モビリティ、ラジオ管理など、従来のワイヤレス機能のほとんどをアクセスポイントから集中コントローラーに移動することでした。
The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol.
IETFのCAPWAP（ワイヤレスアクセスポイントのコントロールとプロビジョニング）WGは、ワイヤレスアクセスコントローラーとワイヤレス終了ポイントの間で標準ベースのプロトコルが必要であることを特定しました（後者は一般に軽量アクセスポイントとも呼ばれます）。この仕様は、CAPWAP（ワイヤレスアクセスポイントの制御とプロビジョニング）プロトコル要件に対応する軽量アクセスポイントプロトコル（LWAPP）を定義します。LWAPPプロトコルは、さまざまなワイヤレステクノロジーに使用できるほど柔軟に柔軟にするように設計されていますが、この特定のドキュメントでは、IEEEの802.11ワイヤレスLANプロトコルで使用できる基本プロトコルと拡張機能を説明しています。
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/rfc5412.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5412で取得できます。
IESG Note
IESGノート
This RFC documents the LWAPP 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に提出された場合のようにLWAPPプロトコルを文書化しているため、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 ....................................................8
1.1. Conventions Used in This Document ..........................9
2. Protocol Overview ..............................................10
2.1. Wireless Binding Definition ...............................11
2.2. LWAPP State Machine Definition ............................12
3. LWAPP Transport Layers .........................................20
3.1. LWAPP Transport Header ....................................21
3.1.1. VER Field ..........................................21
3.1.2. RID Field ..........................................21
3.1.3. C Bit ..............................................21
3.1.4. F Bit ..............................................21
3.1.5. L Bit ..............................................22
3.1.6. Fragment ID ........................................22
3.1.7. Length .............................................22
3.1.8. Status and WLANS ...................................22
3.1.9. Payload ............................................22
3.2. Using IEEE 802.3 MAC as LWAPP Transport ...................22
3.2.1. Framing ............................................23
3.2.2. AC Discovery .......................................23
3.2.3. LWAPP Message Header Format over IEEE 802.3
MAC Transport ......................................23
3.2.4. Fragmentation/Reassembly ...........................24
3.2.5. Multiplexing .......................................24
3.3. Using IP/UDP as LWAPP Transport ...........................24
3.3.1. Framing ............................................24
3.3.2. AC Discovery .......................................25
3.3.3. LWAPP Message Header Format over IP/UDP Transport ..25
3.3.4. Fragmentation/Reassembly for IPv4 ..................26
3.3.5. Fragmentation/Reassembly for IPv6 ..................26
3.3.6. Multiplexing .......................................26
4. LWAPP Packet Definitions .......................................26
4.1. LWAPP Data Messages .......................................27
4.2. LWAPP Control Messages Overview ...........................27
4.2.1. Control Message Format .............................28
4.2.2. Message Element Format .............................29
4.2.3. Quality of Service .................................31
5. LWAPP Discovery Operations .....................................31
5.1. Discovery Request .........................................31
5.1.1. Discovery Type .....................................32
5.1.2. WTP Descriptor .....................................33
5.1.3. WTP Radio Information ..............................34
5.2. Discovery Response ........................................34
5.2.1. AC Address .........................................35
5.2.2. AC Descriptor ......................................35
5.2.3. AC Name ............................................36
5.2.4. WTP Manager Control IPv4 Address ...................37
5.2.5. WTP Manager Control IPv6 Address ...................37
5.3. Primary Discovery Request .................................38
5.3.1. Discovery Type .....................................38
5.3.2. WTP Descriptor .....................................38
5.3.3. WTP Radio Information ..............................38
5.4. Primary Discovery Response ................................38
5.4.1. AC Descriptor ......................................39
5.4.2. AC Name ............................................39
5.4.3. WTP Manager Control IPv4 Address ...................39
5.4.4. WTP Manager Control IPv6 Address ...................39
6. Control Channel Management .....................................39
6.1. Join Request ..............................................39
6.1.1. WTP Descriptor .....................................40
6.1.2. AC Address .........................................40
6.1.3. WTP Name ...........................................40
6.1.4. Location Data ......................................41
6.1.5. WTP Radio Information ..............................41
6.1.6. Certificate ........................................41
6.1.7. Session ID .........................................42
6.1.8. Test ...............................................42
6.1.9. XNonce .............................................42
6.2. Join Response .............................................43
6.2.1. Result Code ........................................44
6.2.2. Status .............................................44
6.2.3. Certificate ........................................45
6.2.4. WTP Manager Data IPv4 Address ......................45
6.2.5. WTP Manager Data IPv6 Address ......................45
6.2.6. AC IPv4 List .......................................46
6.2.7. AC IPv6 List .......................................46
6.2.8. ANonce .............................................47
6.2.9. PSK-MIC ............................................48
6.3. Join ACK ..................................................48
6.3.1. Session ID .........................................49
6.3.2. WNonce .............................................49
6.3.3. PSK-MIC ............................................49
6.4. Join Confirm ..............................................49
6.4.1. Session ID .........................................50
6.4.2. PSK-MIC ............................................50
6.5. Echo Request ..............................................50
6.6. Echo Response .............................................50
6.7. Key Update Request ........................................51
6.7.1. Session ID .........................................51
6.7.2. XNonce .............................................51
6.8. Key Update Response .......................................51
6.8.1. Session ID .........................................51
6.8.2. ANonce .............................................51
6.8.3. PSK-MIC ............................................52
6.9. Key Update ACK ............................................52
6.9.1. WNonce .............................................52
6.9.2. PSK-MIC ............................................52
6.10. Key Update Confirm .......................................52
6.10.1. PSK-MIC ...........................................52
6.11. Key Update Trigger .......................................52
6.11.1. Session ID ........................................53
7. WTP Configuration Management ...................................53
7.1. Configuration Consistency .................................53
7.2. Configure Request .........................................54
7.2.1. Administrative State ...............................54
7.2.2. AC Name ............................................55
7.2.3. AC Name with Index .................................55
7.2.4. WTP Board Data .....................................56
7.2.5. Statistics Timer ...................................56
7.2.6. WTP Static IP Address Information ..................57
7.2.7. WTP Reboot Statistics ..............................58
7.3. Configure Response ........................................58
7.3.1. Decryption Error Report Period .....................59
7.3.2. Change State Event .................................59
7.3.3. LWAPP Timers .......................................60
7.3.4. AC IPv4 List .......................................60
7.3.5. AC IPv6 List .......................................61
7.3.6. WTP Fallback .......................................61
7.3.7. Idle Timeout .......................................61
7.4. Configuration Update Request ..............................62
7.4.1. WTP Name ...........................................62
7.4.2. Change State Event .................................62
7.4.3. Administrative State ...............................62
7.4.4. Statistics Timer ...................................62
7.4.5. Location Data ......................................62
7.4.6. Decryption Error Report Period .....................62
7.4.7. AC IPv4 List .......................................62
7.4.8. AC IPv6 List .......................................62
7.4.9. Add Blacklist Entry ................................63
7.4.10. Delete Blacklist Entry ............................63
7.4.11. Add Static Blacklist Entry ........................64
7.4.12. Delete Static Blacklist Entry .....................64
7.4.13. LWAPP Timers ......................................65
7.4.14. AC Name with Index ................................65
7.4.15. WTP Fallback ......................................65
7.4.16. Idle Timeout ......................................65
7.5. Configuration Update Response .............................65
7.5.1. Result Code ........................................65
7.6. Change State Event Request ................................65
7.6.1. Change State Event .................................66
7.7. Change State Event Response ...............................66
7.8. Clear Config Indication ...................................66
8. Device Management Operations ...................................66
8.1. Image Data Request ........................................66
8.1.1. Image Download .....................................67
8.1.2. Image Data .........................................67
8.2. Image Data Response .......................................68
8.3. Reset Request .............................................68
8.4. Reset Response ............................................68
8.5. WTP Event Request .........................................68
8.5.1. Decryption Error Report ............................69
8.5.2. Duplicate IPv4 Address .............................69
8.5.3. Duplicate IPv6 Address .............................70
8.6. WTP Event Response ........................................70
8.7. Data Transfer Request .....................................71
8.7.1. Data Transfer Mode .................................71
8.7.2. Data Transfer Data .................................71
8.8. Data Transfer Response ....................................72
9. Mobile Session Management ......................................72
9.1. Mobile Config Request .....................................72
9.1.1. Delete Mobile ......................................73
9.2. Mobile Config Response ....................................73
9.2.1. Result Code ........................................74
10. LWAPP Security ................................................74
10.1. Securing WTP-AC Communications ...........................74
10.2. LWAPP Frame Encryption ...................................75
10.3. Authenticated Key Exchange ...............................76
10.3.1. Terminology .......................................76
10.3.2. Initial Key Generation ............................77
10.3.3. Refreshing Cryptographic Keys .....................81
10.4. Certificate Usage ........................................82
11. IEEE 802.11 Binding ...........................................82
11.1. Division of Labor ........................................82
11.1.1. Split MAC .........................................83
11.1.2. Local MAC .........................................85
11.2. Roaming Behavior and 802.11 Security .....................87
11.3. Transport-Specific Bindings ..............................88
11.3.1. Status and WLANS Field ............................88
11.4. BSSID to WLAN ID Mapping .................................89
11.5. Quality of Service .......................................89
11.6. Data Message Bindings ....................................90
11.7. Control Message Bindings .................................90
11.7.1. Mobile Config Request .............................90
11.7.2. WTP Event Request .................................96
11.8. 802.11 Control Messages ..................................97
11.8.1. IEEE 802.11 WLAN Config Request ...................98
11.8.2. IEEE 802.11 WLAN Config Response .................103
11.8.3. IEEE 802.11 WTP Event ............................103
11.9. Message Element Bindings ................................105
11.9.1. IEEE 802.11 WTP WLAN Radio Configuration .........105
11.9.2. IEEE 802.11 Rate Set .............................107
11.9.3. IEEE 802.11 Multi-Domain Capability ..............107
11.9.4. IEEE 802.11 MAC Operation ........................108
11.9.5. IEEE 802.11 Tx Power .............................109
11.9.6. IEEE 802.11 Tx Power Level .......................110
11.9.7. IEEE 802.11 Direct Sequence Control ..............110
11.9.8. IEEE 802.11 OFDM Control .........................111
11.9.9. IEEE 802.11 Antenna ..............................112
11.9.10. IEEE 802.11 Supported Rates .....................113
11.9.11. IEEE 802.11 CFP Status ..........................114
11.9.12. IEEE 802.11 WTP Mode and Type ...................114
11.9.13. IEEE 802.11 Broadcast Probe Mode ................115
11.9.14. IEEE 802.11 WTP Quality of Service ..............115
11.9.15. IEEE 802.11 MIC Error Report From Mobile ........117
11.10. IEEE 802.11 Message Element Values .....................117
12. LWAPP Protocol Timers ........................................118
12.1. MaxDiscoveryInterval ....................................118
12.2. SilentInterval ..........................................118
12.3. NeighborDeadInterval ....................................118
12.4. EchoInterval ............................................118
12.5. DiscoveryInterval .......................................118
12.6. RetransmitInterval ......................................119
12.7. ResponseTimeout .........................................119
12.8. KeyLifetime .............................................119
13. LWAPP Protocol Variables .....................................119
13.1. MaxDiscoveries ..........................................119
13.2. DiscoveryCount ..........................................119
13.3. RetransmitCount .........................................119
13.4. MaxRetransmit ...........................................120
14. NAT Considerations ...........................................120
15. Security Considerations ......................................121
15.1. Certificate-Based Session Key Establishment .............122
15.2. PSK-Based Session Key Establishment .....................123
16. Acknowledgements .............................................123
17. References ...................................................123
17.1. Normative References ....................................123
17.2. Informative References ..................................124
Unlike wired network elements, Wireless Termination Points (WTPs) require a set of dynamic management and control functions related to their primary task of connecting the wireless and wired mediums. Today, protocols for managing WTPs are either manual static configuration via HTTP, proprietary Layer 2-specific, or non-existent (if the WTPs are self-contained). The emergence of simple 802.11 WTPs that are managed by a WLAN appliance or switch (also known as an Access Controller, or AC) suggests that having a standardized, interoperable protocol could radically simplify the deployment and management of wireless networks. In many cases, the overall control and management functions themselves are generic and could apply to an AP for any wireless Layer 2 (L2) protocol. Being independent of specific wireless Layer 2 technologies, such a protocol could better support interoperability between Layer 2 devices and enable smoother intertechnology handovers.
有線ネットワーク要素とは異なり、ワイヤレス終端ポイント（WTPS）には、ワイヤレス媒体と有線媒体を接続するという主要なタスクに関連する動的管理および制御機能のセットが必要です。今日、WTPを管理するためのプロトコルは、HTTP、独自のレイヤー2固有、または存在しない（WTPSが自己完結型である場合）を介した手動静的構成です。WLANアプライアンスまたはスイッチ（アクセスコントローラー、またはACとも呼ばれる）によって管理される単純な802.11 WTPSの出現は、標準化された相互運用可能なプロトコルを持つことで、ワイヤレスネットワークの展開と管理を根本的に簡素化できることを示唆しています。多くの場合、全体的な制御および管理機能自体は汎用であり、任意のワイヤレスレイヤー2（L2）プロトコルにAPに適用できます。特定のワイヤレスレイヤー2テクノロジーとは独立しているため、このようなプロトコルはレイヤー2デバイス間の相互運用性をより適切にサポートし、スムーズなインターテクノロジーハンドオーバーを有効にします。
The details of how these functions would be implemented are dependent on the particular Layer 2 wireless technology. Such a protocol would need provisions for binding to specific technologies.
これらの機能がどのように実装されるかの詳細は、特定のレイヤー2ワイヤレステクノロジーに依存します。このようなプロトコルには、特定のテクノロジーに拘束するための規定が必要です。
LWAPP assumes a network configuration that consists of multiple WTPs communicating either via Layer 2 (Medium Access Control (MAC)) or Layer 3 (IP) to an AC. The WTPs can be considered as remote radio frequency (RF) interfaces, being controlled by the AC. The AC forwards all L2 frames it wants to transmit to a WTP via the LWAPP protocol. Packets from mobile nodes are forwarded by the WTP to the AC, also via this protocol. Figure 1 illustrates this arrangement as applied to an IEEE 802.11 binding.
LWAPPは、レイヤー2（中アクセス制御（MAC））またはレイヤー3（IP）を介してACに通信する複数のWTPで構成されるネットワーク構成を想定しています。WTPは、ACによって制御されるリモート無線周波数（RF）インターフェイスと見なすことができます。ACは、LWAPPプロトコルを介してWTPに送信したいすべてのL2フレームを転送します。モバイルノードからのパケットは、このプロトコルを介してWTPによってACに転送されます。図1は、IEEE 802.11バインディングに適用されるこの配置を示しています。
+-+ 802.11 frames +-+
| |--------------------------------| |
| | +-+ | |
| |--------------| |---------------| |
| | 802.11 PHY/ | | LWAPP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA WTP AC
Figure 1: LWAPP Architecture
図1：LWAPPアーキテクチャ
Security is another aspect of Wireless Termination Point management that is not well served by existing solutions. Provisioning WTPs with security credentials, and managing which WTPs are authorized to provide service are today handled by proprietary solutions. Allowing these functions to be performed from a centralized AC in an interoperable fashion increases manageability and allows network operators to more tightly control their wireless network infrastructure.
セキュリティは、既存のソリューションによって十分に役立たないワイヤレス終了点管理のもう1つの側面です。セキュリティ資格情報を使用してWTPSをプロビジョニングし、WTPSがサービスを提供することを許可されていることを管理することは、現在、独自のソリューションによって処理されます。これらの機能を集中型ACから相互運用可能な方法で実行できるようにすると、管理性が向上し、ネットワークオペレーターがワイヤレスネットワークインフラストラクチャをより厳密に制御できるようになります。
This document describes the Lightweight Access Point Protocol (LWAPP), allowing an AC to manage a collection of WTPs. The protocol is defined to be independent of Layer 2 technology, but an 802.11 binding is provided for use in growing 802.11 wireless LAN networks.
このドキュメントでは、軽量アクセスポイントプロトコル（LWAPP）について説明し、ACがWTPのコレクションを管理できるようにします。このプロトコルは、レイヤー2テクノロジーから独立していると定義されていますが、802.11ワイヤレスLANネットワークの成長に使用するために802.11のバインディングが提供されます。
Goals:
目標：
The following are goals for this protocol:
以下は、このプロトコルの目標です。
1. Centralization of the bridging, forwarding, authentication, and policy enforcement functions for a wireless network. Optionally, the AC may also provide centralized encryption of user traffic. This will permit reduced cost and higher efficiency when applying the capabilities of network processing silicon to the wireless network, as it has already been applied to wired LANs.
1. ワイヤレスネットワークのブリッジング、転送、認証、およびポリシー施行機能の集中化。オプションで、ACはユーザートラフィックの集中暗号化を提供する場合があります。これにより、ワイヤレスネットワークにネットワーク処理シリコンの機能を適用する際に、コストが削減され、効率が高くなります。これは、有線LANにすでに適用されているためです。
2. Permit shifting of the higher-level protocol processing burden away from the WTP. This leaves the computing resource of the WTP to the timing-critical applications of wireless control and access. This makes the most efficient use of the computing power available in WTPs that are the subject of severe cost pressure.
2. WTPから離れた高レベルのプロトコル処理の負担のシフトを許可します。これにより、WTPのコンピューティングリソースは、ワイヤレスコントロールとアクセスのタイミングクリティカルなアプリケーションに残されます。これにより、重度のコスト圧力の対象であるWTPで利用可能なコンピューティング能力を最も効率的に使用できます。
3. Providing a generic encapsulation and transport mechanism, the protocol may be applied to other access point types in the future by adding the binding.
3. 一般的なカプセル化と輸送メカニズムを提供すると、プロトコルは、バインディングを追加することにより、将来他のアクセスポイントタイプに適用される場合があります。
The LWAPP protocol concerns itself solely with the interface between the WTP and the AC. Inter-AC, or mobile-to-AC communication is strictly outside the scope of this document.
LWAPPプロトコルは、WTPとACの間のインターフェースのみに関係しています。Inter-AC、またはモバイル間通信は、このドキュメントの範囲外です。
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]に記載されているように解釈される。
LWAPP is a generic protocol defining how Wireless Termination Points communicate with Access Controllers. Wireless Termination Points and Access Controllers may communicate either by means of Layer 2 protocols or by means of a routed IP network.
LWAPPは、ワイヤレス終了ポイントがアクセスコントローラーと通信する方法を定義する一般的なプロトコルです。ワイヤレス終了ポイントとアクセスコントローラーは、レイヤー2プロトコルまたはルーティングされたIPネットワークによって通信する場合があります。
LWAPP messages and procedures defined in this document apply to both types of transports unless specified otherwise. Transport independence is achieved by defining formats for both MAC-level and IP-level transport (see Section 3). Also defined are framing, fragmentation/reassembly, and multiplexing services to LWAPP for each transport type.
このドキュメントで定義されているLWAPPメッセージと手順は、特に指定されていない限り、両方のタイプのトランスポートに適用されます。輸送の独立性は、MacレベルとIPレベルの両方のトランスポートの形式を定義することで達成されます（セクション3を参照）。また、各輸送タイプのFraming、Fraymentation/再組み立て、およびLWAPPへの多重化サービスも定義されています。
The LWAPP Transport layer carries two types of payload. LWAPP data messages are forwarded wireless frames. LWAPP control messages are management messages exchanged between a WTP and an AC. The LWAPP transport header defines the "C-bit", which is used to distinguish data and control traffic. When used over IP, the LWAPP data and control traffic are also sent over separate UDP ports. Since both data and control frames can exceed Path Maximum Transmission Unit (PMTU), the payload of an LWAPP data or control message can be fragmented. The fragmentation behavior is highly dependent upon the lower-layer transport and is defined in Section 3.
LWAPP輸送層には、2種類のペイロードが搭載されています。LWAPPデータメッセージは、転送されたワイヤレスフレームです。LWAPPコントロールメッセージは、WTPとACの間で交換される管理メッセージです。LWAPPトランスポートヘッダーは、データを区別し、トラフィックを制御するために使用される「Cビット」を定義します。IPで使用すると、LWAPPデータと制御トラフィックも個別のUDPポートを介して送信されます。データとコントロールフレームの両方がパス最大伝送ユニット（PMTU）を超える可能性があるため、LWAPPデータまたはコントロールメッセージのペイロードを断片化できます。断片化挙動は、低層輸送に大きく依存しており、セクション3で定義されています。
The Lightweight Access Protocol (LWAPP) begins with a discovery phase. The WTPs send a Discovery Request frame, causing any Access Controller (AC), receiving that frame to respond with a Discovery Response. From the Discovery Responses received, a WTP will select an AC with which to associate, using the Join Request and Join Response. The Join Request also provides an MTU discovery mechanism, to determine whether there is support for the transport of large frames between the WTP and its AC. If support for large frames is not present, the LWAPP frames will be fragmented to the maximum length discovered to be supported by the network.
軽量アクセスプロトコル（LWAPP）は、発見フェーズから始まります。WTPSはディスカバリーリクエストフレームを送信し、アクセスコントローラー（AC）を引き起こし、そのフレームを受信して発見応答で応答します。受信したディスカバリー応答から、WTPは、参加要求と参加応答を使用して、関連付けるACを選択します。Join Requestは、WTPとそのAC間の大きなフレームの輸送のサポートがあるかどうかを判断するために、MTU発見メカニズムも提供します。大きなフレームのサポートが存在しない場合、LWAPPフレームは、ネットワークによってサポートされることが発見された最大長に断片化されます。
Once the WTP and the AC have joined, a configuration exchange is accomplished that will cause both devices to agree on version information. During this exchange, the WTP may receive provisioning settings. For the 802.11 binding, this information would typically include a name (802.11 Service Set Identifier, SSID), and security parameters, the data rates to be advertised, as well as the radio channel (channels, if the WTP is capable of operating more than one 802.11 MAC and Physical Layer (PHY) simultaneously) to be used. Finally, the WTPs are enabled for operation.
WTPとACが参加すると、両方のデバイスがバージョン情報に同意する構成交換が達成されます。この交換中、WTPはプロビジョニング設定を受信する場合があります。802.11バインディングの場合、この情報には通常、名前（802.11サービスセット識別子、SSID）、セキュリティパラメーター、宣伝されるデータレート、および無線チャネル（WTPがより多く動作できる場合は、ラジオチャネルが含まれます。使用する1つの802.11 MACと物理層（PHY）を同時に）。最後に、wtpsが操作のために有効になります。
When the WTP and AC have completed the version and provision exchange and the WTP is enabled, the LWAPP encapsulates the wireless frames sent between them. LWAPP will fragment its packets, if the size of the encapsulated wireless user data (Data) or protocol control (Management) frames cause the resultant LWAPP packet to exceed the MTU supported between the WTP and AC. Fragmented LWAPP packets are reassembled to reconstitute the original encapsulated payload.
WTPとACがバージョンとプロビジョニング交換を完了し、WTPが有効になっている場合、LWAPPはそれらの間に送信されるワイヤレスフレームをカプセル化します。LWAPPは、カプセル化されたワイヤレスユーザーデータ（データ）またはプロトコル制御（管理）フレームのサイズが、結果のLWAPPパケットがWTPとACの間でサポートされるMTUを超えると、パケットを断片化します。断片化されたLWAPPパケットは、元のカプセル化されたペイロードを再構成するために再組み立てされています。
In addition to the functions thus far described, LWAPP also provides for the delivery of commands from the AC to the WTP for the management of devices that are communicating with the WTP. This may include the creation of local data structures in the WTP for the managed devices and the collection of statistical information about the communication between the WTP and the 802.11 devices. LWAPP provides the ability for the AC to obtain any statistical information collected by the WTP.
これまでに説明した関数に加えて、LWAPPは、WTPと通信しているデバイスの管理のために、ACからWTPへのコマンドの配信も提供します。これには、管理されたデバイス用のWTP内のローカルデータ構造の作成と、WTPと802.11デバイス間の通信に関する統計情報の収集が含まれる場合があります。LWAPPは、ACがWTPによって収集された統計情報を取得する機能を提供します。
LWAPP also provides for a keepalive feature that preserves the communication channel between the WTP and AC. If the AC fails to appear alive, the WTP will try to discover a new AC to communicate through.
LWAPPは、WTPとACの間の通信チャネルを保持するキープライブ機能も提供します。ACが生き残っていない場合、WTPは通信する新しいACを発見しようとします。
This document uses terminology defined in [5].
この文書は、[5]で定義されている用語を使用します。
This draft standard specifies a protocol independent of a specific wireless access point radio technology. Elements of the protocol are designed to accommodate specific needs of each wireless technology in a standard way. Implementation of this standard for a particular wireless technology must follow the binding requirements defined for that technology. This specification includes a binding for the IEEE 802.11 (see Section 11).
このドラフト標準は、特定のワイヤレスアクセスポイントラジオテクノロジーとは無関係にプロトコルを指定します。プロトコルの要素は、標準的な方法で各ワイヤレステクノロジーの特定のニーズに対応するように設計されています。特定のワイヤレステクノロジーのこの標準の実装は、そのテクノロジーで定義された拘束力のある要件に従う必要があります。この仕様には、IEEE 802.11のバインディングが含まれています（セクション11を参照）。
When defining a binding for other technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. At a minimum, a binding MUST provide the definition for a binding-specific Statistics message element, which is carried in the WTP Event Request message, and Add Mobile message element, which is carried in the Mobile Configure Request. If any technology-specific message elements are required for any of the existing LWAPP messages defined in this specification, they MUST also be defined in the technology-binding document.
他のテクノロジーの拘束力を定義する場合、著者は、テクノロジー固有のメッセージに必要な定義と、それらのメッセージにすべてのテクノロジー固有のメッセージ要素を含める必要があります。少なくとも、バインディングは、WTPイベントリクエストメッセージに掲載されるバインディング固有の統計メッセージ要素の定義を提供し、モバイル構成要素に掲載されるモバイルメッセージ要素を追加する必要があります。この仕様で定義されている既存のLWAPPメッセージのいずれかに技術固有のメッセージ要素が必要な場合は、テクノロジー拘束ドキュメントでも定義する必要があります。
The naming of binding-specific message elements MUST begin with the name of the technology type, e.g., the binding for IEEE 802.11, provided in this standard, begins with "IEEE 802.11".
結合固有のメッセージ要素の命名は、テクノロジータイプの名前から始まる必要があります。たとえば、この標準で提供されるIEEE 802.11のバインディングは、「IEEE 802.11」から始まります。
The following state diagram represents the life cycle of a WTP-AC session:
次の状態図は、WTP-ACセッションのライフサイクルを表しています。
/-------------\
| v
| +------------+
| C| Idle |<-----------------------------------\
| +------------+<-----------------------\ |
| ^ |a ^ | |
| | | \----\ | |
| | | | +------------+ |
| | | | -------| Key Confirm| |
| | | | w/ +------------+ |
| | | | | ^ |
| | | |t V |5 |
| | | +-----------+ +------------+ |
| / | C| Run | | Key Update | |
| / | r+-----------+------>+------------+ |
| / | ^ |s u x| |
| | v | | | |
| | +--------------+ | | v |y
| | C| Discovery | q| \--------------->+-------+
| | b+--------------+ +-------------+ | Reset |
| | |d f| ^ | Configure |------->+-------+
| | | | | +-------------+p ^
| |e v | | ^ |
| +---------+ v |i 2| |
| C| Sulking | +------------+ +--------------+ |
| +---------+ C| Join |--->| Join-Confirm | |
| g+------------+z +--------------+ |
| |h m| 3| |4 |
| | | | v |o
|\ | | | +------------+
\\-----------------/ \--------+---->| Image Data |C
\------------------------------------/ +------------+n
Figure 2: LWAPP State Machine
図2：LWAPPステートマシン
The LWAPP state machine, depicted above, is used by both the AC and the WTP. For every state defined, only certain messages are permitted to be sent and received. In all of the LWAPP control messages defined in this document, the state for which each command is valid is specified.
上記のLWAPPステートマシンは、ACとWTPの両方で使用されています。定義されているすべての状態について、特定のメッセージのみが送信および受信が許可されています。このドキュメントで定義されているすべてのLWAPP制御メッセージで、各コマンドが有効な状態が指定されています。
Note that in the state diagram figure above, the 'C' character is used to represent a condition that causes the state to remain the same.
上の状態図では、「C」文字は、状態が同じままになる条件を表すために使用されることに注意してください。
The following text discusses the various state transitions, and the events that cause them.
次のテキストでは、さまざまな状態移行とそれらを引き起こすイベントについて説明します。
Idle to Discovery (a): This is the initialization state.
アイドルからディスカバリー（a）：これは初期化状態です。
WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 12). The WTP resets the DiscoveryCount counter to zero (0) (see Section 13). The WTP also clears all information from ACs (e.g., AC Addresses) it may have received during a previous discovery phase.
WTP：WTPは、最初のディスカバリーリクエストを送信する前に発見状態に入ります（セクション5.1を参照）。この状態に入ると、WTPはDiscoveryIntervalタイマーを設定します（セクション12を参照）。WTPは、DiscoveryCountカウンターをゼロ（0）にリセットします（セクション13を参照）。また、WTPは、以前の発見フェーズで受け取った可能性のあるACS（例：ACアドレス）からすべての情報をクリアします。
AC: The AC does not need to maintain state information for the WTP upon reception of the Discovery Request, but it MUST respond with a Discovery Response (see Section 5.2).
AC：ACは、ディスカバリーリクエストを受信するときにWTPの状態情報を維持する必要はありませんが、発見応答で応答する必要があります（セクション5.2を参照）。
Discovery to Discovery (b): This is the state the WTP uses to determine to which AC it wishes to connect.
発見への発見（b）：これは、WTPが接続したいACを決定するために使用する状態です。
WTP: This event occurs when the DiscoveryInterval timer expires. The WTP transmits a Discovery Request to every AC to which the WTP hasn't received a response. For every transition to this event, the WTP increments the DisoveryCount counter. See Section 5.1 for more information on how the WTP knows to which ACs it should transmit the Discovery Requests. The WTP restarts the DiscoveryInterval timer.
WTP：このイベントは、DiscoveryIntervalタイマーの有効期限が切れたときに発生します。WTPは、WTPが応答を受信していないすべてのACにディスカバリーリクエストを送信します。このイベントへの移行ごとに、WTPはDisoveryCountカウントカウンターを増加させます。WTPがどのACSが発見要求を送信するかについての詳細については、セクション5.1を参照してください。WTPは、DiscoveryIntervalタイマーを再起動します。
AC: This is a noop.
AC：これはヌープです。
Discovery to Sulking (d): This state occurs on a WTP when Discovery or connectivity to the AC fails.
Sulking（d）への発見：この状態は、ACへの発見または接続性が失敗したときにWTPで発生します。
WTP: The WTP enters this state when the DiscoveryInterval timer expires and the DiscoveryCount variable is equal to the MaxDiscoveries variable (see Section 13). Upon entering this state, the WTP will start the SilentInterval timer. While in the Sulking state, all LWAPP messages received are ignored.
WTP：DiscoveryIntervalタイマーが期限切れになり、DiscoveryCount変数がMaxDiscoveries変数に等しい場合、WTPはこの状態に入ります（セクション13を参照）。この状態に入ると、WTPはSilentIntervalタイマーを開始します。suling状態では、受け取ったすべてのLWAPPメッセージは無視されます。
AC: This is a noop.
AC：これはヌープです。
Sulking to Idle (e): This state occurs on a WTP when it must restart the discovery phase.
IDLE（E）へのsuling：この状態は、発見フェーズを再起動する必要がある場合にWTPで発生します。
WTP: The WTP enters this state when the SilentInterval timer (see Section 12) expires.
WTP：WTPは、SilentIntervalタイマー（セクション12を参照）が期限切れになったときにこの状態に入ります。
AC: This is a noop.
AC：これはヌープです。
Discovery to Join (f): This state is used by the WTP to confirm its commitment to an AC that it wishes to be provided service.
Discovery to Into（F）：この状態は、WTPが提供することを望んでいるACへのコミットメントを確認するために使用されます。
WTP: The WTP selects the best AC based on the information it gathered during the discovery phase. It then transmits a Join Request (see Section 6.1) to its preferred AC. The WTP starts the WaitJoin timer (see Section 12).
WTP：WTPは、発見フェーズ中に収集した情報に基づいて、最高のACを選択します。次に、参加要求（セクション6.1を参照）を優先ACに送信します。WTPはWaitJoinタイマーを開始します（セクション12を参照）。
AC: The AC enters this state for the given WTP upon reception of a Join Request. The AC processes the request and responds with a Join Response.
AC：ACは、参加リクエストを受信すると、指定されたWTPに対してこの状態に入ります。ACはリクエストを処理し、Join Responseで応答します。
Join to Join (g): This state transition occurs during the join phase.
Join to Join（g）：この状態遷移は、結合フェーズ中に発生します。
WTP: The WTP enters this state when the WaitJoin timer expires, and the underlying transport requires LWAPP MTU detection (Section 3).
WTP：wtpは、waitjoinタイマーが期限切れになるとこの状態に入り、基礎となる輸送にはLWAPP MTU検出が必要です（セクション3）。
AC: This state occurs when the AC receives a retransmission of a Join Request. The WTP processes the request and responds with the Join Response.
AC：この状態は、ACが参加要求の再送信を受信したときに発生します。WTPはリクエストを処理し、Join Responseで応答します。
Join to Idle (h): This state is used when the join process has failed.
IDLE（H）への参加：この状態は、結合プロセスが失敗したときに使用されます。
WTP: This state transition occurs if the WTP is configured to use pre-shared key (PSK) security and receives a Join Response that includes an invalid PSK-MIC (Message Integrity Check) message element.
WTP：この状態遷移は、WTPが事前共有キー（PSK）セキュリティを使用するように構成され、無効なPSK-MIC（メッセージ整合性チェック）メッセージ要素を含む結合応答を受信する場合に発生します。
AC: The AC enters this state when it transmits an unsuccessful Join Response.
AC：ACは、失敗した結合応答を送信するときにこの状態に入ります。
Join to Discovery (i): This state is used when the join process has failed.
Discoveryに参加（i）：この状態は、結合プロセスが失敗したときに使用されます。
WTP: The WTP enters this state when it receives an unsuccessful Join Response. Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 12). The WTP resets the DiscoveryCount counter to zero (0) (see Section 13). This state transition may also occur if the PSK-MIC (see Section 6.2.9) message element is invalid.
WTP：WTPは、失敗したJOIN Responseを受け取るとこの状態に入ります。この状態に入ると、WTPはDiscoveryIntervalタイマーを設定します（セクション12を参照）。WTPは、DiscoveryCountカウンターをゼロ（0）にリセットします（セクション13を参照）。この状態遷移は、PSK-MIC（セクション6.2.9を参照）メッセージ要素が無効である場合にも発生する可能性があります。
AC: This state transition is invalid.
AC：この状態の移行は無効です。
Join to Join-Confirm (z): This state is used to provide key confirmation during the join process.
Join-confirm（z）に参加：この状態は、参加プロセス中に重要な確認を提供するために使用されます。
WTP: This state is entered when the WTP receives a Join Response. In the event that certificate-based security is utilized, this transition will occur if the Certificate message element is present and valid in the Join Response. For pre-shared key security, the Join Response must include a valid and authenticated PSK-MIC message element. The WTP MUST respond with a Join ACK, which is used to provide key confirmation.
WTP：この状態は、WTPが結合応答を受信したときに入力されます。証明書ベースのセキュリティが利用されている場合、この遷移は、合計メッセージ要素が存在し、結合応答に有効である場合に発生します。事前に共有されるキーセキュリティの場合、結合応答には、有効で認証されたPSK-MICメッセージ要素を含める必要があります。WTPは、重要な確認を提供するために使用されるJoin ACKで応答する必要があります。
AC: The AC enters this state when it receives a valid Join ACK. For certificate-based security, the Join ACK MUST include the WNonce message element. For pre-shared key security, the message must include a valid PSK-MIC message element. The AC MUST respond with a Join Confirm message, which includes the Session Key message element.
AC：ACは、有効な結合ACKを受け取るとこの状態に入ります。証明書ベースのセキュリティの場合、Join ACKにはWNONCEメッセージ要素を含める必要があります。事前に共有されるキーセキュリティの場合、メッセージには有効なPSK-MICメッセージ要素を含める必要があります。ACは、セッションキーメッセージ要素を含むJoin Confismメッセージで応答する必要があります。
Join-Confirm to Idle (3): This state is used when the join process has failed.
Join-Confirm to Idle（3）：この状態は、Joinプロセスが失敗したときに使用されます。
WTP: This state transition occurs when the WTP receives an invalid Join Confirm.
WTP：この状態遷移は、WTPが無効な結合確認を受信したときに発生します。
AC: The AC enters this state when it receives an invalid Join ACK.
AC：ACは、無効な結合ACKを受け取るとこの状態に入ります。
Join-Confirm to Configure (2): This state is used by the WTP and the AC to exchange configuration information.
（2）を構成するためのJoin-Confirm：この状態は、WTPとACによって構成情報を交換するために使用されます。
WTP: The WTP enters this state when it receives a successful Join Confirm and determines that its version number and the version number advertised by the AC are the same. The WTP transmits the Configure Request (see Section 7.2) message to the AC with a snapshot of its current configuration. The WTP also starts the ResponseTimeout timer (see Section 12).
WTP：WTPは、成功したJOINの確認を受け取ったときにこの状態に入り、ACによって宣伝されているバージョン番号とバージョン番号が同じであると判断します。WTPは、現在の構成のスナップショットを使用して、configure request（セクション7.2を参照）メッセージをACに送信します。WTPは、ResponsetimeOutタイマーも開始します（セクション12を参照）。
AC: This state transition occurs when the AC receives the Configure Request from the WTP. The AC must transmit a Configure Response (see Section 7.3) to the WTP, and may include specific message elements to override the WTP's configuration.
AC：この状態遷移は、ACがWTPからConfigure要求を受信したときに発生します。ACは、構成応答（セクション7.3を参照）をWTPに送信する必要があり、WTPの構成をオーバーライドするための特定のメッセージ要素を含めることができます。
Join-Confirm to Image Data (4): This state is used by the WTP and the AC to download executable firmware.
Image Data（4）へのJoin-Confirm：この状態は、WTPとACが実行可能ファームウェアをダウンロードするために使用されます。
WTP: The WTP enters this state when it receives a successful Join Confirm, and determines that its version number and the version number advertised by the AC are different. The WTP transmits the Image Data Request (see Section 8.1) message requesting that the AC's latest firmware be initiated.
WTP：WTPは、成功したJOINの確認を受け取ったときにこの状態に入り、ACによって宣伝されているバージョン番号とバージョン番号が異なると判断します。WTPは、ACの最新のファームウェアを開始することを要求する画像データ要求（セクション8.1を参照）メッセージを送信します。
AC: This state transition occurs when the AC receives the Image Data Request from the WTP. The AC must transmit an Image Data Response (see Section 8.2) to the WTP, which includes a portion of the firmware.
AC：この状態遷移は、ACがWTPから画像データ要求を受信したときに発生します。ACは、ファームウェアの一部を含む画像データ応答（セクション8.2を参照）をWTPに送信する必要があります。
Image Data to Image Data (n): This state is used by the WTP and the AC during the firmware download phase.
画像データから画像データ（n）：この状態は、ファームウェアのダウンロードフェーズ中にWTPとACで使用されます。
WTP: The WTP enters this state when it receives an Image Data Response that indicates that the AC has more data to send.
WTP：WTPは、ACに送信するデータが増えることを示す画像データ応答を受信すると、この状態に入ります。
AC: This state transition occurs when the AC receives the Image Data Request from the WTP while already in this state, and it detects that the firmware download has not completed.
AC：この状態の遷移は、ACがすでにこの状態にいる間にWTPから画像データ要求を受信したときに発生し、ファームウェアのダウンロードが完了していないことを検出します。
Image Data to Reset (o): This state is used when the firmware download is completed.
リセットする画像データ（o）：この状態は、ファームウェアのダウンロードが完了したときに使用されます。
WTP: The WTP enters this state when it receives an Image Data Response that indicates that the AC has no more data to send, or if the underlying LWAPP transport indicates a link failure. At this point, the WTP reboots itself.
WTP：WTPは、ACに送信するデータがないことを示す画像データ応答を受信すると、この状態に入ります。この時点で、WTPはそれ自体を再起動します。
AC: This state transition occurs when the AC receives the Image Data Request from the WTP while already in this state, and it detects that the firmware download has completed or if the underlying LWAPP transport indicates a link failure. Note that the AC itself does not reset, but it places the specific WTP's context it is communicating with in the reset state: meaning that it clears all state associated with the WTP.
AC：この状態の遷移は、ACがすでにこの状態にいる間にWTPから画像データ要求を受信したときに発生し、ファームウェアのダウンロードが完了したこと、または基礎となるLWAPP輸送がリンクの障害を示している場合に発生します。AC自体はリセットされませんが、リセット状態で通信している特定のWTPのコンテキストを配置することに注意してください。つまり、WTPに関連するすべての状態をクリアします。
Configure to Reset (p): This state transition occurs if the configure phase fails.
構成（p）：この状態遷移は、構成位相が失敗した場合に発生します。
WTP: The WTP enters this state when the reliable transport fails to deliver the Configure Request, or if the ResponseTimeout timer (see Section 12) expires.
WTP：信頼できるトランスポートがConfigureリクエストの配信に失敗した場合、またはResponsetimeOutタイマー（セクション12を参照）が失効した場合、WTPはこの状態に入ります。
AC: This state transition occurs if the AC is unable to transmit the Configure Response to a specific WTP. Note that the AC itself does not reset, but it places the specific WTP's context it is communicating with in the reset state: meaning that it clears all state associated with the WTP.
AC：ACが特定のWTPへの構成応答を送信できない場合、この状態遷移が発生します。AC自体はリセットされませんが、リセット状態で通信している特定のWTPのコンテキストを配置することに注意してください。つまり、WTPに関連するすべての状態をクリアします。
Configure to Run (q): This state transition occurs when the WTP and AC enter their normal state of operation.
実行する構成（q）：この状態遷移は、WTPとACが通常の動作状態に入ると発生します。
WTP: The WTP enters this state when it receives a successful Configure Response from the AC. The WTP initializes the HeartBeat timer (see Section 12), and transmits the Change State Event Request message (see Section 7.6).
WTP：WTPは、ACから成功した構成応答を受信するとこの状態に入ります。WTPは、ハートビートタイマーを初期化し（セクション12を参照）、変更状態イベントリクエストメッセージを送信します（セクション7.6を参照）。
AC: This state transition occurs when the AC receives the Change State Event Request (see Section 7.6) from the WTP. The AC responds with a Change State Event Response (see Section 7.7) message. The AC must start the Session ID and NeighborDead timers (see Section 12).
AC：この状態遷移は、ACがWTPから変更状態イベント要求（セクション7.6を参照）を受信したときに発生します。ACは、変更状態イベント応答（セクション7.7を参照）メッセージで応答します。ACはセッションIDとNeighbordeadタイマーを開始する必要があります（セクション12を参照）。
Run to Run (r): This is the normal state of operation.
Run to Run（R）：これは通常の動作状態です。
WTP: This is the WTP's normal state of operation, and there are many events that cause this to occur:
WTP：これはWTPの通常の動作状態であり、これを発生させる多くのイベントがあります。
Configuration Update: The WTP receives a Configuration Update Request (see Section 7.4). The WTP MUST respond with a Configuration Update Response (see Section 7.5).
構成更新：WTPは、構成更新リクエストを受信します（セクション7.4を参照）。WTPは、構成更新応答で応答する必要があります（セクション7.5を参照）。
Change State Event: The WTP receives a Change State Event Response, or determines that it must initiate a Change State Event Request, as a result of a failure or change in the state of a radio.
変更状態イベント：WTPは、変更状態イベントの応答を受け取るか、無線の状態の失敗または変更の結果として、変更状態イベントリクエストを開始する必要があると判断します。
Echo Request: The WTP receives an Echo Request message (Section 6.5), to which it MUST respond with an Echo Response (see Section 6.6).
エコーリクエスト：WTPはエコーリクエストメッセージ（セクション6.5）を受信し、エコー応答で応答する必要があります（セクション6.6を参照）。
Clear Config Indication: The WTP receives a Clear Config Indication message (Section 7.8). The WTP MUST reset its configuration back to manufacturer defaults.
クリア設定の表示：WTPは、クリア設定表示メッセージを受信します（セクション7.8）。WTPは、構成をメーカーのデフォルトに戻す必要があります。
WTP Event: The WTP generates a WTP Event Request to send information to the AC (Section 8.5). The WTP receives a WTP Event Response from the AC (Section 8.6).
WTPイベント：WTPは、AC（セクション8.5）に情報を送信するWTPイベントリクエストを生成します。WTPは、ACからWTPイベント応答を受け取ります（セクション8.6）。
Data Transfer: The WTP generates a Data Transfer Request to the AC (Section 8.7). The WTP receives a Data Transfer Response from the AC (Section 8.8).
データ転送：WTPは、ACへのデータ転送要求を生成します（セクション8.7）。WTPは、ACからデータ転送応答を受け取ります（セクション8.8）。
WLAN Config Request: The WTP receives a WLAN Config Request message (Section 11.8.1), to which it MUST respond with a WLAN Config Response (see Section 11.8.2).
WLAN構成要求：WTPはWLAN構成要求メッセージ（セクション11.8.1）を受信し、WLAN構成応答で応答する必要があります（セクション11.8.2を参照）。
Mobile Config Request: The WTP receives an Mobile Config Request message (Section 9.1), to which it MUST respond with a Mobile Config Response (see Section 9.2).
モバイル構成要求：WTPはモバイル構成要求メッセージ（セクション9.1）を受信し、モバイル構成応答で応答する必要があります（セクション9.2を参照）。
AC: This is the AC's normal state of operation, and there are many events that cause this to occur:
AC：これはACの通常の動作状態であり、これを発生させる多くのイベントがあります。
Configuration Update: The AC sends a Configuration Update Request (see Section 7.4) to the WTP to update its configuration. The AC receives a Configuration Update Response (see Section 7.5) from the WTP.
構成更新：ACは、構成の更新要求（セクション7.4を参照）をWTPに送信して、その構成を更新します。ACは、WTPから構成更新応答（セクション7.5を参照）を受信します。
Change State Event: The AC receives a Change State Event Request (see Section 7.6), to which it MUST respond with the Change State Event Response (see Section 7.7).
変更状態イベント：ACは、変更状態イベントリクエスト（セクション7.6を参照）を受信します。
Echo: The AC sends an Echo Request message (Section 6.5) or receives the associated Echo Response (see Section 6.6) from the WTP.
ECHO：ACはエコー要求メッセージ（セクション6.5）を送信するか、WTPから関連するエコー応答（セクション6.6を参照）を受信します。
Clear Config Indication: The AC sends a Clear Config Indication message (Section 7.8).
設定の明確な表示：ACは、Clear Config表示メッセージを送信します（セクション7.8）。
WLAN Config: The AC sends a WLAN Config Request message (Section 11.8.1) or receives the associated WLAN Config Response (see Section 11.8.2) from the WTP.
WLAN構成：ACは、WTPからWLAN構成要求メッセージ（セクション11.8.1）を送信するか、関連するWLAN構成応答（セクション11.8.2を参照）を受信します。
Mobile Config: The AC sends a Mobile Config Request message (Section 9.1) or receives the associated Mobile Config Response (see Section 9.2) from the WTP.
モバイル構成：ACはモバイル構成要求メッセージ（セクション9.1）を送信するか、WTPから関連するモバイル構成応答（セクション9.2を参照）を受信します。
Data Transfer: The AC receives a Data Transfer Request from the AC (see Section 8.7) and MUST generate the associated Data Transfer Response message (see Section 8.8).
データ転送：ACは、ACからデータ転送要求を受信し（セクション8.7を参照）、関連するデータ転送応答メッセージを生成する必要があります（セクション8.8を参照）。
WTP Event: The AC receives a WTP Event Request from the AC (see Section 8.5) and MUST generate the associated WTP Event Response message (see Section 8.6).
WTPイベント：ACは、ACからWTPイベントリクエストを受信し（セクション8.5を参照）、関連するWTPイベント応答メッセージ（セクション8.6を参照）を生成する必要があります。
Run to Reset (s): This event occurs when the AC wishes for the WTP to reboot.
リセットに実行：このイベントは、ACがWTPが再起動することを望んでいるときに発生します。
WTP: The WTP enters this state when it receives a Reset Request (see Section 8.3). It must respond with a Reset Response (see Section 8.4), and once the reliable transport acknowledgement has been received, it must reboot itself.
WTP：WTPは、リセットリクエストを受信するとこの状態に入ります（セクション8.3を参照）。リセット応答（セクション8.4を参照）で応答する必要があり、信頼できる輸送承認が受信されたら、それ自体を再起動する必要があります。
AC: This state transition occurs either through some administrative action, or via some internal event on the AC that causes it to request that the WTP disconnect. Note that the AC itself does not reset, but it places the specific WTPs context it is communicating with in the reset state.
AC：この状態遷移は、何らかの管理措置を介して、またはAC上の内部イベントを介して発生し、WTPが切断されることを要求します。AC自体はリセットされませんが、リセット状態で通信している特定のWTPSコンテキストを配置することに注意してください。
Run to Idle (t): This event occurs when an error occurs in the communication between the WTP and the AC.
IDLE（T）に実行：このイベントは、WTPとACの間の通信でエラーが発生したときに発生します。
WTP: The WTP enters this state when the underlying reliable transport is unable to transmit a message within the RetransmitInterval timer (see Section 12), and the maximum number of RetransmitCount counter has reached the MaxRetransmit variable (see Section 13).
WTP：基礎となる信頼性の高い輸送が再送信介入タイマー内でメッセージを送信できない場合（セクション12を参照）、retransmitCountカウンターの最大数がMaxretransmit変数に到達した場合（セクション13を参照）、WTPはこの状態に入ります。
AC: The AC enters this state when the underlying reliable transport in unable to transmit a message within the RetransmitInterval timer (see Section 12), and the maximum number of RetransmitCount counter has reached the MaxRetransmit variable (see Section 13).
AC：ACは、再送信インターバルタイマー内でメッセージを送信できないという根本的な信頼できる輸送がこの状態に入り（セクション12を参照）、RecransmitCountカウンターの最大数はMaxRetransmit変数に達しました（セクション13を参照）。
Run to Key Update (u): This event occurs when the WTP and the AC are to exchange new keying material, with which it must use to protect all future messages.
キーアップデート（u）に実行されます。このイベントは、WTPとACが新しいキーイング素材を交換する場合に発生します。これは、すべての将来のメッセージを保護するために使用する必要があります。
WTP: This state transition occurs when the KeyLifetime timer expires (see Section 12).
WTP：この状態遷移は、キーライフタイムタイマーの有効期限が切れると発生します（セクション12を参照）。
AC: The WTP enters this state when it receives a Key Update Request (see Section 6.7).
AC：WTPは、キーアップデートリクエストを受信するとこの状態に入ります（セクション6.7を参照）。
Key Update to Key Confirm (w): This event occurs during the rekey phase and is used to complete the loop.
Key Confirmのキーアップデート（W）：このイベントはRekeyフェーズ中に発生し、ループを完了するために使用されます。
WTP: This state transition occurs when the WTP receives the Key Update Response. The WTP MUST only accept the message if it is authentic. The WTP responds to this response with a Key Update ACK.
WTP：この状態遷移は、WTPがキーアップデート応答を受信したときに発生します。WTPは、本物の場合にのみメッセージを受け入れる必要があります。WTPは、キーアップデートACKでこの応答に応答します。
AC: The AC enters this state when it receives an authenticated Key Update ACK message.
AC：ACは、認証されたキーアップデートACKメッセージを受信すると、この状態に入ります。
Key Confirm to Run (5): This event occurs when the rekey exchange phase is completed.
実行するキー確認（5）：このイベントは、Rekey Exchangeフェーズが完了したときに発生します。
WTP: This state transition occurs when the WTP receives the Key Update Confirm. The newly derived encryption key and Initialization Vector (IV) must be plumbed into the crypto module after validating the message's authentication.
WTP：この状態遷移は、WTPがキーアップデートの確認を受信したときに発生します。新しく派生した暗号化キーと初期化ベクトル（IV）は、メッセージの認証を検証した後、Cryptoモジュールに配管する必要があります。
AC: The AC enters this state when it transmits the Key Update Confirm message. The newly derived encryption key and IV must be plumbed into the crypto module after transmitting a Key Update Confirm message.
AC：ACは、キーアップデートの確認メッセージを送信すると、この状態に入ります。新しく派生した暗号化キーとIVは、キーアップデートの確認メッセージを送信した後、Cryptoモジュールに配管する必要があります。
Key Update to Reset (x): This event occurs when the key exchange phase times out.
リセットのキーアップデート（x）：このイベントは、キーエクスチェンジフェーズがタイムアウトするときに発生します。
WTP: This state transition occurs when the WTP does not receive a Key Update Response from the AC.
WTP：この状態遷移は、WTPがACからキーアップデート応答を受け取らない場合に発生します。
AC: The AC enters this state when it is unable to process a Key Update Request.
AC：ACは、キーアップデートリクエストを処理できない場合にこの状態に入ります。
Reset to Idle (y): This event occurs when the state machine is restarted.
IDLE（Y）にリセット：このイベントは、状態マシンが再起動されたときに発生します。
WTP: The WTP reboots itself. After rebooting, the WTP will start its LWAPP state machine in the Idle state.
WTP：WTPはそれ自体を再起動します。再起動した後、WTPはアイドル状態でLWAPP状態マシンを起動します。
AC: The AC clears out any state associated with the WTP. The AC generally does this as a result of the reliable link layer timing out.
AC：ACは、WTPに関連する状態をクリアします。ACは通常、信頼できるリンク層のタイミングの結果としてこれを行います。
The LWAPP protocol can operate at Layer 2 or 3. For Layer 2 support, the LWAPP messages are carried in a native Ethernet frame. As such, the protocol is not routable and depends upon Layer 2 connectivity between the WTP and the AC. Layer 3 support is provided by encapsulating the LWAPP messages within UDP.
LWAPPプロトコルは、レイヤー2または3で動作できます。レイヤー2サポートの場合、LWAPPメッセージはネイティブイーサネットフレームで運ばれます。そのため、プロトコルはルーティング可能ではなく、WTPとACの間のレイヤー2接続に依存します。レイヤー3サポートは、UDP内のLWAPPメッセージをカプセル化することにより提供されます。
All LWAPP protocol packets are encapsulated using a common header format, regardless of the transport used to carry the frames. However, certain flags are not applicable for a given transport, and it is therefore necessary to refer to the specific transport section in order to determine which flags are valid.
すべてのLWAPPプロトコルパケットは、フレームを運ぶために使用されるトランスポートに関係なく、共通のヘッダー形式を使用してカプセル化されています。ただし、特定のフラグは特定の輸送には適用されないため、どのフラグが有効であるかを判断するために、特定の輸送セクションを参照する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER| RID |C|F|L| Frag ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status/WLANs | Payload... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A 2-bit field that contains the version of LWAPP used in this packet. The value for this document is 0.
このパケットで使用されるLWAPPのバージョンを含む2ビットフィールド。このドキュメントの値は0です。
A 3-bit field that contains the Radio ID number for this packet. WTPs with multiple radios but a single MAC address use this field to indicate which radio is associated with the packet.
このパケットのラジオID番号を含む3ビットフィールド。複数の無線を持つWTPは、単一のMACアドレスを使用してこのフィールドを使用して、パケットに関連付けられている無線を示します。
The control message 'C' bit indicates whether this packet carries a data or control message. When this bit is zero (0), the packet carries an LWAPP data message in the payload (see Section 4.1). When this bit is one (1), the packet carries an LWAPP control message as defined in Section 4.2 for consumption by the addressed destination.
コントロールメッセージ「C」ビットは、このパケットがデータまたはコントロールメッセージを伝えるかどうかを示します。このビットがゼロ（0）の場合、パケットにはペイロードにLWAPPデータメッセージが含まれます（セクション4.1を参照）。このビットが1つの場合、パケットは、アドレス指定された宛先による消費のためにセクション4.2で定義されているLWAPP制御メッセージを伝えます。
The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC.
フラグメント「F」ビットは、このパケットがフラグメントであるかどうかを示します。このビットが1つの場合、パケットはフラグメントであり、他の対応するフラグメントと組み合わせて、WTPとACの間で交換される完全な情報を再組み立てする必要があります。
The Not Last 'L' bit is valid only if the 'F' bit is set and indicates whether the packet contains the last fragment of a fragmented exchange between the WTP and AC. When this bit is 1, the packet is not the last fragment. When this bit is 0, the packet is the last fragment.
「l」ビットではないビットは、「f」ビットが設定されている場合にのみ有効であり、パケットにWTPとACの間の断片化された交換の最後の断片が含まれているかどうかを示します。このビットが1の場合、パケットは最後のフラグメントではありません。このビットが0の場合、パケットは最後のフラグメントです。
An 8-bit field whose value is assigned to each group of fragments making up a complete set. The Fragment ID space is managed individually for every WTP/AC pair. The value of Fragment ID is incremented with each new set of fragments. The Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. LWAPP only supports up to 2 fragments per frame.
完全なセットを構成するフラグメントの各グループに値が割り当てられている8ビットフィールド。フラグメントIDスペースは、すべてのWTP/ACペアに対して個別に管理されています。フラグメントIDの値は、新しいフラグメントセットごとにインクリメントされます。フラグメントのセットを識別するために最大値を使用した後、フラグメントIDはゼロにラップします。LWAPPは、フレームごとに最大2つのフラグメントのみをサポートします。
The 16-bit length field contains the number of bytes in the Payload. The field is encoded as an unsigned number. If the LWAPP packet is encrypted, the length field includes the Advanced Encryption Standard Counter with CBC-MAC (AES-CCM) MIC (see Section 10.2 for more information).
16ビットの長さフィールドには、ペイロード内のバイト数が含まれています。フィールドは、署名されていない番号としてエンコードされています。LWAPPパケットが暗号化されている場合、長さフィールドには、CBC-MAC（AES-CCM）マイクを備えた高度な暗号化標準カウンターが含まれています（詳細については、セクション10.2を参照）。
The interpretation of this 16-bit field is binding-specific. Refer to the transport portion of the binding for a wireless technology for the specification.
この16ビットフィールドの解釈は、結合固有です。仕様のワイヤレステクノロジーのバインディングの輸送部分を参照してください。
This field contains the header for an LWAPP data message or LWAPP control message, followed by the data associated with that message.
このフィールドには、LWAPPデータメッセージまたはLWAPP制御メッセージのヘッダーが含まれており、その後にそのメッセージに関連付けられたデータが含まれます。
This section describes how the LWAPP protocol is provided over native Ethernet frames. An LWAPP packet is formed from the MAC frame header, followed by the LWAPP message header. The following figure provides an example of the frame formats used when LWAPP is used over the IEEE 802.3 transport.
このセクションでは、LWAPPプロトコルがネイティブイーサネットフレームでどのように提供されるかについて説明します。LWAPPパケットがMacフレームヘッダーから形成され、その後LWAPPメッセージヘッダーが続きます。次の図は、IEEE 802.3トランスポートでLWAPPが使用されているときに使用されるフレーム形式の例を示しています。
Layer 2 LWAPP Data Frame
+-----------------------------------------------------------+
| MAC Header | LWAPP Header [C=0] | Forwarded Data ... |
+-----------------------------------------------------------+
Layer 2 LWAPP Control Frame
+---------------------------------------------------+
| MAC Header | LWAPP Header [C=1] | Control Message |
+---------------------------------------------------+
| Message Elements ... |
+----------------------+
Source Address
ソースアドレス
A MAC address belonging to the interface from which this message is sent. If multiple source addresses are configured on an interface, then the one chosen is implementation-dependent.
このメッセージが送信されるインターフェイスに属するMACアドレス。複数のソースアドレスがインターフェイスで構成されている場合、選択されたものは実装依存です。
Destination Address
宛先アドレス
A MAC address belonging to the interface to which this message is to be sent. This destination address MAY be either an individual address or a multicast address, if more than one destination interface is intended.
このメッセージが送信されるインターフェイスに属するMACアドレス。この宛先アドレスは、複数の宛先インターフェイスが意図されている場合、個々のアドレスまたはマルチキャストアドレスのいずれかです。
Ethertype
EtherType
The Ethertype field is set to 0x88bb.
EtherTypeフィールドは0x88bbに設定されています。
When run over IEEE 802.3, LWAPP messages are distributed to a specific MAC-level broadcast domain. The AC discovery mechanism used with this transport is for a WTP to transmit a Discovery Request message to a broadcast destination MAC address. The ACs will receive this message and reply based on their policy.
IEEE 802.3を介して実行すると、LWAPPメッセージは特定のMACレベルのブロードキャストドメインに配布されます。このトランスポートで使用されるAC発見メカニズムは、WTPがブロードキャスト宛先MACアドレスにディスカバリーリクエストメッセージを送信するためのものです。ACSは、ポリシーに基づいてこのメッセージと返信を受け取ります。
All of the fields described in Section 3.1 are used when LWAPP uses the IEEE 802.3 MAC transport.
セクション3.1で説明されているすべてのフィールドは、LWAPPがIEEE 802.3 MACトランスポートを使用している場合に使用されます。
Fragmentation at the MAC layer is managed using the F, L, and Frag ID fields of the LWAPP message header. The LWAPP protocol only allows a single packet to be fragmented into 2, which is sufficient for a frame that exceeds MTU due to LWAPP encapsulation. When used with Layer 2 (Ethernet) transport, both fragments MUST include the LWAPP header.
MACレイヤーでのフラグメンテーションは、LWAPPメッセージヘッダーのF、L、およびフラグIDフィールドを使用して管理されます。LWAPPプロトコルでは、単一のパケットを2に断片化できます。これは、LWAPPカプセル化のためにMTUを超えるフレームに十分です。レイヤー2（イーサネット）輸送で使用する場合、両方のフラグメントにLWAPPヘッダーを含める必要があります。
LWAPP control messages and data messages are distinguished by the 'C' bit in the LWAPP message header.
LWAPP制御メッセージとデータメッセージは、LWAPPメッセージヘッダーの「C」ビットによって区別されます。
This section defines how LWAPP makes use of IP/UDP transport between the WTP and the AC. When this transport is used, the MAC layer is controlled by the IP stack, and there are therefore no special MAC-layer requirements. The following figure provides an example of the frame formats used when LWAPP is used over the IP/UDP transport. IP stacks can be either IPv4 or IPv6.
このセクションでは、LWAPPがWTPとAC間のIP/UDP輸送をどのように使用するかを定義します。このトランスポートを使用すると、MACレイヤーはIPスタックによって制御されるため、特別なMAC層要件はありません。次の図は、LWAPPがIP/UDPトランスポートで使用されているときに使用されるフレーム形式の例を示しています。IPスタックは、IPv4またはIPv6のいずれかです。
Layer 3 LWAPP Data Frame
+--------------------------------------------+
| MAC Header | IP | UDP | LWAPP Header [C=0] |
+--------------------------------------------+
|Forwarded Data ... |
+-------------------+
Layer 3 LWAPP Control Frame
+--------------------------------------------+
| MAC Header | IP | UDP | LWAPP Header [C=1] |
+--------------------------------------------+
| Control Message | Message Elements ... |
+-----------------+----------------------+
Communication between the WTP and AC is established according to the standard UDP client/server model. The connection is initiated by the WTP (client) to the well-known UDP port of the AC (server) used for control messages. This UDP port number of the AC is 12222 for LWAPP data and 12223 for LWAPP control frames.
WTPとAC間の通信は、標準のUDPクライアント/サーバーモデルに従って確立されます。接続は、WTP（クライアント）によって、コントロールメッセージに使用されるAC（サーバー）のよく知られているUDPポートに開始されます。ACのこのUDPポート番号は、LWAPPデータでは12222、LWAPPコントロールフレームでは12223です。
When LWAPP is run over routed IP networks, the WTP and the AC do not need to reside in the same IP subnet (broadcast domain). However, in the event the peers reside on separate subnets, there must exist a mechanism for the WTP to discover the AC.
LWAPPがルーティングされたIPネットワークを介して実行されると、WTPとACは同じIPサブネット（ブロードキャストドメイン）に居住する必要はありません。ただし、ピアが別々のサブネットに存在する場合、WTPがACを発見するメカニズムが存在する必要があります。
As the WTP attempts to establish communication with the AC, it sends the Discovery Request message and receives the corresponding response message from the AC. The WTP must send the Discovery Request message to either the limited broadcast IP address (255.255.255.255), a well known multicast address, or the unicast IP address of the AC. Upon receipt of the message, the AC issues a Discovery Response message to the unicast IP address of the WTP, regardless of whether a Discovery Request was sent as a broadcast, multicast, or unicast message.
WTPがACとの通信を確立しようとすると、Discovery Requestメッセージが送信され、ACから対応する応答メッセージが受信されます。WTPは、発見要求メッセージを、限られたブロードキャストIPアドレス（255.255.255.255）、よく知られているマルチキャストアドレス、またはACのユニキャストIPアドレスのいずれかに送信する必要があります。メッセージを受け取ると、ACは、ディスカバリーリクエストがブロードキャスト、マルチキャスト、またはユニキャストメッセージとして送信されたかどうかにかかわらず、WTPのユニキャストIPアドレスに対するディスカバリー応答メッセージを発行します。
Whether the WTP uses a limited IP broadcast, multicast or unicast IP address is implementation-dependent.
WTPが限られたIPブロードキャストを使用するかどうか、マルチキャストまたはユニキャストIPアドレスは実装依存です。
In order for a WTP to transmit a Discovery Request to a unicast address, the WTP must first obtain the IP address of the AC. Any static configuration of an AC's IP address on the WTP non-volatile storage is implementation-dependent. However, additional dynamic schemes are possible: for example:
WTPがユニキャストアドレスにディスカバリーリクエストを送信するためには、WTPは最初にACのIPアドレスを取得する必要があります。WTPの不揮発性ストレージ上のACのIPアドレスの静的構成は、実装依存です。ただし、追加の動的スキームが可能です。たとえば、：
DHCP: A comma-delimited, ASCII-encoded list of AC IP addresses is embedded inside a DHCP vendor-specific option 43 extension. An example of the actual format of the vendor-specific payload for IPv4 is of the form "10.1.1.1, 10.1.1.2".
DHCP：AC IPアドレスのComma DelimitedのASCIIエンコードされたリストは、DHCPベンダー固有のオプション43拡張機能に埋め込まれています。IPv4のベンダー固有のペイロードの実際の形式の例は、「10.1.1.1、10.1.1.2」という形式です。
DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to one or more AC addresses.
DNS：DNS名「lwapp-ac-address」は、1つ以上のACアドレスが解決できる場合があります。
All of the fields described in Section 3.1 are used when LWAPP uses the IPv4/UDP or IPv6/UDP transport, with the following exceptions.
セクション3.1で説明されているすべてのフィールドは、LWAPPがIPv4/UDPまたはIPv6/UDPトランスポートを使用している場合に使用されます。
This flag field is not used with this transport, and MUST be set to zero.
このフラグフィールドはこのトランスポートでは使用されておらず、ゼロに設定する必要があります。
This flag field is not used with this transport, and MUST be set to zero.
このフラグフィールドはこのトランスポートでは使用されておらず、ゼロに設定する必要があります。
This field is not used with this transport, and MUST be set to zero.
このフィールドはこのトランスポートでは使用されておらず、ゼロに設定する必要があります。
When LWAPP is implemented at L3, the transport layer uses IP fragmentation to fragment and reassemble LWAPP messages that are longer than the MTU size used by either the WTP or AC. The details of IP fragmentation are covered in [8]. When used with the IP transport, only the first fragment would include the LWAPP header.
LWAPPがL3で実装されると、輸送層はIPフラグメンテーションを使用して、WTPまたはACで使用されるMTUサイズよりも長いLWAPPメッセージを断片化および再組み立てします。IP断片化の詳細は[8]で説明されています。IPトランスポートで使用する場合、最初のフラグメントのみがLWAPPヘッダーを含みます。
IPv6 does MTU discovery so fragmentation and re-assembly is not necessary for UDP packets.
IPv6はMTU発見を行うため、UDPパケットには断片化と再組み立てが必要ありません。
LWAPP messages convey control information between WTP and AC, as well as binding specific data frames or binding specific management frames. As such, LWAPP messages need to be multiplexed in the transport sub-layer and be delivered to the proper software entities in the endpoints of the protocol. However, the 'C' bit is still used to differentiate between data and control frames.
LWAPPメッセージは、WTPとAC間の制御情報を伝え、特定のデータフレームをバインドするか、特定の管理フレームを拘束します。そのため、LWAPPメッセージはトランスポートサブレイヤーで多重化し、プロトコルのエンドポイントの適切なソフトウェアエンティティに配信する必要があります。ただし、「C」ビットは、データとコントロールフレームを区別するためにまだ使用されています。
In case of Layer 3 connection, multiplexing is achieved by use of different UDP ports for control and data packets (see Section 3.3.1).
レイヤー3接続の場合、制御およびデータパケットに異なるUDPポートを使用することにより、多重化が達成されます（セクション3.3.1を参照）。
As part of the Join procedure, the WTP and AC may negotiate different IP Addresses for data or control messages. The IP address returned in the AP Manager Control IP Address message element is used to inform the WTP with the IP address to which it must send all control frames. The AP Manager Data IP Address message element MAY be present only if the AC has a different IP address that the WTP is to use to send its data LWAPP frames.
結合手順の一部として、WTPとACは、データまたは制御メッセージの異なるIPアドレスをネゴシエートする場合があります。AP ManagerコントロールIPアドレスメッセージ要素で返されるIPアドレスは、すべてのコントロールフレームを送信する必要があるIPアドレスをWTPに通知するために使用されます。APマネージャーデータIPアドレスメッセージ要素は、ACにWTPがデータLWAPPフレームを送信するために使用する別のIPアドレスを持っている場合にのみ存在する場合があります。
In the event the WTP and AC are separated by a NAT, with the WTP using private IP address space, it is the responsibility of the NAT to manage appropriate UDP port mapping.
WTPとACがNATによって区切られており、WTPがプライベートIPアドレススペースを使用している場合、適切なUDPポートマッピングを管理することはNATの責任です。
This section contains the packet types and format. The LWAPP protocol is designed to be transport-agnostic by specifying packet formats for both MAC frames and IP packets. An LWAPP packet consists of an LWAPP Transport Layer packet header followed by an LWAPP message.
このセクションには、パケットの種類と形式が含まれています。LWAPPプロトコルは、MacフレームとIPパケットの両方にパケット形式を指定することにより、輸送に依存するように設計されています。LWAPPパケットは、LWAPPトランスポートレイヤーパケットヘッダーに続いてLWAPPメッセージが続きます。
Transport details can be found in Section 3.
輸送の詳細はセクション3にあります。
An LWAPP data message is a forwarded wireless frame. When forwarding wireless frames, the sender simply encapsulates the wireless frame in an LWAPP data packet, using the appropriate transport rules defined in Section 3.
LWAPPデータメッセージは、転送されたワイヤレスフレームです。ワイヤレスフレームを転送するとき、送信者は、セクション3で定義された適切なトランスポートルールを使用して、LWAPPデータパケットのワイヤレスフレームを単純にカプセル化します。
In the event that the encapsulated frame would exceed the transport layer's MTU, the sender is responsible for the fragmentation of the frame, as specified in the transport-specific section of Section 3.
カプセル化されたフレームが輸送層のMTUを超える場合、セクション3の輸送固有のセクションで指定されているように、送信者はフレームの断片化に責任を負います。
The actual format of the encapsulated LWAPP data frame is subject to the rules defined under the specific wireless technology binding.
カプセル化されたLWAPPデータフレームの実際の形式は、特定のワイヤレステクノロジーバインディングの下で定義されているルールの対象となります。
The LWAPP Control protocol provides a control channel between the WTP and the AC. The control channel is the series of control messages between the WTP and AC, associated with a session ID and key. Control messages are divided into the following distinct message types:
LWAPP制御プロトコルは、WTPとACの間の制御チャネルを提供します。制御チャネルは、WTPとACの間の一連のコントロールメッセージであり、セッションIDとキーに関連付けられています。コントロールメッセージは、次の異なるメッセージタイプに分割されます。
Discovery: LWAPP Discovery messages are used to identify potential ACs, their load and capabilities.
発見：LWAPPディスカバリーメッセージは、潜在的なACS、その負荷、機能を識別するために使用されます。
Control Channel Management: Messages that fall within this classification are used for the discovery of ACs by the WTPs as well as the establishment and maintenance of an LWAPP control channel.
コントロールチャネル管理：この分類内にあるメッセージは、WTPによるACSの発見とLWAPP制御チャネルの確立とメンテナンスに使用されます。
WTP Configuration: The WTP Configuration messages are used by the AC to push a specific configuration to the WTPs with which it has a control channel. Messages that deal with the retrieval of statistics from the WTP also fall in this category.
WTP構成：WTP構成メッセージは、ACによって使用され、特定の構成をコントロールチャネルを持つWTPSにプッシュします。WTPからの統計の検索を扱うメッセージもこのカテゴリに分類されます。
Mobile Session Management: Mobile Session Management messages are used by the AC to push specific mobile policies to the WTP.
モバイルセッション管理：モバイルセッション管理メッセージは、特定のモバイルポリシーをWTPにプッシュするためにACによって使用されます。
Firmware Management: Messages in this category are used by the AC to push a new firmware image down to the WTP.
ファームウェア管理：このカテゴリのメッセージは、ACが新しいファームウェアイメージをWTPに押し下げるために使用されます。
Control Channel, WTP Configuration, and Mobile Session Management MUST be implemented. Firmware Management MAY be implemented.
制御チャネル、WTP構成、およびモバイルセッション管理を実装する必要があります。ファームウェア管理が実装される場合があります。
In addition, technology-specific bindings may introduce new control channel commands that depart from the above list.
さらに、テクノロジー固有のバインディングは、上記のリストから逸脱する新しい制御チャネルコマンドを導入する場合があります。
All LWAPP control messages are sent encapsulated within the LWAPP header (see Section 3.1). Immediately following the header is the LWAPP control header, which has the following format:
すべてのLWAPPコントロールメッセージは、LWAPPヘッダー内でカプセル化されて送信されます（セクション3.1を参照）。ヘッダーの直後には、次の形式があるLWAPPコントロールヘッダーがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Seq Num | Msg Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type field identifies the function of the LWAPP control message. The valid values for a Message Type are the following:
メッセージタイプフィールドは、LWAPPコントロールメッセージの関数を識別します。メッセージタイプの有効な値は次のとおりです。
Description Value
Discovery Request 1
Discovery Response 2
Join Request 3
Join Response 4
Join ACK 5
Join Confirm 6
Unused 7-9
Configure Request 10
Configure Response 11
Configuration Update Request 12
Configuration Update Response 13
WTP Event Request 14
WTP Event Response 15
Change State Event Request 16
Change State Event Response 17
Unused 18-21
Echo Request 22
Echo Response 23
Image Data Request 24
Image Data Response 25
Reset Request 26
Reset Response 27
Unused 28-29
Key Update Request 30
Key Update Response 31
Primary Discovery Request 32
Primary Discovery Response 33
Data Transfer Request 34
Data Transfer Response 35
Clear Config Indication 36
WLAN Config Request 37
WLAN Config Response 38
Mobile Config Request 39
Mobile Config Response 40
The Sequence Number field is an identifier value to match request/ response packet exchanges. When an LWAPP packet with a request message type is received, the value of the Sequence Number field is copied into the corresponding response packet.
シーケンス番号フィールドは、リクエスト/応答パケット交換に一致する識別子値です。リクエストメッセージタイプを使用したLWAPPパケットが受信されると、シーケンス番号フィールドの値が対応する応答パケットにコピーされます。
When an LWAPP control frame is sent, its internal sequence number counter is monotonically incremented, ensuring that no two requests pending have the same sequence number. This field will wrap back to zero.
LWAPP制御フレームが送信されると、内部シーケンス番号カウンターが単調に増加し、保留中の2つのリクエストが同じシーケンス番号を持たないようにします。このフィールドはゼロに戻ります。
The length field indicates the number of bytes following the Session ID field. If the LWAPP packet is encrypted, the length field includes the AES-CCM MIC (see Section 10.2 for more information).
長さフィールドは、セッションIDフィールドに続くバイト数を示します。LWAPPパケットが暗号化されている場合、長さフィールドにはAES-CCMマイクが含まれます（詳細についてはセクション10.2を参照）。
The Session ID is a 32-bit unsigned integer that is used to identify the security context for encrypted exchanges between the WTP and the AC. Note that a Session ID is a random value that MUST be unique between a given AC and any of the WTPs with which it may be communicating.
セッションIDは、WTPとACの間の暗号化された交換のセキュリティコンテキストを識別するために使用される32ビットの非署名整数です。セッションIDは、特定のACとそれが通信している可能性のあるWTPの間で一意でなければならないランダム値であることに注意してください。
The message element(s) carry the information pertinent to each of the control message types. Every control message in this specification specifies which message elements are permitted.
メッセージ要素には、各コントロールメッセージタイプに関連する情報が含まれています。この仕様のすべてのコントロールメッセージは、許可されているメッセージ要素を指定します。
The message element is used to carry information pertinent to a control message. Every message element is identified by the Type field, whose numbering space is managed via IANA (see Section 16). The total length of the message elements is indicated in the Message Element Length field.
メッセージ要素は、コントロールメッセージに関連する情報を伝達するために使用されます。すべてのメッセージ要素は、番号のスペースがIANAを介して管理されているタイプフィールドによって識別されます（セクション16を参照）。メッセージ要素の総長さは、メッセージ要素の長さフィールドに示されています。
All of the message element definitions in this document use a diagram similar to the one below in order to depict their formats. Note that in order to simplify this specification, these diagrams do not include the header fields (Type and Length). However, in each message element description, the header's field values will be defined.
このドキュメントのメッセージ要素定義はすべて、形式を描写するために、以下の図と同様の図を使用します。この仕様を簡素化するために、これらの図にはヘッダーフィールド（タイプと長さ）が含まれていないことに注意してください。ただし、各メッセージ要素の説明では、ヘッダーのフィールド値が定義されます。
Note that additional message elements may be defined in separate IETF documents.
追加のメッセージ要素は、個別のIETFドキュメントで定義できることに注意してください。
The format of a message element uses the TLV format shown here:
メッセージ要素の形式は、ここに示すTLV形式を使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where Type (8 bits) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field.
タイプ（8ビット）が値フィールドに掲載された情報の文字を識別し、長さ（16ビット）は値フィールドのバイト数を示します。
This section includes message elements that are not bound to a specific control message.
このセクションには、特定のコントロールメッセージにバインドされていないメッセージ要素が含まれています。
The Vendor-Specific Payload is used to communicate vendor-specific information between the WTP and the AC. The value contains the following format:
ベンダー固有のペイロードは、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 104 for Vendor Specific
タイプ：ベンダー固有の104
Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI Network Management Private Enterprise Codes" [13].
ベンダー識別子：IANAが割り当てられた「SMIネットワーク管理プライベートエンタープライズコード」を含む32ビット値[13]。
Element ID: A 16-bit Element Identifier that is managed by the vendor.
要素ID：ベンダーが管理する16ビット要素識別子。
Value: The value associated with the vendor-specific element.
値：ベンダー固有の要素に関連する値。
It is recommended that LWAPP control messages be sent by both the AC and the WTP with an appropriate Quality-of-Service precedence value, ensuring that congestion in the network minimizes occurrences of LWAPP control channel disconnects. Therefore, a Quality-of-Service-enabled LWAPP device should use:
適切なサービス品質の優先順位値を使用して、LWAPP制御メッセージをACとWTPの両方から送信し、ネットワーク内の混雑がLWAPPコントロールチャネルの発生を最小限に抑えることを保証することをお勧めします。したがって、サービス品質対応のLWAPPデバイスを使用する必要があります。
802.1P: The precedence value of 7 SHOULD be used.
802.1p：7の優先順位値を使用する必要があります。
DSCP: The Differentiated Services Code Point (DSCP) tag value of 46 SHOULD be used.
DSCP：差別化されたサービスコードポイント（DSCP）タグ値46を使用する必要があります。
The Discovery messages are used by a WTP to determine which ACs are available to provide service, as well as the capabilities and load of the ACs.
ディスカバリーメッセージは、WTPによって使用されて、どのACSがサービスを提供するために利用可能であるか、およびACSの機能と負荷を決定します。
The Discovery Request is used by the WTP to automatically discover potential ACs available in the network. A WTP must transmit this command even if it has a statically configured AC, as it is a required step in the LWAPP state machine.
ディスカバリー要求は、WTPによって使用され、ネットワークで利用可能な潜在的なACを自動的に発見します。wtpは、lwappステートマシンで必要なステップであるため、静的に構成されたACがある場合でもこのコマンドを送信する必要があります。
Discovery Requests MUST be sent by a WTP in the Discover state after waiting for a random delay less of than MaxDiscoveryInterval, after a WTP first comes up or is (re)initialized. A WTP MUST send no more than a maximum of MaxDiscoveries discoveries, waiting for a random delay less than MaxDiscoveryInterval between each successive discovery.
WTPが最初に登場するか、（再）初期化された後、MaxDiscoveryintervalよりも少ないランダムな遅延を待っていた後、発見状態のWTPによって発見要求を送信する必要があります。WTPは、最大のMaxDiscoveriesの発見以下を送信する必要があり、連続する各発見の間にMaxdiscoveryintervalよりも少ないランダム遅延を待っています。
This is to prevent an explosion of WTP Discoveries. An example of this occurring would be when many WTPs are powered on at the same time.
これは、WTPの発見の爆発を防ぐためです。この発生の例は、多くのWTPが同時に電源を入れている場合です。
Discovery Requests MUST be sent by a WTP when no Echo Responses are received for NeighborDeadInterval and the WTP returns to the Idle state. Discovery Requests are sent after NeighborDeadInterval, they MUST be sent after waiting for a random delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum of MaxDiscoveries discoveries, waiting for a random delay less than MaxDiscoveryInterval between each successive discovery.
Echo ResponseがNeighbordeadIntervalに対して受信され、WTPがアイドル状態に戻る場合、ディスカバリーリクエストはWTPによって送信する必要があります。Discoveryリクエストは、NeighbordeadedIntervalの後に送信され、MaxDiscoveryintervalよりも少ないランダム遅延を待ってから送信する必要があります。WTPは、最大数のMaxDiscoveriesの発見を送信する場合があり、それぞれの発見の間でMaxDiscoveryintervalよりも少ないランダムな遅延を待っています。
If a Discovery Response is not received after sending the maximum number of Discovery Requests, the WTP enters the Sulking state and MUST wait for an interval equal to SilentInterval before sending further Discovery Requests.
発見リクエストの最大数を送信した後に発見応答が受信されない場合、WTPはスルーキング状態に入り、さらに発見リクエストを送信する前にSilentIntervalに等しい間隔を待つ必要があります。
The Discovery Request message may be sent as a unicast, broadcast, or multicast message.
ディスカバリーリクエストメッセージは、ユニキャスト、ブロードキャスト、またはマルチキャストメッセージとして送信される場合があります。
Upon receiving a Discovery Request, the AC will respond with a Discovery Response sent to the address in the source address of the received Discovery Request.
発見要求を受信すると、ACは、受信した発見要求のソースアドレスのアドレスに送信されたディスカバリー応答で応答します。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Discovery message element is used to configure a WTP to operate in a specific mode.
ディスカバリーメッセージ要素は、特定のモードで動作するようにWTPを構成するために使用されます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Discovery Type|
+-+-+-+-+-+-+-+-+
Type: 58 for Discovery Type
タイプ：発見タイプ用58
Length: 1
長さ：1
Discovery Type: An 8-bit value indicating how the AC was discovered. The following values are supported:
発見タイプ：ACがどのように発見されたかを示す8ビット値。次の値がサポートされています。
0 - Broadcast
0-放送
1 - Configured
1-構成
The WTP Descriptor message element is used by the WTP to communicate its current hardware/firmware configuration. The value contains the following fields.
WTP記述子メッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Boot Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 for WTP Descriptor
タイプ：WTP記述子の3
Length: 16
長さ：16
Hardware Version: A 32-bit integer representing the WTP's hardware version number.
ハードウェアバージョン：WTPのハードウェアバージョン番号を表す32ビット整数。
Software Version: A 32-bit integer representing the WTP's Firmware version number.
ソフトウェアバージョン：WTPのファームウェアバージョン番号を表す32ビット整数。
Boot Version: A 32-bit integer representing the WTP's boot loader's version number.
ブートバージョン：WTPのブートローダーのバージョン番号を表す32ビット整数。
Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the RID field) supported by the WTP.
最大ラジオ：WTPでサポートされているラジオの数（各無線がRIDフィールドを介して識別される）を表す8ビット値。
Radios in Use: An 8-bit value representing the number of radios present in the WTP.
使用中の無線：WTPに存在する無線の数を表す8ビット値。
Encryption Capabilities: This 16-bit field is used by the WTP to communicate its capabilities to the AC. Since most WTPs support link-layer encryption, the AC may make use of these services. There are binding-dependent encryption capabilites. A WTP that does not have any encryption capabilities would set this field to zero (0). Refer to the specific binding for the specification.
暗号化機能：この16ビットフィールドは、WTPによってその機能をACに通信するために使用されます。ほとんどのWTPSはリンク層暗号化をサポートするため、ACはこれらのサービスを利用する場合があります。結合依存性暗号化能力があります。暗号化機能を持たないWTPは、このフィールドをゼロ（0）に設定します。仕様の特定のバインディングを参照してください。
The WTP Radio Information message element is used to communicate the radio information in a specific slot. The Discovery Request MUST include one such message element per radio in the WTP. The Radio-Type field is used by the AC in order to determine which technology-specific binding is to be used with the WTP.
WTP無線情報メッセージ要素は、特定のスロットで無線情報を通信するために使用されます。ディスカバリーリクエストには、WTPにラジオごとにそのようなメッセージ要素の1つを含める必要があります。無線型フィールドは、WTPで使用する技術固有の結合を決定するためにACによって使用されます。
The value contains two fields, as shown:
値に示すように、値には2つのフィールドが含まれています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Radio Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4 for WTP Radio Information
タイプ：WTP無線情報の4
Length: 2
長さ：2
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
Radio Type: The type of radio present. The following values are supported:
無線タイプ：存在する無線の種類。次の値がサポートされています。
1 - 802.11bg: An 802.11bg radio.
1-802.11bg：802.11bgラジオ。
2 - 802.11a: An 802.11a radio.
2-802.11a：802.11aラジオ。
3 - 802.16: An 802.16 radio.
3-802.16：802.16ラジオ。
4 - Ultra Wideband: A UWB radio.
4-ウルトラワイドバンド：UWBラジオ。
7 - all: Used to specify all radios in the WTP.
7-すべて：WTP内のすべてのラジオを指定するために使用されます。
The Discovery Response is a mechanism by which an AC advertises its services to requesting WTPs.
発見応答は、ACがWTPSを要求するためにサービスを宣伝するメカニズムです。
Discovery Responses are sent by an AC after receiving a Discovery Request.
発見応答は、発見要求を受け取った後にACによって送信されます。
When a WTP receives a Discovery Response, it MUST wait for an interval not less than DiscoveryInterval for receipt of additional Discovery Responses. After the DiscoveryInterval elapses, the WTP enters the Joining state and will select one of the ACs that sent a Discovery Response and send a Join Request to that AC.
WTPが発見応答を受信した場合、追加のディスカバリー応答を受信するために、DiscoveryInterval以上の間隔を待つ必要があります。DiscoveryIntervalの経過後、WTPは結合状態に入り、Discovery Responseを送信したACSの1つを選択し、そのACに参加要求を送信します。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The AC Address message element is used to communicate the identity of the AC. The value contains two fields, as shown:
ACアドレスメッセージ要素は、ACのIDを通信するために使用されます。値に示すように、値には2つのフィールドが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for AC Address
タイプ：ACアドレスの2
Length: 7
長さ：7
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
MAC Address: The MAC address of the AC
MACアドレス：ACのMACアドレス
The AC Descriptor message element is used by the AC to communicate its current state. The value contains the following fields:
AC記述子メッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Hardware Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Ver | Software Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Ver | Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit | Radios | Max Radio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radio | Security |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 for AC Descriptor
タイプ：AC記述子の6
Length: 17
長さ：17
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
Hardware Version: A 32-bit integer representing the AC's hardware version number.
ハードウェアバージョン：ACのハードウェアバージョン番号を表す32ビット整数。
Software Version: A 32-bit integer representing the AC's Firmware version number.
ソフトウェアバージョン：ACのファームウェアバージョン番号を表す32ビット整数。
Stations: A 16-bit integer representing the number of mobile stations currently associated with the AC.
ステーション：ACに現在関連付けられているモバイルステーションの数を表す16ビット整数。
Limit: A 16-bit integer representing the maximum number of stations supported by the AC.
制限：ACがサポートするステーションの最大数を表す16ビット整数。
Radios: A 16-bit integer representing the number of WTPs currently attached to the AC.
ラジオ：ACに現在接続されているWTPの数を表す16ビット整数。
Max Radio: A 16-bit integer representing the maximum number of WTPs supported by the AC.
Max Radio：ACがサポートするWTPの最大数を表す16ビット整数。
Security: An 8-bit bitmask specifying the security schemes supported by the AC. The following values are supported (see Section 10):
セキュリティ：ACがサポートするセキュリティスキームを指定する8ビットビットマスク。次の値がサポートされています（セクション10を参照）：
1 - X.509 Certificate-Based
1 -X.509証明書ベース
2 - Pre-Shared Secret
2-事前に共有された秘密
The AC Name message element contains an ASCII representation of the AC's identity. The value is a variable-length byte string. The string is NOT zero terminated.
AC名メッセージ要素には、ACのIDのASCII表現が含まれています。値は、可変長バイト文字列です。文字列はゼロ終端ではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Type: 31 for AC Name
タイプ：AC名の31
Length: > 0 Name: A variable-length ASCII string containing the AC's name.
長さ：> 0名前：ACの名前を含む可変長ASCII文字列。
The WTP Manager Control IPv4 Address message element is sent by the AC to the WTP during the discovery process and is used by the AC to provide the interfaces available on the AC, and their current load. This message element is useful for the WTP to perform load balancing across multiple interfaces.
WTP Manager Control IPv4アドレスメッセージ要素は、発見プロセス中にACによってWTPに送信され、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 99 for WTP Manager Control IPv4 Address
タイプ：WTP ManagerコントロールIPv4アドレスの99
Length: 6
長さ：6
IP Address: The IP address of an interface.
IPアドレス：インターフェイスのIPアドレス。
WTP Count: The number of WTPs currently connected to the interface.
WTPカウント：現在インターフェイスに接続されているWTPの数。
The WTP Manager Control IPv6 Address message element is sent by the AC to the WTP during the discovery process and is used by the AC to provide the interfaces available on the AC, and their current load. This message element is useful for the WTP to perform load balancing across multiple interfaces.
WTPマネージャーコントロールIPv6アドレスメッセージ要素は、発見プロセス中にACによってWTPに送信され、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 137 for WTP Manager Control IPv6 Address
タイプ：WTP ManagerコントロールIPv6アドレスの137
Length: 6
長さ：6
IP Address: The IP address of an interface.
IPアドレス：インターフェイスのIPアドレス。
WTP Count: The number of WTPs currently connected to the interface.
WTPカウント：現在インターフェイスに接続されているWTPの数。
The Primary Discovery Request is sent by the WTP in order to determine whether its preferred (or primary) AC is available.
プライマリディスカバリーリクエストは、その優先（またはプライマリ）ACが利用可能かどうかを判断するために、WTPによって送信されます。
Primary Discovery Requests are sent by a WTP when it has a primary AC configured, and is connected to another AC. This generally occurs as a result of a failover, and is used by the WTP as a means to discover when its primary AC becomes available. As a consequence, this message is only sent by a WTP when it is in the Run state.
一次発見要求は、プライマリAC構成があり、別のACに接続されている場合にWTPによって送信されます。これは一般に、フェールオーバーの結果として発生し、WTPによって使用されているのは、プライマリACがいつ利用可能になるかを発見する手段として使用されます。結果として、このメッセージは、WTPが実行状態にある場合にのみ送信されます。
The frequency of the Primary Discovery Requests should be no more often than the sending of the Echo Request message.
主要な発見要求の頻度は、Echo要求メッセージの送信よりも頻繁にはないはずです。
Upon receiving a Discovery Request, the AC will respond with a Primary Discovery Response sent to the address in the source address of the received Primary Discovery Request.
発見要求を受信すると、ACは受信した主要な発見要求のソースアドレスのアドレスに送信されたプライマリディスカバリー応答で応答します。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Discovery Type message element is defined in Section 5.1.1.
ディスカバリータイプメッセージ要素は、セクション5.1.1で定義されています。
The WTP Descriptor message element is defined in Section 5.1.2.
WTP記述子メッセージ要素は、セクション5.1.2で定義されています。
A WTP Radio Information message element must be present for every radio in the WTP. This message element is defined in Section 5.1.3.
WTPのすべてのラジオにWTP無線情報メッセージ要素が存在する必要があります。このメッセージ要素は、セクション5.1.3で定義されています。
The Primary Discovery Response is a mechanism by which an AC advertises its availability and services to requesting WTPs that are configured to have the AC as its primary AC.
一次発見応答は、ACがACをプライマリACとして構成されているWTPを要求するために、ACがその可用性とサービスを宣伝するメカニズムです。
Primary Discovery Responses are sent by an AC after receiving a Primary Discovery Request.
一次発見応答は、主要な発見要求を受け取った後、ACによって送信されます。
When a WTP receives a Primary Discovery Response, it may opt to establish an LWAPP connection to its primary AC, based on the configuration of the WTP Fallback Status message element on the WTP.
WTPが一次発見応答を受信すると、WTPのWTPフォールバックステータスメッセージ要素の構成に基づいて、プライマリACへのLWAPP接続を確立することを選択できます。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Discovery Type message element is defined in Section 5.2.2.
ディスカバリータイプメッセージ要素は、セクション5.2.2で定義されています。
The AC Name message element is defined in Section 5.2.3.
AC名メッセージ要素は、セクション5.2.3で定義されています。
A WTP Radio Information message element MAY be present for every radio in the WTP that is reachable via IPv4. This message element is defined in Section 5.2.4.
IPv4を介して到達可能なWTPのすべての無線にWTP無線情報メッセージ要素が存在する場合があります。このメッセージ要素は、セクション5.2.4で定義されています。
A WTP Radio Information message element must be present for every radio in the WTP that is reachable via IPv6. This message element is defined in Section 5.2.5.
WTP無線情報メッセージ要素は、IPv6を介して到達可能なWTPのすべての無線に存在する必要があります。このメッセージ要素は、セクション5.2.5で定義されています。
The Control Channel Management messages are used by the WTP and AC to create and maintain a channel of communication on which various other commands may be transmitted, such as configuration, firmware update, etc.
制御チャネル管理メッセージは、WTPとACによって使用され、構成、ファームウェアの更新など、他のさまざまなコマンドが送信される可能性のある通信チャネルを作成および維持します。
The Join Request is used by a WTP to inform an AC that it wishes to provide services through it.
結合要求は、WTPによって使用され、ACを通じてサービスを提供したいことをACに通知します。
Join Requests are sent by a WTP in the Joining state after receiving one or more Discovery Responses. The Join Request is also used as an MTU discovery mechanism by the WTP. The WTP issues a Join Request with a Test message element, bringing the total size of the message to exceed MTU.
結合リクエストは、1つ以上の発見応答を受け取った後、参加状態のWTPによって送信されます。結合要求は、WTPによるMTU発見メカニズムとしても使用されます。WTPは、テストメッセージ要素を使用して参加要求を発行し、メッセージの合計サイズをMTUを超えるようにします。
If the transport used does not provide MTU path discovery, the initial Join Request is padded with the Test message element to 1596 bytes. If a Join Response is received, the WTP can forward frames without requiring any fragmentation. If no Join Response is received, it issues a second Join Request padded with the Test payload to a total of 1500 bytes. The WTP continues to cycle from large (1596) to small (1500) packets until a Join Response has been received, or until both packets' sizes have been retransmitted 3 times. If the Join Response is not received after the maximum number of retransmissions, the WTP MUST abandon the AC and restart the discovery phase.
使用されているトランスポートがMTUパスの発見を提供しない場合、最初の結合要求は、テストメッセージ要素が1596バイトにパッドで詰め込まれています。結合応答を受信した場合、WTPは断片化を必要とせずにフレームを転送できます。Join Responseが受信されない場合、テストペイロードを合計1500バイトにパディングした2番目の結合要求を発行します。WTPは、結合応答が受信されるまで、または両方のパケットのサイズが3回再送信されるまで、大きな（1596）から小（1500）パケットに循環し続けます。再送信の最大数の後に結合応答が受信されない場合、WTPはACを放棄し、発見フェーズを再起動する必要があります。
When an AC receives a Join Request, it will respond with a Join Response. If the certificate-based security mechanism is used, the AC validates the certificate found in the request. If valid, the AC generates a session key that will be used to secure the control frames it exchanges with the WTP. When the AC issues the Join Response, the AC creates a context for the session with the WTP.
ACが参加リクエストを受信すると、Join Responseで応答します。証明書ベースのセキュリティメカニズムが使用されている場合、ACはリクエストで見つかった証明書を検証します。有効な場合、ACは、WTPと交換するコントロールフレームを保護するために使用されるセッションキーを生成します。ACが結合応答を発行すると、ACはWTPとのセッションのコンテキストを作成します。
If the pre-shared session key security mechanism is used, the AC saves the WTP's nonce, found in the WNonce message element, and creates its own nonce, which it includes in the ANonce message element. Finally, the AC creates the PSK-MIC, which is computed using a key that is derived from the PSK.
事前に共有セッションのキーセキュリティメカニズムを使用すると、ACはWNONCEメッセージ要素に見られるWTPのNonCEを保存し、Anonceメッセージ要素に含まれる独自のNonCEを作成します。最後に、ACはPSK-MICを作成します。PSK-MICは、PSKから派生したキーを使用して計算されます。
A Join Request that includes both a WNonce and a Certificate message element MUST be considered invalid.
WNONCEと証明書メッセージ要素の両方を含む参加要求は、無効と見なされる必要があります。
Details on the key generation are found in Section 10.
キー生成の詳細はセクション10にあります。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The WTP Descriptor message element is defined in Section 5.1.2.
WTP記述子メッセージ要素は、セクション5.1.2で定義されています。
The AC Address message element is defined in Section 5.2.1.
ACアドレスメッセージ要素は、セクション5.2.1で定義されています。
The WTP Name message element value is a variable-length byte string. The string is NOT zero terminated.
WTP名メッセージ要素値は、可変長バイト文字列です。文字列はゼロ終端ではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Type: 5 for WTP Name
タイプ：WTP名の5
Length: > 0
長さ：> 0
Name: A non-zero-terminated string containing the WTP's name.
名前：WTPの名前を含む非ゼロ終了文字列。
The Location Data message element is a variable-length byte string containing user-defined location information (e.g., "Next to Fridge"). The string is NOT zero terminated.
ロケーションデータメッセージ要素は、ユーザー定義の位置情報を含む可変長バイト文字列です（例：「冷蔵庫の隣」）。文字列はゼロ終端ではありません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Location ...
+-+-+-+-+-+-+-+-+
Type: 35 for Location Data
タイプ：35ロケーションデータ
Length: > 0
長さ：> 0
Location: A non-zero-terminated string containing the WTP's location.
場所：WTPの場所を含む非ゼロ終了文字列。
A WTP Radio Information message element must be present for every radio in the WTP. This message element is defined in Section 5.1.3.
WTPのすべてのラジオにWTP無線情報メッセージ要素が存在する必要があります。このメッセージ要素は、セクション5.1.3で定義されています。
The Certificate message element value is a byte string containing a DER-encoded x.509v3 certificate. This message element is only included if the LWAPP security type used between the WTP and the AC makes use of certificates (see Section 10 for more information).
証明書メッセージ要素値は、derエンコードx.509v3証明書を含むバイト文字列です。このメッセージ要素は、WTPとACの間で使用されるLWAPPセキュリティタイプが証明書を使用している場合にのみ含まれています（詳細についてはセクション10を参照）。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Certificate...
+-+-+-+-+-+-+-+-+
Type: 44 for Certificate
タイプ：証明書の44
Length: > 0
長さ：> 0
Certificate: A non-zero-terminated string containing the device's certificate.
証明書：デバイスの証明書を含む非ゼロ終了文字列。
The Session ID message element value contains a randomly generated [4] unsigned 32-bit integer.
セッションIDメッセージ要素値には、ランダムに生成された[4]符号なしの32ビット整数が含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 45 for Session ID
タイプ：セッションIDの45
Length: 4
長さ：4
Session ID: 32-bit random session identifier.
セッションID：32ビットランダムセッション識別子。
The Test message element is used as padding to perform MTU discovery, and it MAY contain any value, of any length.
テストメッセージ要素は、MTU発見を実行するためのパディングとして使用され、任意の長さの任意の値を含む場合があります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding ...
+-+-+-+-+-+-+-+-+
Type: 18 for Test
タイプ：テスト用18
Length: > 0
長さ：> 0
Padding: A variable-length pad.
パディング：可変長パッド。
The XNonce is used by the WTP to communicate its random nonce during the join or rekey phase. See Section 10 for more information.
Xnonceは、JoinまたはRekeフェーズ中にランダムなNonCEを通信するためにWTPによって使用されます。詳細については、セクション10を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 111 for XNonce
タイプ：Xnonceの111
Length: 16
長さ：16
Nonce: 1 16-octet random nonce.
Nonce：1 16-OCTETランダムノンセ。
The Join Response is sent by the AC to indicate to a WTP whether it is capable and willing to provide service to it.
結合応答は、ACによって送信され、WTPが能力があり、サービスを提供することをいとわないかどうかを示します。
Join Responses are sent by the AC after receiving a Join Request. Once the Join Response has been sent, the Heartbeat timer is initiated for the session to EchoInterval. Expiration of the timer will result in deletion of the AC-WTP session. The timer is refreshed upon receipt of the Echo Request.
参加リクエストを受信した後、参加回答はACによって送信されます。結合応答が送信されると、セッションのためにハートビートタイマーが開始されます。タイマーの有効期限は、AC-WTPセッションが削除されます。エコーリクエストの受信時にタイマーは更新されます。
If the security method used is certificate-based, when a WTP receives a Join Response, it enters the Joined state and initiates either a Configure Request or Image Data to the AC to which it is now joined. Upon entering the Joined state, the WTP begins timing an interval equal to NeighborDeadInterval. Expiration of the timer will result in the transmission of the Echo Request.
使用されるセキュリティメソッドが証明書ベースである場合、WTPが参加応答を受信すると、結合状態に入り、現在結合されているACの構成要求または画像データを開始します。結合された状態に入ると、WTPは近隣のインターバルに等しい間隔のタイミングを開始します。タイマーの有効期限は、エコーリクエストの送信につながります。
If the security method used is pre-shared-secret-based, when a WTP receives a Join Response that includes a valid PSK-MIC message element, it responds with a Join ACK that also MUST include a locally computed PSK-MIC message element.
使用されたセキュリティ方法が、Pre-Shared-Secretベースである場合、WTPが有効なPSK-MICメッセージ要素を含む結合応答を受信する場合、ローカルに計算されたPSK-MICメッセージ要素を含める必要があるJoin ACKで応答します。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Result Code message element value is a 32-bit integer value, indicating the result of the request operation corresponding to the sequence number in the message. The Result Code is included in a successful Join Response.
結果コードメッセージ要素値は32ビット整数値であり、メッセージのシーケンス番号に対応するリクエスト操作の結果を示します。結果コードは、成功した結合応答に含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 for Result Code
タイプ：結果コードの場合
Length: 4
長さ：4
Result Code: The following values are defined:
結果コード：次の値が定義されています。
0 Success
0成功
1 Failure (AC List message element MUST be present)
1障害（ACリストメッセージ要素が存在する必要があります）
The Status message element is sent by the AC to the WTP in a non-successful Join Response message. This message element is used to indicate the reason for the failure and should only be accompanied with a Result Code message element that indicates a failure.
ステータスメッセージ要素は、ACからsunsucessulsの参加応答メッセージでWTPに送信されます。このメッセージ要素は、障害の理由を示すために使用され、障害を示す結果コードメッセージ要素のみを伴う必要があります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+
Type: 60 for Status
タイプ：ステータスの場合は60
Length: 1
長さ：1
Status: The Status field indicates the reason for an LWAPP failure.
The following values are supported:
1 - Reserved - do not use
2 - Resource Depletion
2-リソースの枯渇
3 - Unknown Source
3-不明なソース
4 - Incorrect Data
4-誤ったデータ
The Certificate message element is defined in Section 6.1.6. Note this message element is only included if the WTP and the AC make use of certificate-based security as defined in Section 10.
証明書メッセージ要素は、セクション6.1.6で定義されています。注意このメッセージ要素は、WTPとACがセクション10で定義されている証明書ベースのセキュリティを使用する場合にのみ含まれています。
The WTP Manager Data IPv4 Address message element is optionally sent by the AC to the WTP during the join phase. If present, the IP Address contained in this message element is the address the WTP is to use when sending any of its LWAPP data frames.
WTP Manager Data IPv4アドレスメッセージ要素は、オプションでACによって結合フェーズ中にWTPに送信されます。存在する場合、このメッセージ要素に含まれるIPアドレスは、LWAPPデータフレームのいずれかを送信するときにWTPが使用するアドレスです。
Note that this message element is only valid when LWAPP uses the IP/UDP Layer 3 transport.
このメッセージ要素は、LWAPPがIP/UDPレイヤー3トランスポートを使用する場合にのみ有効であることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 138 for WTP Manager Data IPv4 Address
タイプ：WTPマネージャーデータIPv4アドレスの138
Length: 4
長さ：4
IP Address: The IP address of an interface.
IPアドレス：インターフェイスのIPアドレス。
The WTP Manager Data IPv6 Address message element is optionally sent by the AC to the WTP during the join phase. If present, the IP Address contained in this message element is the address the WTP is to use when sending any of its LWAPP data frames.
WTP Manager Data IPv6アドレスメッセージ要素は、オプションでACによって結合フェーズ中にWTPに送信されます。存在する場合、このメッセージ要素に含まれるIPアドレスは、LWAPPデータフレームのいずれかを送信するときにWTPが使用するアドレスです。
Note that this message element is only valid when LWAPP uses the IP/UDP Layer 3 transport.
このメッセージ要素は、LWAPPがIP/UDPレイヤー3トランスポートを使用する場合にのみ有効であることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 139 for WTP Manager Data IPv6 Address
タイプ：WTPマネージャーデータIPv6アドレスの139
Length: 4
長さ：4
IP Address: The IP address of an interface.
IPアドレス：インターフェイスのIPアドレス。
The AC List message element is used to configure a WTP with the latest list of ACs in a cluster. This message element MUST be included if the Join Response returns a failure indicating that the AC cannot handle the WTP at this time, allowing the WTP to find an alternate AC to which to connect.
ACリストメッセージ要素は、クラスター内のACSの最新リストを使用してWTPを構成するために使用されます。このメッセージ要素は、ACが現時点でWTPを処理できないことを示す障害を返す場合は含める必要があり、WTPが接続する代替ACを見つけることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 59 for AC List
タイプ：ACリスト用59
Length: >= 4
AC IP Address: An array of 32-bit integers containing an AC's IPv4 Address.
AC IPアドレス：ACのIPv4アドレスを含む32ビット整数の配列。
The AC List message element is used to configure a WTP with the latest list of ACs in a cluster. This message element MUST be included if the Join Response returns a failure indicating that the AC cannot handle the WTP at this time, allowing the WTP to find an alternate AC to which to connect.
ACリストメッセージ要素は、クラスター内のACSの最新リストを使用してWTPを構成するために使用されます。このメッセージ要素は、ACが現時点でWTPを処理できないことを示す障害を返す場合は含める必要があり、WTPが接続する代替ACを見つけることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 141 for AC List
タイプ：ACリストの141
Length: >= 4
AC IP Address: An array of 32-bit integers containing an AC's IPv6 Address.
AC IPアドレス：ACのIPv6アドレスを含む32ビット整数の配列。
The ANonce message element is sent by an AC during the join or rekey phase. The contents of the ANonce are encrypted as described in Section 10 for more information.
ANONCEメッセージ要素は、JOINまたはREKEYフェーズ中にACによって送信されます。Anonceの内容は、詳細についてはセクション10で説明されているように暗号化されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 108 for ANonce
タイプ：Anonceの108
Length: 16
長さ：16
Nonce: An encrypted, 16-octet random nonce.
Nonce：暗号化された16オクテットのランダムNonce。
The PSK-MIC message element includes a message integrity check, whose purpose is to provide confirmation to the peer that the sender has the proper session key. This message element is only included if the security method used between the WTP and the AC is the pre-shared secret mechanism. See Section 10 for more information.
PSK-MICメッセージ要素には、送信者が適切なセッションキーを持っていることをピアに確認することを目的とするメッセージの整合性チェックが含まれています。このメッセージ要素は、WTPとACの間で使用されるセキュリティ方法が事前に共有された秘密メカニズムである場合にのみ含まれます。詳細については、セクション10を参照してください。
When present, the PSK-MIC message element MUST be the last message element in the message. The MIC is computed over the complete LWAPP packet, from the LWAPP control header as defined in Section 4.2.1 to the end of the packet (which MUST be this PSK-MIC message element). The MIC field in this message element and the Sequence Number field in the LWAPP control header MUST be set to zeroes prior to computing the MIC. The length field in the LWAPP control header must already include this message element prior to computing the MIC.
存在する場合、PSK-MICメッセージ要素はメッセージの最後のメッセージ要素でなければなりません。マイクは、セクション4.2.1で定義されているLWAPPコントロールヘッダーからパケットの最後まで定義されている（これはこのPSK-MICメッセージ要素である必要があります）。このメッセージ要素のMICフィールドとLWAPPコントロールヘッダーのシーケンス番号フィールドは、MICを計算する前にゼロに設定する必要があります。LWAPPコントロールヘッダーの長さフィールドには、MICを計算する前に、このメッセージ要素を既に含める必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | MIC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 109 for PSK-MIC
タイプ：PSK-MICの109
Length: > 1
長さ：> 1
SPI: The Security Parameter Index (SPI) field specifies the cryptographic algorithm used to create the message integrity check. The following values are supported:
SPI：セキュリティパラメーターインデックス（SPI）フィールドは、メッセージの整合性チェックの作成に使用される暗号化アルゴリズムを指定します。次の値がサポートされています。
0 - Unused
0-未使用
1 - HMAC-SHA-1 (RFC 2104 [15])
1 -HMAC-SHA-1（RFC 2104 [15]）
MIC: A 20-octet Message Integrity Check.
MIC：20オクテットメッセージの整合性チェック。
The Join ACK message is sent by the WTP upon receiving a Join Response, which has a valid PSK-MIC message element, as a means of providing key confirmation to the AC. The Join ACK is only used in the case where the WTP makes use of the pre-shared key LWAPP mode (see Section 10 for more information).
Join ACKメッセージは、ACに重要な確認を提供する手段として、有効なPSK-MICメッセージ要素を持つJoin Responseを受信するとWTPによって送信されます。Join ACKは、WTPが事前に共有キーLWAPPモードを使用する場合にのみ使用されます（詳細についてはセクション10を参照）。
Note that the AC should never receive this message unless the security method used between the WTP and the AC is pre-shared-secret-based.
WTPとACの間で使用されているセキュリティ方法が事前に共有された秘密ベースでない限り、ACはこのメッセージを受け取るべきではないことに注意してください。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Session ID message element is defined in Section 6.1.7.
セッションIDメッセージ要素は、セクション6.1.7で定義されています。
The WNonce message element is sent by a WTP during the join or rekey phase. The contents of the ANonce are encrypted as described in Section 10 for more information.
WNONCEメッセージ要素は、JoinまたはRekeフェーズ中にWTPによって送信されます。Anonceの内容は、詳細についてはセクション10で説明されているように暗号化されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 107 for WNonce
タイプ：Wnonceの107
Length: 16
長さ：16
Nonce: An encrypted, 16-octet random nonce.
Nonce：暗号化された16オクテットのランダムNonce。
The PSK-MIC message element is defined in Section 6.2.9.
PSK-MICメッセージ要素は、セクション6.2.9で定義されています。
The Join Confirm message is sent by the AC upon receiving a Join ACK, which has a valid PSK-MIC message element, as a means of providing key confirmation to the WTP. The Join Confirm is only used in the case where the WTP makes use of the pre-shared key LWAPP mode (see Section 10 for more information).
Joinの確認メッセージは、WTPに重要な確認を提供する手段として、有効なPSK-MICメッセージ要素を備えたJoin ACKを受信するとACから送信されます。結合確認書は、WTPが事前に共有キーLWAPPモードを使用する場合にのみ使用されます（詳細についてはセクション10を参照）。
If the security method used is pre-shared-key-based, when a WTP receives a Join Confirm, it enters the Joined state and initiates either a Configure Request or Image Data to the AC to which it is now joined. Upon entering the Joined state, the WTP begins timing an interval equal to NeighborDeadInterval. Expiration of the timer will result in the transmission of the Echo Request.
使用されたセキュリティ方法がプレシェアキーベースである場合、WTPがJoinの確認を受信すると、結合状態に入り、現在結合されているACに設定要求または画像データを開始します。結合された状態に入ると、WTPは近隣のインターバルに等しい間隔のタイミングを開始します。タイマーの有効期限は、エコーリクエストの送信につながります。
This message is never received, or sent, when the security type used between the WTP and the AC is certificated-based.
このメッセージは、WTPとACの間で使用されているセキュリティタイプが認証ベースになった場合、受信されたり、送信されたりしません。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Session ID message element is defined in Section 6.1.7.
セッションIDメッセージ要素は、セクション6.1.7で定義されています。
The PSK-MIC message element is defined in Section 6.2.9.
PSK-MICメッセージ要素は、セクション6.2.9で定義されています。
The Echo Request message is a keepalive mechanism for the LWAPP control message.
エコーリクエストメッセージは、LWAPPコントロールメッセージのキープライブメカニズムです。
Echo Requests are sent periodically by a WTP in the Run state (see Figure 2) to determine the state of the connection between the WTP and the AC. The Echo Request is sent by the WTP when the Heartbeat timer expires, and it MUST start its NeighborDeadInterval timer.
エコー要求は、実行状態のWTPによって定期的に送信され（図2を参照）、WTPとACの間の接続の状態を決定します。エコー要求は、ハートビートタイマーが期限切れになったときにWTPによって送信され、近隣のインテルタイマーを開始する必要があります。
The Echo Request carries no message elements.
エコー要求にはメッセージ要素が含まれていません。
When an AC receives an Echo Request, it responds with an Echo Response.
ACがエコーリクエストを受信すると、エコー応答で応答します。
The Echo Response acknowledges the Echo Request, and is only accepted while in the Run state (see Figure 2).
エコー応答はエコーリクエストを認め、実行状態でのみ受け入れられます（図2を参照）。
Echo Responses are sent by an AC after receiving an Echo Request. After transmitting the Echo Response, the AC should reset its Heartbeat timer to expire in the value configured for EchoInterval. If another Echo request is not received by the AC when the timer expires, the AC SHOULD consider the WTP to no longer be reachable.
エコー応答は、エコーリクエストを受信した後、ACによって送信されます。エコー応答を送信した後、ACはハートビートタイマーをリセットして、echoInterval用に構成された値で有効期限を切る必要があります。タイマーの有効期限が切れたときにACが別のエコー要求を受信しない場合、ACはWTPが到達できなくなると考える必要があります。
The Echo Response carries no message elements.
エコー応答にはメッセージ要素が含まれていません。
When a WTP receives an Echo Response it stops the NeighborDeadInterval timer, and starts the Heartbeat timer to EchoInterval.
WTPがエコー応答を受信すると、NeighbordeadeadIntervalタイマーを停止し、ハートビートタイマーをエコーインターバルに起動します。
If the NeighborDeadInterval timer expires prior to receiving an Echo Response, the WTP enters the Idle state.
Echo応答を受ける前にNeighbordeAdedIntervalタイマーが期限切れになった場合、WTPはアイドル状態に入ります。
The Key Update Request is used by the WTP to initiate the rekeying phase. This message is sent by a WTP when in the Run state and MUST include a new unique Session Identifier. This message MUST also include a unique nonce in the XNonce message element, which is used to protect against replay attacks (see Section 10).
キーアップデートリクエストは、WTPによって使用され、再キーイングフェーズを開始します。このメッセージは、実行状態にあるときにWTPによって送信され、新しい一意のセッション識別子を含める必要があります。このメッセージには、リプレイ攻撃から保護するために使用されるXnonceメッセージ要素に一意のNonCEを含める必要があります（セクション10を参照）。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Session ID message element is defined in Section 6.1.7.
セッションIDメッセージ要素は、セクション6.1.7で定義されています。
The XNonce message element is defined in Section 6.1.9.
Xnonceメッセージ要素は、セクション6.1.9で定義されています。
The Key Update Response is sent by the AC in response to the request message, and includes an encrypted ANonce, which is used to derive new session keys. This message MUST include a Session Identifier message element, whose value MUST be identical to the one found in the Key Update Request.
キーアップデート応答は、リクエストメッセージに応じてACによって送信され、新しいセッションキーの導出に使用される暗号化されたAnonceが含まれています。このメッセージには、セッション識別子メッセージ要素が含まれている必要があります。その値は、キーアップデートリクエストで見つかったものと同一でなければなりません。
The AC MUST include a PSK-MIC message element, which provides message integrity over the whole message.
ACには、メッセージ全体にメッセージの整合性を提供するPSK-MICメッセージ要素を含める必要があります。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Session ID message element is defined in Section 6.1.7.
セッションIDメッセージ要素は、セクション6.1.7で定義されています。
The ANonce message element is defined in Section 6.2.8.
Anonceメッセージ要素は、セクション6.2.8で定義されています。
The PSK-MIC message element is defined in Section 6.2.9.
PSK-MICメッセージ要素は、セクション6.2.9で定義されています。
The Key Update ACK is sent by the WTP and includes an encrypted version of the WTP's nonce, which is used in the key derivation process. The session keys derived are then used as new LWAPP control message encryption keys (see Section 10).
キーアップデートACKはWTPによって送信され、Key Derivationプロセスで使用されるWTPのNONCEの暗号化バージョンが含まれています。派生したセッションキーは、新しいLWAPPコントロールメッセージ暗号化キーとして使用されます（セクション10を参照）。
The WTP MUST include a PSK-MIC message element, which provides message integrity over the whole message.
WTPには、メッセージ全体にメッセージの整合性を提供するPSK-MICメッセージ要素を含める必要があります。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The WNonce message element is defined in Section 6.3.2.
WNONCEメッセージ要素は、セクション6.3.2で定義されています。
The PSK-MIC message element is defined in Section 6.2.9.
PSK-MICメッセージ要素は、セクション6.2.9で定義されています。
The Key Update Confirm closes the rekeying loop, and allows the WTP to recognize that the AC has received and processed the Key Update messages. At this point, the WTP updates its session key in its crypto engine, and the associated Initialization Vector, ensuring that all future LWAPP control frames are encrypted with the newly derived encryption key.
キーアップデートでは、再キーイングループが閉じられ、WTPがACがキーアップデートメッセージを受信および処理したことを認識できるようになります。この時点で、WTPはCryptoエンジンと関連する初期化ベクトルのセッションキーを更新し、すべての将来のLWAPPコントロールフレームが新しく派生した暗号化キーで暗号化されるようにします。
The WTP MUST include a PSK-MIC message element, which provides message integrity over the whole message.
WTPには、メッセージ全体にメッセージの整合性を提供するPSK-MICメッセージ要素を含める必要があります。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The PSK-MIC message element is defined in Section 6.2.9.
PSK-MICメッセージ要素は、セクション6.2.9で定義されています。
The Key Update Trigger is used by the AC to request that a Key Update Request be initiated by the WTP.
キーアップデートトリガーは、ACがWTPによってキーアップデートリクエストを開始することを要求するために使用されます。
Key Update Triggers are sent by an AC in the Run state to inform the WTP to initiate a Key Update Request message.
キーアップデートトリガーは、実行状態のACから送信され、WTPに通知してキーアップデートリクエストメッセージを開始します。
When a WTP receives a Key Update Trigger, it generates a Key Update Request.
WTPがキーアップデートトリガーを受信すると、キーアップデートリクエストが生成されます。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Session ID message element is defined in Section 6.1.7.
セッションIDメッセージ要素は、セクション6.1.7で定義されています。
The Wireless Termination Point Configuration messages are used to exchange configuration between the AC and the WTP.
ワイヤレス終端ポイント構成メッセージは、ACとWTPの間の構成を交換するために使用されます。
The LWAPP protocol provides flexibility in how WTP configuration is managed. To put it simply, a WTP has one of two options:
LWAPPプロトコルは、WTP構成の管理方法に柔軟性を提供します。簡単に言えば、WTPには2つのオプションのいずれかがあります。
1. The WTP retains no configuration and simply abides by the configuration provided by the AC.
1. WTPは構成を保持せず、ACが提供する構成を単純に順守します。
2. The WTP retains the configuration of parameters provided by the AC that are non-default values.
2. WTPは、非デフォルト値であるACによって提供されるパラメーターの構成を保持します。
If the WTP opts to save configuration locally, the LWAPP protocol state machine defines the "Configure" state, which is used during the initial binding WTP-AC phase, which allows for configuration exchange. During this period, the WTP sends its current configuration overrides to the AC via the Configure Request message. A configuration override is a parameter that is non-default. One example is that in the LWAPP protocol, the default antenna configuration is an internal-omni antenna. However, a WTP that either has no internal antennas, or has been explicitely configured by the AC to use external antennas would send its antenna configuration during the configure phase, allowing the AC to become aware of the WTP's current configuration.
WTPが構成をローカルに保存することを選択した場合、LWAPPプロトコル状態マシンは、構成交換を可能にする初期バインディングWTP-ACフェーズで使用される「構成」状態を定義します。この期間中、WTPは、Configure Requestメッセージを介して現在の構成オーバーライドをACに送信します。構成オーバーライドは、非デフォルトであるパラメーターです。1つの例は、LWAPPプロトコルでは、デフォルトのアンテナ構成が内部オムニアンテナであることです。ただし、内部アンテナがない、またはACによって明示的に構成されているWTPは、外部アンテナを使用するようにACによってANTENNA構成を送信し、ACがWTPの現在の構成を認識できるようにします。
Once the WTP has provided its configuration to the AC, the AC sends down its own configuration. This allows the WTP to inherit the configuration and policies on the AC.
WTPがACに構成を提供すると、ACは独自の構成を送信します。これにより、WTPはACの構成とポリシーを継承できます。
An LWAPP AC maintains a copy of each active WTP's configuration. There is no need for versioning or other means to identify configuration changes. If a WTP becomes inactive, the AC MAY delete the configuration associated with it. If a WTP were to fail, and connect to a new AC, it would provide its overridden configuration parameters, allowing the new AC to be aware of the WTP's configuration.
LWAPP ACは、各アクティブなWTPの構成のコピーを維持します。構成の変更を識別するバージョン化やその他の手段は必要ありません。WTPが非アクティブになった場合、ACはそれに関連付けられた構成を削除する場合があります。WTPが故障し、新しいACに接続すると、オーバーライドされた構成パラメーターが提供され、新しいACがWTPの構成を認識できるようになります。
As a consequence, this model allows for resiliency, whereby in light of an AC failure, another AC could provide service to the WTP. In this scenario, the new AC would be automatically updated on any possible WTP configuration changes -- eliminating the need for Inter-AC communication or the need for all ACs to be aware of the configuration of all WTPs in the network.
結果として、このモデルは回復力を可能にし、それによりAC障害に照らして、別のACがWTPにサービスを提供できる可能性があります。このシナリオでは、新しいACは、可能なWTP構成の変更について自動的に更新されます。これは、INTER-AC通信の必要性またはすべてのACSがネットワーク内のすべてのWTPの構成を認識する必要性を排除します。
Once the LWAPP protocol enters the Run state, the WTPs begin to provide service. However, it is quite common for administrators to require that configuration changes be made while the network is operational. Therefore, the Configuration Update Request is sent by the AC to the WTP in order to make these changes at run-time.
LWAPPプロトコルが実行状態に入ると、WTPSはサービスの提供を開始します。ただし、管理者は、ネットワークが動作している間に構成の変更を行うことを要求することが非常に一般的です。したがって、実行時にこれらの変更を行うために、構成更新リクエストがACによってWTPに送信されます。
The Configure Request message is sent by a WTP to send its current configuration to its AC.
Configure requestメッセージは、現在の構成をACに送信するためにWTPによって送信されます。
Configure Requests are sent by a WTP after receiving a Join Response, while in the Configure state.
Configure Requestsは、Configure Stateで参加応答を受信した後、WTPによって送信されます。
The Configure Request carries binding-specific message elements. Refer to the appropriate binding for the definition of this structure.
Configure要求には、バインディング固有のメッセージ要素が含まれます。この構造の定義については、適切なバインディングを参照してください。
When an AC receives a Configure Request, it will act upon the content of the packet and respond to the WTP with a Configure Response.
ACがConfigureリクエストを受信すると、パケットのコンテンツに作用し、Configure応答を使用してWTPに応答します。
The Configure Request includes multiple Administrative State message elements. There is one such message element for the WTP, and then one per radio in the WTP.
Configure要求には、複数の管理状態メッセージ要素が含まれます。WTPにはそのようなメッセージ要素が1つあり、次にWTPの無線ごとに1つあります。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Administrative Event message element is used to communicate the state of a particular radio. The value contains the following fields.
管理イベントメッセージ要素は、特定の無線の状態を通信するために使用されます。値には、次のフィールドが含まれています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 27 for Administrative State
タイプ：管理状態の場合は27
Length: 2
長さ：2
Radio ID: An 8-bit value representing the radio to configure. The Radio ID field may also include the value of 0xff, which is used to identify the WTP itself. Therefore, if an AC wishes to change the administrative state of a WTP, it would include 0xff in the Radio ID field.
ラジオID：構成するラジオを表す8ビット値。ラジオIDフィールドには、WTP自体を識別するために使用される0xffの値も含まれている場合があります。したがって、ACがWTPの管理状態を変更したい場合、無線IDフィールドに0xffが含まれます。
Admin State: An 8-bit value representing the administrative state of the radio. The following values are supported:
管理状態：無線の管理状態を表す8ビット値。次の値がサポートされています。
1 - Enabled
1-有効
2 - Disabled
2-無効
The AC Name message element is defined in Section 5.2.3.
AC名メッセージ要素は、セクション5.2.3で定義されています。
The AC Name with Index message element is sent by the AC to the WTP to configure preferred ACs. The number of instances where this message element would be present is equal to the number of ACs configured on the WTP.
インデックスメッセージ要素を備えたAC名は、ACによってWTPに送信され、優先ACSを構成します。このメッセージ要素が存在するインスタンスの数は、WTPで構成されたACSの数に等しくなります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 90 for AC Name with Index
タイプ：インデックス付きAC名の90
Length: 5
長さ：5
Index: The index of the preferred server (e.g., 1=primary, 2=secondary).
インデックス：優先サーバーのインデックス（例：1 =プライマリ、2 =セカンダリ）。
AC Name: A variable-length ASCII string containing the AC's name.
AC名：ACの名前を含む可変長ASCII文字列。
The WTP Board Data message element is sent by the WTP to the AC and contains information about the hardware present.
WTPボードデータメッセージ要素は、WTPによってACに送信され、存在するハードウェアに関する情報が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Card ID | Card Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Model |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Model |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Serial Number ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 50 for WTP Board Data
タイプ：WTPボードデータの50
Length: 26
長さ：26
Card ID: A hardware identifier.
カードID：ハードウェア識別子。
Card Revision: 4-byte Revision of the card.
カードの改訂：カードの4バイトリビジョン。
WTP Model: 8-byte WTP Model Number.
WTPモデル：8バイトWTPモデル番号。
WTP Serial Number: 24-byte WTP Serial Number.
WTPシリアル番号：24バイトWTPシリアル番号。
Reserved: A 4-byte reserved field that MUST be set to zero (0).
予約済み：ゼロ（0）に設定する必要がある4バイトの予約フィールド。
Ethernet MAC Address: MAC address of the WTP's Ethernet interface.
イーサネットMACアドレス：WTPのイーサネットインターフェイスのMACアドレス。
The Statistics Timer message element value is used by the AC to inform the WTP of the frequency that it expects to receive updated statistics.
Statistics Timerメッセージ要素値は、ACによって使用され、WTPに更新された統計を受信すると予想される頻度を通知します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 37 for Statistics Timer
タイプ：統計タイマーの場合は37
Length: 2
長さ：2
Statistics Timer: A 16-bit unsigned integer indicating the time, in seconds.
統計タイマー：数秒で時間を示す16ビットの署名のない整数。
The WTP Static IP Address Information message element is used by an AC to configure or clear a previously configured static IP address on a WTP.
WTP静的IPアドレス情報メッセージメッセージ要素は、ACによって使用され、WTPで以前に構成された静的IPアドレスを構成またはクリアするために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static |
+-+-+-+-+-+-+-+-+
Type: 82 for WTP Static IP Address Information
タイプ：WTP静的IPアドレス情報の82
Length: 13
長さ：13
IP Address: The IP address to assign to the WTP.
IPアドレス：WTPに割り当てるIPアドレス。
Netmask: The IP Netmask.
ネットマスク：IPネットマスク。
Gateway: The IP address of the gateway.
ゲートウェイ：ゲートウェイのIPアドレス。
Netmask: The IP Netmask.
ネットマスク：IPネットマスク。
Static: An 8-bit Boolean stating whether or not the WTP should use a static IP address. A value of zero disables the static IP address, while a value of one enables it.
静的：WTPが静的IPアドレスを使用するかどうかを示す8ビットのブール値。ゼロの値は静的IPアドレスを無効にし、1つの値はそれを有効にします。
The WTP Reboot Statistics message element is sent by the WTP to the AC to communicate information about reasons why reboots have occurred.
WTP再起動統計メッセージ要素は、WTPによってACに送信され、再起動が発生した理由に関する情報を伝えます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crash Count | LWAPP Initiated Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Failure Count | Failure Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 67 for WTP Reboot Statistics
タイプ：WTPの再起動統計の67
Length: 7
長さ：7
Crash Count: The number of reboots that have occurred due to a WTP crash.
クラッシュカウント：WTPクラッシュのために発生した再起動の数。
LWAPP Initiated Count: The number of reboots that have occurred at the request of some LWAPP message, such as a change in configuration that required a reboot or an explicit LWAPP reset request.
LWAPPはカウントを開始しました：再起動や明示的なLWAPPリセットリクエストを必要とする構成の変更など、いくつかのLWAPPメッセージのリクエストで発生した再起動の数。
Link Failure Count: The number of times that an LWAPP connection with an AC has failed.
リンク障害カウント：ACとのLWAPP接続が失敗した回数。
Failure Type: The last WTP failure. The following values are supported:
障害タイプ：最後のWTP障害。次の値がサポートされています。
0 - Link Failure
0-リンク障害
1 - LWAPP Initiated
1 -LWAPPが開始されました
2 - WTP Crash
2 -WTPクラッシュ
The Configure Response message is sent by an AC and provides an opportunity for the AC to override a WTP's requested configuration.
Configure ResponseメッセージはACによって送信され、ACがWTPの要求された構成をオーバーライドする機会を提供します。
Configure Responses are sent by an AC after receiving a Configure Request.
構成応答は、Configureリクエストを受信した後にACによって送信されます。
The Configure Response carries binding-specific message elements. Refer to the appropriate binding for the definition of this structure.
Configure応答には、バインディング固有のメッセージ要素が含まれます。この構造の定義については、適切なバインディングを参照してください。
When a WTP receives a Configure Response, it acts upon the content of the packet, as appropriate. If the Configure Response message includes a Change State Event message element that causes a change in the operational state of one of the Radios, the WTP will transmit a Change State Event to the AC as an acknowledgement of the change in state.
WTPがConfigure応答を受信すると、必要に応じてパケットのコンテンツに作用します。Configure Responseメッセージに、RADIOの1つの運用状態の変更を引き起こす変更状態イベントメッセージ要素が含まれている場合、WTPは状態の変更の認識として変更状態イベントをACに送信します。
The following subsections define the message elements that MUST be included in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に含める必要があるメッセージ要素を定義します。
The Decryption Error Report Period message element value is used by the AC to inform the WTP of how frequently it should send decryption error report messages.
復号化エラーレポート期間メッセージ要素値は、ACによって使用され、WTPが復号化エラーレポートメッセージを送信する頻度をWTPに通知します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 38 for Decryption Error Report Period
タイプ：復号化エラーレポート期間の場合は38
Length: 3
長さ：3
Radio ID: The Radio Identifier: typically refers to some interface index on the WTP.
無線ID：無線識別子：通常、WTPのインターフェイスインデックスを指します。
Report Interval: A 16-bit, unsigned integer indicating the time, in seconds.
レポート間隔：時間を数秒で示す16ビットの署名のない整数。
The WTP Radio Information message element is used to communicate the operational state of a radio. The value contains two fields, as shown.
WTP無線情報メッセージ要素は、無線の動作状態を通信するために使用されます。この値には、図のように2つのフィールドが含まれています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 26 for Change State Event
タイプ：変更状態イベントの26
Length: 3
長さ：3
Radio ID: The Radio Identifier: typically refers to some interface index on the WTP.
無線ID：無線識別子：通常、WTPのインターフェイスインデックスを指します。
State: An 8-bit Boolean value representing the state of the radio. A value of one disables the radio, while a value of two enables it.
状態：無線の状態を表す8ビットのブール値。1つの値は無線を無効にしますが、2つの値はそれを有効にします。
Cause: In the event of a radio being inoperable, the Cause field would contain the reason the radio is out of service. The following values are supported:
原因：無線が動作不能になった場合、原因フィールドにはラジオが使用されていない理由が含まれます。次の値がサポートされています。
0 - Normal
0-通常
1 - Radio Failure
1-無線障害
2 - Software Failure
2-ソフトウェアの障害
The LWAPP Timers message element is used by an AC to configure LWAPP timers on a WTP.
LWAPPタイマーメッセージ要素は、ACによって使用され、WTPでLWAPPタイマーを構成します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 68 for LWAPP Timers
タイプ：LWAPPタイマー用68
Length: 2
長さ：2
Discovery: The number of seconds between LWAPP Discovery packets when the WTP is in the discovery mode.
発見：WTPが発見モードにあるときのLWAPPディスカバリーパケット間の秒数。
Echo Request: The number of seconds between WTP Echo Request LWAPP messages.
エコーリクエスト：WTPエコーリクエストLWAPPメッセージの間の秒数。
The AC List message element is defined in Section 6.2.6.
ACリストメッセージ要素は、セクション6.2.6で定義されています。
The AC List message element is defined in Section 6.2.7.
ACリストメッセージ要素は、セクション6.2.7で定義されています。
The WTP Fallback message element is sent by the AC to the WTP to enable or disable automatic LWAPP fallback in the event that a WTP detects its preferred AC, and is not currently connected to it.
WTPフォールバックメッセージ要素は、ACによってWTPに送信され、WTPが優先ACを検出し、現在接続されていない場合に自動LWAPPフォールバックを有効または無効にします。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
Type: 91 for WTP Fallback
タイプ：WTPフォールバックの91
Length: 1
長さ：1
Mode: The 8-bit Boolean value indicates the status of automatic LWAPP fallback on the WTP. A value of zero disables the fallback feature, while a value of one enables it. When enabled, if the WTP detects that its primary AC is available, and it is not connected to it, it SHOULD automatically disconnect from its current AC and reconnect to its primary. If disabled, the WTP will only reconnect to its primary through manual intervention (e.g., through the Reset Request command).
モード：8ビットブール値は、WTPに対する自動LWAPPフォールバックのステータスを示します。ゼロの値はフォールバック機能を無効にしますが、1つの値はそれを有効にします。有効にすると、WTPがプライマリACが利用可能であることを検出し、それに接続されていない場合、現在のACから自動的に切断し、プライマリに再接続する必要があります。無効の場合、WTPは手動介入を通じてプライマリにのみ再接続します（例：リセットリクエストコマンドを介して）。
The Idle Timeout message element is sent by the AC to the WTP to provide it with the idle timeout that it should enforce on its active mobile station entries.
アイドルタイムアウトメッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 97 for Idle Timeout
タイプ：アイドルタイムアウト用97
Length: 4
長さ：4
Timeout: The current idle timeout to be enforced by the WTP.
タイムアウト：WTPによって実施される現在のアイドルタイムアウト。
Configure Update Requests are sent by the AC to provision the WTP while in the Run state. This is used to modify the configuration of the WTP while it is operational.
Configure Updateリクエストは、実行状態の間にWTPをプロビジョニングするためにACによって送信されます。これは、動作中にWTPの構成を変更するために使用されます。
When an AC receives a Configuration Update Request it will respond with a Configuration Update Response, with the appropriate Result Code.
ACが構成更新リクエストを受信すると、適切な結果コードを使用して、構成更新応答で応答します。
The following subsections define the message elements introduced by this LWAPP operation.
次のサブセクションでは、このLWAPP操作によって導入されたメッセージ要素を定義します。
The WTP Name message element is defined in Section 6.1.3.
WTP名メッセージ要素は、セクション6.1.3で定義されています。
The Change State Event message element is defined in Section 7.3.2.
変更状態イベントメッセージ要素は、セクション7.3.2で定義されています。
The Administrative State message element is defined in Section 7.2.1.
管理状態メッセージ要素は、セクション7.2.1で定義されています。
The Statistics Timer message element is defined in Section 7.2.5.
統計タイマーメッセージ要素は、セクション7.2.5で定義されています。
The Location Data message element is defined in Section 6.1.4.
位置データメッセージ要素は、セクション6.1.4で定義されています。
The Decryption Error Report Period message element is defined in Section 7.3.1.
復号化エラーレポート期間メッセージ要素は、セクション7.3.1で定義されています。
The AC List message element is defined in Section 6.2.6.
ACリストメッセージ要素は、セクション6.2.6で定義されています。
The AC List message element is defined in Section 6.2.7.
ACリストメッセージ要素は、セクション6.2.7で定義されています。
The Add Blacklist Entry message element is used by an AC to add a blacklist entry on a WTP, ensuring that the WTP no longer provides any service to the MAC addresses provided in the message. The MAC addresses provided in this message element are not expected to be saved in non-volative memory on the WTP.
ADD BlackListエントリメッセージ要素は、ACによってWTPにブラックリストエントリを追加するために使用され、WTPがメッセージに記載されているMacアドレスにサービスを提供しなくなるようにします。このメッセージ要素で提供されるMACアドレスは、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 65 for Add Blacklist Entry
タイプ：ブラックリストエントリを追加するには65
Length: >= 7
Num of Entries: The number of MAC addresses in the array.
エントリの数：配列内のMACアドレスの数。
MAC Address: An array of MAC addresses to add to the blacklist entry.
MACアドレス：ブラックリストエントリに追加するMACアドレスの配列。
The Delete Blacklist Entry message element is used by an AC to delete a previously added blacklist entry on a WTP, ensuring that the WTP provides service to the MAC addresses provided in the message.
削除BlackListエントリメッセージ要素は、ACによって使用されてWTPに以前に追加されたブラックリストエントリを削除し、WTPがメッセージに提供されているMACアドレスにサービスを提供するようにします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 66 for Delete Blacklist Entry
タイプ：66ブラックリストエントリを削除します
Length: >= 7
Num of Entries: The number of MAC addresses in the array.
エントリの数：配列内のMACアドレスの数。
MAC Address: An array of MAC addresses to delete from the blacklist entry.
Macアドレス：ブラックリストエントリから削除するためのMacアドレスの配列。
The Add Static Blacklist Entry message element is used by an AC to add a permanent Blacklist Entry on a WTP, ensuring that the WTP no longer provides any service to the MAC addresses provided in the message. The MAC addresses provided in this message element are expected to be saved in non-volative memory on the WTP.
ADD静的ブラックリストエントリメッセージ要素は、ACによって使用されてWTPに永続的なブラックリストエントリを追加し、WTPがメッセージに提供されているMACアドレスにサービスを提供しなくなるようにします。このメッセージ要素で提供されるMACアドレスは、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 70 for Delete Blacklist Entry
タイプ：70ブラックリストエントリを削除するには70
Length: >= 7
Num of Entries: The number of MAC addresses in the array.
エントリの数：配列内のMACアドレスの数。
MAC Address: An array of MAC addresses to add to the permanent blacklist entry.
MACアドレス：永続的なブラックリストエントリに追加するMACアドレスの配列。
The Delete Static Blacklist Entry message element is used by an AC to delete a previously added static blacklist entry on a WTP, ensuring that the WTP provides service to the MAC addresses provided in the message.
削除Static BlackListエントリメッセージ要素は、ACによって使用されてWTPに以前に追加された静的ブラックリストエントリを削除し、WTPがメッセージに記載されているMACアドレスにサービスを提供できるようにします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 71 for Delete Blacklist Entry
タイプ：71ブラックリストエントリの削除用
Length: >= 7
Num of Entries: The number of MAC addresses in the array.
エントリの数：配列内のMACアドレスの数。
MAC Address: An array of MAC addresses to delete from the static blacklist entry.
MACアドレス：静的ブラックリストエントリから削除するためのMacアドレスの配列。
The LWAPP Timers message element is defined in Section 7.3.3.
LWAPPタイマーメッセージ要素は、セクション7.3.3で定義されています。
The AC Name with Index message element is defined in Section 7.2.3.
インデックスメッセージ要素を持つAC名は、セクション7.2.3で定義されています。
The WTP Fallback message element is defined in Section 7.3.6.
WTPフォールバックメッセージ要素は、セクション7.3.6で定義されています。
The Idle Timeout message element is defined in Section 7.3.7.
アイドルタイムアウトメッセージ要素は、セクション7.3.7で定義されています。
The Configuration Update Response is the acknowledgement message for the Configuration Update Request.
Configuration Update Responseは、構成更新リクエストの確認メッセージです。
Configuration Update Responses are sent by a WTP after receiving a Configuration Update Request.
構成更新応答は、構成更新リクエストを受信した後、WTPによって送信されます。
When an AC receives a Configure Update Response, the result code indicates if the WTP successfully accepted the configuration.
ACがConfigure Update Responseを受信すると、結果コードはWTPが構成を正常に受け入れたかどうかを示します。
The following subsections define the message elements that must be present in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に存在する必要があるメッセージ要素を定義します。
The Result Code message element is defined in Section 6.2.1.
結果コードメッセージ要素は、セクション6.2.1で定義されています。
The Change State Event is used by the WTP to inform the AC of a change in the operational state.
Change Stateイベントは、WTPによって使用され、ACに運用状態の変更を通知します。
The Change State Event message is sent by the WTP when it receives a Configuration Response that includes a Change State Event message element. It is also sent in the event that the WTP detects an operational failure with a radio. The Change State Event may be sent in either the Configure or Run state (see Figure 2).
変更状態イベントメッセージは、WTPが変更状態イベントメッセージ要素を含む構成応答を受信したときに送信されます。また、WTPが無線で運用上の障害を検出した場合にも送信されます。変更状態イベントは、構成状態または実行状態のいずれかで送信できます（図2を参照）。
When an AC receives a Change State Event it will respond with a Change State Event Response and make any necessary modifications to internal WTP data structures.
ACが変更状態イベントを受信すると、変更状態イベント応答で応答し、内部WTPデータ構造に必要な変更を加えます。
The following subsections define the message elements that must be present in this LWAPP operation.
次のサブセクションでは、このLWAPP操作に存在する必要があるメッセージ要素を定義します。
The Change State Event message element is defined in Section 7.3.2.
変更状態イベントメッセージ要素は、セクション7.3.2で定義されています。
The Change State Event Response acknowledges the Change State Event.
変更状態イベントの対応は、変更状態イベントを認めています。
Change State Event Responses are sent by a WTP after receiving a Change State Event.
変更状態イベントの回答は、変更状態イベントを受け取った後、WTPによって送信されます。
The Change State Event Response carries no message elements. Its purpose is to acknowledge the receipt of the Change State Event.
変更状態イベントの応答には、メッセージ要素が含まれていません。その目的は、変更状態イベントの受領を認めることです。
The WTP does not need to perform any special processing of the Change State Event Response message.
WTPは、変更状態イベント応答メッセージの特別な処理を実行する必要はありません。
The Clear Config Indication is used to reset a WTP's configuration.
クリア設定表示は、WTPの構成をリセットするために使用されます。
The Clear Config Indication is sent by an AC to request that a WTP reset its configuration to manufacturing defaults. The Clear Config Indication message is sent while in the Run LWAPP state.
クリア設定表示は、ACによって送信され、WTPがその構成を製造デフォルトにリセットするように要求します。Clear Config Indisicationメッセージは、run lwapp状態で送信されます。
The Reset Request carries no message elements.
リセットリクエストにはメッセージ要素が含まれていません。
When a WTP receives a Clear Config Indication, it will reset its configuration to manufacturing defaults.
WTPが明確な構成表示を受信すると、構成を製造デフォルトにリセットします。
This section defines LWAPP operations responsible for debugging, gathering statistics, logging, and firmware management.
このセクションでは、デバッグ、統計の収集、ロギング、およびファームウェア管理を担当するLWAPP操作を定義します。
The Image Data Request is used to update firmware on the WTP. This message and its companion response are used by the AC to ensure that the image being run on each WTP is appropriate.
画像データ要求は、WTPのファームウェアを更新するために使用されます。このメッセージとそのコンパニオン応答は、各WTPで実行されている画像が適切であることを確認するためにACによって使用されます。
Image Data Requests are exchanged between the WTP and the AC to download a new program image to a WTP.
画像データ要求は、WTPとACの間で交換され、新しいプログラム画像をWTPにダウンロードします。
When a WTP or AC receives an Image Data Request, it will respond with an Image Data Response.
WTPまたはACが画像データ要求を受信すると、画像データ応答で応答します。
The format of the Image Data and Image Download message elements are described in the following subsections.
画像データと画像のダウンロードメッセージ要素の形式は、次のサブセクションで説明されています。
The Image Download message element is sent by the WTP to the AC and contains the image filename. The value is a variable-length byte string. The string is NOT zero terminated.
画像ダウンロードメッセージ要素は、WTPによってACに送信され、画像ファイル名が含まれています。値は、可変長バイト文字列です。文字列はゼロ終端ではありません。
The Image Data message element is present when sent by the AC and contains the following fields.
画像データメッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Checksum | Image Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Image Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 33 for Image Data
タイプ：33画像データの場合
Length: >= 5
Opcode: An 8-bit value representing the transfer opcode. The following values are supported:
OPCODE：転送オペコードを表す8ビット値。次の値がサポートされています。
3 - Image Data is included.
3-画像データが含まれています。
5 - An error occurred. Transfer is aborted.
5-エラーが発生しました。転送は中止されます。
Checksum: A 16-bit value containing a checksum of the Image Data that follows.
チェックサム：続く画像データのチェックサムを含む16ビット値。
Image Data: The Image Data field contains 1024 characters, unless the payload being sent is the last one (end of file).
画像データ：画像データフィールドには、ペイロードが送信されない限り、1024文字が含まれています（ファイルの終わり）。
The Image Data Response acknowledges the Image Data Request.
画像データ応答は、画像データ要求を確認します。
An Image Data Responses is sent in response to an Image Data Request. Its purpose is to acknowledge the receipt of the Image Data Request packet.
画像データ応答は、画像データ要求に応じて送信されます。その目的は、画像データリクエストパケットの受領を確認することです。
The Image Data Response carries no message elements.
画像データの応答には、メッセージ要素が含まれていません。
No action is necessary on receipt.
領収書にはアクションは必要ありません。
The Reset Request is used to cause a WTP to reboot.
リセットリクエストは、WTPを再起動させるために使用されます。
Reset Requests are sent by an AC to cause a WTP to reinitialize its operation.
リセットリクエストはACによって送信され、WTPが操作を再現します。
The Reset Request carries no message elements.
リセットリクエストにはメッセージ要素が含まれていません。
When a WTP receives a Reset Request it will respond with a Reset Response and then reinitialize itself.
WTPがリセットリクエストを受信すると、リセット応答で応答し、それ自体を再活性化します。
The Reset Response acknowledges the Reset Request.
リセット応答は、リセットリクエストを確認します。
Reset Responses are sent by a WTP after receiving a Reset Request.
リセット応答は、リセットリクエストを受信した後、WTPによって送信されます。
The Reset Response carries no message elements. Its purpose is to acknowledge the receipt of the Reset Request.
リセット応答にはメッセージ要素が含まれません。その目的は、リセットリクエストの受領を確認することです。
When an AC receives a Reset Response, it is notified that the WTP will now reinitialize its operation.
ACがリセット応答を受信すると、WTPが操作を再現することが通知されます。
The WTP Event Request is used by a WTP to send information to its AC. These types of events may be periodical, or some asynchronous event on the WTP. For instance, a WTP collects statistics and uses the WTP Event Request to transmit this information to the AC.
WTPイベントリクエストは、WTPによってそのACに情報を送信するために使用されます。これらのタイプのイベントは、定期的なものであるか、WTPでの非同期イベントです。たとえば、WTPは統計を収集し、WTPイベント要求を使用してこの情報をACに送信します。
When an AC receives a WTP Event Request, it will respond with a WTP Event Request.
ACがWTPイベントリクエストを受信すると、WTPイベントリクエストで応答します。
The WTP Event Request message MUST contain one of the following message element described in the next subsections, or a message element that is defined for a specific technology.
WTPイベントリクエストメッセージには、次のサブセクションで説明されている次のメッセージ要素のいずれか、または特定のテクノロジー用に定義されているメッセージ要素を含める必要があります。
The Decryption Error Report message element value is used by the WTP to inform the AC of decryption errors that have occurred since the last report.
復号化エラーレポートメッセージ要素値は、WTPによって使用され、ACに最後のレポート以降に発生した復号化エラーを通知します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID |Num Of Entries | Mobile MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 39 for Decryption Error Report
タイプ：復号化エラーレポートの場合は39
Length: >= 8
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
Num Of Entries: An 8-bit unsigned integer indicating the number of mobile MAC addresses.
エントリの数：モバイルMACアドレスの数を示す8ビットの署名のない整数。
Mobile MAC Address: An array of mobile station MAC addresses that have caused decryption errors.
モバイルMACアドレス：復号化エラーを引き起こしたモバイルステーションMACアドレスの配列。
The Duplicate IPv4 Address message element is used by a WTP to inform an AC that it has detected another host using the same IP address it is currently using.
重複したIPv4アドレスメッセージ要素は、WTPによって使用されて、現在使用している同じIPアドレスを使用して別のホストを検出したことを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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 77 for Duplicate IPv4 Address Length: 10
タイプ：77重複するIPv4アドレスの長さ：10
IP Address: The IP address currently used by the WTP.
IPアドレス：WTPで現在使用されているIPアドレス。
MAC Address: The MAC address of the offending device.
MACアドレス：問題のあるデバイスのMACアドレス。
The Duplicate IPv6 Address message element is used by a WTP to inform an AC that it has detected another host using the same IP address it is currently using.
重複したIPv6アドレスメッセージ要素は、WTPによって使用され、現在使用している同じIPアドレスを使用して別のホストを検出したことを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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 77 for Duplicate IPv6 Address
タイプ：77重複するIPv6アドレスの場合
Length: 10
長さ：10
IP Address: The IP address currently used by the WTP.
IPアドレス：WTPで現在使用されているIPアドレス。
MAC Address: The MAC address of the offending device.
MACアドレス：問題のあるデバイスのMACアドレス。
The WTP Event Response acknowledges the WTP Event Request.
WTPイベント応答は、WTPイベントリクエストを確認します。
WTP Event Responses are sent by an AC after receiving a WTP Event Request.
WTPイベントの応答は、WTPイベントリクエストを受信した後、ACによって送信されます。
The WTP Event Response carries no message elements.
WTPイベント応答には、メッセージ要素が含まれていません。
The Data Transfer Request is used to upload debug information from the WTP to the AC.
データ転送要求は、WTPからACにデバッグ情報をアップロードするために使用されます。
Data Transfer Requests are sent by the WTP to the AC when it determines that it has important information to send to the AC. For instance, if the WTP detects that its previous reboot was caused by a system crash, it would want to send the crash file to the AC. The remote debugger function in the WTP also uses the Data Transfer Request in order to send console output to the AC for debugging purposes.
データ転送要求は、ACに送信するための重要な情報があると判断した場合、WTPからACに送信されます。たとえば、WTPが以前の再起動がシステムのクラッシュによって引き起こされたことを検出した場合、クラッシュファイルをACに送信することをお勧めします。WTPのリモートデバッガー関数は、デバッグ目的でコンソール出力をACに送信するためにデータ転送要求も使用します。
When an AC receives a Data Transfer Request, it will respond with a Data Transfer Response. The AC may log the information received as it sees fit.
ACがデータ転送要求を受信すると、データ転送応答で応答します。ACは、適切であると見なされたときに受信した情報を記録する場合があります。
The Data Transfer Request message MUST contain ONE of the following message element described in the next subsection.
データ転送要求メッセージには、次のサブセクションで説明されている次のメッセージ要素のいずれかを含める必要があります。
The Data Transfer Mode message element is used by the AC to request information from the WTP for debugging purposes.
データ転送モードメッセージ要素は、ACがデバッグの目的でWTPから情報を要求するために使用されます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Data Type |
+-+-+-+-+-+-+-+-+
Type: 52 for Data Transfer Mode
タイプ：52データ転送モードの場合
Length: 1
長さ：1
Data Type: An 8-bit value describing the type of information being requested. The following values are supported:
データタイプ：要求される情報の種類を説明する8ビット値。次の値がサポートされています。
1 - WTP Crash Data
1 -WTPクラッシュデータ
2 - WTP Memory Dump
2 -WTPメモリダンプ
The Data Transfer Data message element is used by the WTP to provide information to the AC for debugging purposes.
データ転送データメッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Length | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 53 for Data Transfer Data
タイプ：データ転送データの場合は53
Length: >= 3
Data Type: An 8-bit value describing the type of information being sent. The following values are supported:
データタイプ：送信される情報の種類を説明する8ビット値。次の値がサポートされています。
1 - WTP Crash Data
1 -WTPクラッシュデータ
2 - WTP Memory Dump
2 -WTPメモリダンプ
Data Length: Length of data field.
データの長さ：データフィールドの長さ。
Data: Debug information.
データ：デバッグ情報。
The Data Transfer Response acknowledges the Data Transfer Request.
データ転送応答は、データ転送リクエストを確認します。
A Data Transfer Response is sent in response to a Data Transfer Request. Its purpose is to acknowledge the receipt of the Data Transfer Request packet.
データ転送リクエストに応じてデータ転送応答が送信されます。その目的は、データ転送要求パケットの受領を確認することです。
The Data Transfer Response carries no message elements.
データ転送応答には、メッセージ要素が含まれていません。
Upon receipt of a Data Transfer Response, the WTP transmits more information, if any is available.
データ転送応答を受け取ると、WTPは、利用可能な場合はより多くの情報を送信します。
Messages in this section are used by the AC to create, modify, or delete mobile station session state on the WTPs.
このセクションのメッセージは、ACがWTPSでモバイルステーションセッション状態を作成、変更、または削除するために使用されます。
The Mobile Config Request message is used to create, modify, or delete mobile session state on a WTP. The message is sent by the AC to the WTP, and may contain one or more message elements. The message elements for this LWAPP control message include information that is generally highly technology-specific. Therefore, please refer to the appropriate binding section or document for the definitions of the messages elements that may be used in this control message.
モバイル構成要求メッセージは、WTPでモバイルセッションの状態を作成、変更、または削除するために使用されます。メッセージはACからWTPに送信され、1つ以上のメッセージ要素が含まれる場合があります。このLWAPPコントロールメッセージのメッセージ要素には、一般的に技術固有の情報が含まれます。したがって、このコントロールメッセージで使用できるメッセージ要素の定義については、適切なバインディングセクションまたはドキュメントを参照してください。
This section defines the format of the Delete Mobile message element, since it does not contain any technology-specific information.
このセクションでは、テクノロジー固有の情報が含まれていないため、削除モバイルメッセージ要素の形式を定義します。
The Delete Mobile message element is used by the AC to inform a WTP that it should no longer provide service to a particular mobile station. The WTP must terminate service immediately upon receiving this message element.
削除モバイルメッセージ要素は、ACがWTPに特定のモバイルステーションにサービスを提供しなくなってはならないことを通知するために使用されます。WTPは、このメッセージ要素を受信するとすぐにサービスを終了する必要があります。
The transmission of a Delete Mobile message element could occur for various reasons, including administrative reasons, as a result of the fact that the mobile has roamed to another WTP, etc.
モバイルが別のWTPなどに歩き回っているという事実の結果として、管理上の理由を含むさまざまな理由で、削除モバイルメッセージ要素の送信が発生する可能性があります。
Once access has been terminated for a given station, any future packets received from the mobile must result in a deauthenticate message, as specified in [6].
特定のステーションのアクセスが終了すると、[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 30 for Delete Mobile
タイプ：モバイルを削除するには30
Length: 7
長さ：7
Radio ID: An 8-bit value representing the radio
ラジオID：ラジオを表す8ビット値
MAC Address: The mobile station's MAC address
MACアドレス：モバイルステーションのMACアドレス
The Mobile Configuration Response is used to acknowledge a previously received Mobile Configuration Request, and includes a Result Code message element that indicates whether an error occurred on the WTP.
モバイル構成応答は、以前に受信したモバイル構成要求を確認するために使用され、WTPでエラーが発生したかどうかを示す結果コードメッセージ要素が含まれています。
This message requires no special processing and is only used to acknowledge the Mobile Configuration Request.
このメッセージは特別な処理を必要とせず、モバイル構成要求を確認するためにのみ使用されます。
The Data Transfer Request message MUST contain the message elements described in the next subsection.
データ転送要求メッセージには、次のサブセクションで説明されているメッセージ要素が含まれている必要があります。
The Result Code message element is defined in Section 6.2.1.
結果コードメッセージ要素は、セクション6.2.1で定義されています。
Note: This version only defines a certificate and a shared-secret-based mechanism to secure control LWAPP traffic exchanged between the WTP and the AC.
注：このバージョンは、WTPとACの間で交換される制御LWAPPトラフィックを保護するための証明書と共有分泌ベースのメカニズムのみを定義します。
While it is generally straightforward to produce network installations in which the communications medium between the WTP and AC is not accessible to the casual user (e.g., these LAN segments are isolated, and no RJ45 or other access ports exist between the WTP and the AC), this will not always be the case. Furthermore, a determined attacker may resort to various, more sophisticated monitoring and/or access techniques, thereby compromising the integrity of this connection.
一般に、WTPとACの間の通信媒体がカジュアルユーザーがアクセスできないネットワークインストールを作成するのは簡単ですが（たとえば、これらのLANセグメントは分離されており、WTPとACの間にRJ45またはその他のアクセスポートは存在しません）、これは必ずしもそうではありません。さらに、決定された攻撃者は、さまざまな、より洗練された監視および/またはアクセス技術に頼ることができ、これによりこの接続の完全性が損なわれます。
In general, a certain level of threat on the local (wired) LAN is expected and accepted in most computing environments. That is, it is expected that in order to provide users with an acceptable level of service and maintain reasonable productivity levels, a certain amount of risk must be tolerated. It is generally believed that a certain perimeter is maintained around such LANs, that an attacker must have access to the building(s) in which such LANs exist, and that they must be able to "plug in" to the LAN in order to access the network.
一般に、ほとんどのコンピューティング環境では、ローカル（有線）LANの一定レベルの脅威が期待され、受け入れられています。つまり、ユーザーに許容レベルのサービスを提供し、合理的な生産性レベルを維持するためには、一定量のリスクを容認する必要があることが期待されています。一般に、そのようなLANの周りに特定の境界線が維持され、攻撃者がそのようなLANが存在する建物にアクセスしなければならず、アクセスするためにLANに「プラグイン」できる必要があると考えられています。ネットワーク。
With these things in mind, we can begin to assess the general security requirements for AC-WTP communications. While an in-depth security analysis of threats and risks to these communications is beyond the scope of this document, some discussion of the motivation for various security-related design choices is useful. The assumptions driving the security design thus far include the following:
これらのことを念頭に置いて、AC-WTP通信の一般的なセキュリティ要件の評価を開始できます。これらのコミュニケーションに対する脅威とリスクの詳細なセキュリティ分析は、このドキュメントの範囲を超えていますが、さまざまなセキュリティ関連の設計選択の動機についてのいくつかの議論は有用です。これまでのセキュリティ設計を推進する仮定には、以下が含まれます。
o WTP-AC communications take place over a wired connection that may be accessible to a sophisticated attacker.
o WTP-AC通信は、洗練された攻撃者がアクセスできる有線接続を介して行われます。
o access to this connection is not trivial for an outsider (i.e., someone who does not "belong" in the building) to access.
o この接続へのアクセスは、部外者（つまり、建物に「属していない」人）がアクセスするための些細なことではありません。
o if authentication and/or privacy of end-to-end traffic for which the WTP and AC are intermediaries is required, this may be provided via IPsec [14].
o WTPとACが仲介者であるエンドツーエンドトラフィックの認証および/またはプライバシーが必要な場合、これはIPSECを介して提供される場合があります[14]。
o privacy and authentication for at least some WTP-AC control traffic is required (e.g., Wired Equivalent Privacy (WEP) keys for user sessions, passed from the AC to the WTP).
o 少なくとも一部のWTP-AC制御トラフィックのプライバシーと認証が必要です（たとえば、ACからWTPに渡されたユーザーセッションの有線同等のプライバシー（WEP）キー）。
o the AC can be trusted to generate strong cryptographic keys.
o ACは、強力な暗号化キーを生成することを信頼できます。
The AC-WTP traffic can be considered to consist of two types: data traffic (e.g., to or from an end user), and control traffic, which is strictly between the AC and WTP. Since data traffic may be secured using IPsec (or some other end-to-end security mechanism), we confine our solution to control traffic. The resulting security consists of two components: an authenticated key exchange and control traffic security encapsulation. The security encapsulation is accomplished using AES-CCM, described in [3]. This encapsulation provides for strong AES-based authentication and encryption [2]. The exchange of cryptographic keys used for CCM is described below.
AC-WTPトラフィックは、データトラフィック（エンドユーザーとの間、またはエンドユーザーとの間）と、厳密にACとWTPの間にあるコントロールトラフィックの2つのタイプで構成されると考えることができます。IPSEC（または他のエンドツーエンドのセキュリティメカニズム）を使用してデータトラフィックは保護される場合があるため、トラフィックを制御するためのソリューションを限定します。結果のセキュリティは、認証されたキー交換と制御トラフィックセキュリティのカプセル化の2つのコンポーネントで構成されています。セキュリティカプセル化は、[3]で説明されているAES-CCMを使用して達成されます。このカプセル化は、強力なAESベースの認証と暗号化を提供します[2]。CCMに使用される暗号化キーの交換を以下に説明します。
While the LWAPP protocol uses AES-CCM to encrypt control traffic, it is important to note that not all control frames are encrypted. The LWAPP discovery and join phase are not encrypted. The Discovery messages are sent in the clear since there does not exist a security association between the WTP and the AC during the discovery phase. The join phase is an authenticated exchange used to negotiate symmetric session keys (see Section 10.3).
LWAPPプロトコルはAES-CCMを使用して制御トラフィックを暗号化しますが、すべてのコントロールフレームが暗号化されているわけではないことに注意することが重要です。LWAPPディスカバリーと結合フェーズは暗号化されていません。発見段階では、WTPとACの間にセキュリティ関連が存在しないため、ディスカバリーメッセージはクリアに送信されます。結合フェーズは、対称セッションキーの交渉に使用される認証された交換です（セクション10.3を参照）。
Once the join phase has been successfully completed, the LWAPP state machine Figure 2 will move to the Configure state, at which time all LWAPP control frames are encrypted using AES-CCM.
結合フェーズが正常に完了すると、LWAPPステートマシンの図2が構成状態に移動し、その時点ですべてのLWAPPコントロールフレームがAES-CCMを使用して暗号化されます。
Encryption of a control message begins at the Message Element field: meaning the Msg Type, Seq Num, Msg Element Length, and Session ID fields are left intact (see Section 4.2.1).
コントロールメッセージの暗号化は、メッセージ要素フィールドで始まります。これは、MSGタイプ、seq num、msg要素の長さ、およびセッションIDフィールドを意味します（セクション4.2.1を参照）。
The AES-CCM 12-byte authentication data is appended to the end of the message. The authentication data is calculated from the start of the LWAPP packet and includes the complete LWAPP control header (see Section 4.2.1).
AES-CCM 12バイト認証データは、メッセージの最後に追加されます。認証データは、LWAPPパケットの開始から計算され、完全なLWAPPコントロールヘッダーが含まれています（セクション4.2.1を参照）。
The AES-CCM block cipher protocol requires an initialization vector. The LWAPP protocol requires that the WTP and the AC maintain two separate IVs, one for transmission and one for reception. The IV derived during the key exchange phase by both the WTP and the AC is used as the base for all encrypted packets with a new key.
AES-CCMブロック暗号プロトコルには、初期化ベクトルが必要です。LWAPPプロトコルでは、WTPとACが2つの個別のIVを維持する必要があります。1つは送信用、もう1つは受信用です。WTPとACの両方によってキー交換フェーズ中に導出されたIVは、新しいキーを備えたすべての暗号化されたパケットのベースとして使用されます。
This section describes the key management component of the LWAPP protocol. There are two modes supported by LWAPP: certificate and pre-shared key.
このセクションでは、LWAPPプロトコルの主要な管理コンポーネントについて説明します。LWAPPでサポートされている2つのモードがあります。証明書と事前共有キーです。
This section details the key management protocol that makes use of pre-shared secrets.
このセクションでは、事前に共有された秘密を利用する主要な管理プロトコルについて詳しく説明します。
The following notations are used throughout this section:
次の表記は、このセクション全体で使用されます。
o PSK - the pre-shared key shared between the WTP and the AC.
o PSK- WTPとACの間で共有される事前共有キー。
o Kpriv - the private key of a public-private key pair.
o KPRIV-官民キーペアの秘密鍵。
o Kpub - the public key of the pair.
o KPUB-ペアの公開鍵。
o SessionID - a randomly generated LWAPP session identifier, provided by the WTP in the Join Request.
o SESSIONID -JOINリクエストでWTPによって提供されるランダムに生成されたLWAPPセッション識別子。
o E-x{Kpub, M} - RSA encryption of M using X's public key.
o e -x {kpub、m} - xの公開キーを使用したMのRSA暗号化。
o D-x{Kpriv, C} - RSA decryption of C using X's private key.
o d -x {kpriv、c} - xの秘密キーを使用したcのrsa復号化。
o AES-CMAC(key, packet) - A message integrity check, using AES-CMAC and key, of the complete LWAPP packet, with the Sequence Number field and the payload of the PSK-MIC message element set to zero.
o AES-CMAC（key、packet） - 完全なLWAPPパケットのAES-CMACおよびキーを使用したメッセージの整合性チェック、シーケンス番号フィールドとPSK-MICメッセージ要素のペイロードがゼロに設定されています。
o AES-E(key, plaintext) - Plaintext is encrypted with key, using AES.
o AES -E（Key、Plantext） - Plantextは、AEを使用してキーで暗号化されます。
o AES-D(key, ciphertext) - ciphertext is decrypted with key, using AES.
o AES -D（key、ciphertext） - ciphertextは、AEを使用してキーで復号化されます。
o Certificate-AC - AC's Certificate.
o certificate -ac -acの証明書。
o Certificate-WTP - WTP's Certificate.
o 証明書WTP -WTPの証明書。
o WTP-MAC - The WTP's MAC address.
o WTP -MAC -WTPのMacアドレス。
o AC-MAC - The AC's MAC address.
o AC -MAC -ACのMACアドレス。
o RK0 - the root key, which is created through a Key Derivation Function (KDF) function.
o RK0-キー派生関数（KDF）関数によって作成されるルートキー。
o RK0E - the root Encryption key, derived from RK0.
o RK0E- RK0から派生したルート暗号化キー。
o RK0M - the root MIC key, derived from RK0.
o RK0M -RK0から派生したルートマイクキー。
o SK1 - the session key.
o SK1-セッションキー。
o SK1C - the session confirmation key, derived from SK.
o SK1C -SKから派生したセッション確認キー。
o SK1E - the session encryption key, derived from SK.
o SK1E -SKから派生したセッション暗号化キー。
o SK1W - the session keywrap key, derived from SK (see RFC 3394 [9]).
o SK1W -SKから派生したセッションキーワラップキー（RFC 3394 [9]を参照）。
o WNonce - The WTP's randomly generated nonce.
o WNONCE -WTPのランダムに生成されたノンセ。
o ANonce - The AC's randomly generated nonce.
o ANONCE -ACのランダムに生成されたノンセ。
o EWNonce - The payload of the WNonce message element, which includes the WNonce.
o Ewnonce- WNONCEを含むWNONCEメッセージ要素のペイロード。
o EANonce - The payload of the ANonce message element, which includes the ANonce.
o Eanonce-アノンセを含むAnonceメッセージ要素のペイロード。
The AC and WTP accomplish mutual authentication and a cryptographic key exchange in a dual round trip using the Join Request, Join Response, Join ACK, and Join Confirm (see Section 6.1).
ACおよびWTPは、参加要求を使用してデュアルラウンドトリップで相互認証と暗号化キー交換を達成し、応答に参加し、ACKに参加して、確認確認書に参加します（セクション6.1を参照）。
The following text describes the exchange between the WTP and the AC that creates a session key, which is used to secure LWAPP control messages.
次のテキストは、LWAPPコントロールメッセージを保護するために使用されるセッションキーを作成するWTPとACの間の交換について説明しています。
o The WTP creates a Join Request using the following process:
o WTPは、次のプロセスを使用して参加要求を作成します。
o If certificate-based security is used, the WTP adds the Certificate message element (see Section 6.1.6) with its contents set to Certificate-WTP.
o 証明書ベースのセキュリティが使用されている場合、WTPは証明書メッセージ要素（セクション6.1.6を参照）を証明書WTPに設定して追加します。
o The WTP adds the Session ID message element (see Section 6.1.7) with the contents set to a randomly generated session identifier (see RFC 1750 [4]). The WTP MUST save the Session ID in order to validate the Join Response.
o WTPは、セッションIDメッセージ要素（セクション6.1.7を参照）をランダムに生成されたセッション識別子（RFC 1750 [4]を参照）に設定したコンテンツを追加します。wtpは、結合応答を検証するためにセッションIDを保存する必要があります。
o The WTP creates a random nonce, included in the XNonce message element (see Section 6.1.9). The WTP MUST save the XNonce to validate the Join Response.
o WTPは、Xnonceメッセージ要素に含まれるランダムなNonCEを作成します（セクション6.1.9を参照）。wtpは、xnonceを保存して、結合応答を検証する必要があります。
o The WTP transmits the Join Request to the AC.
o WTPは、結合要求をACに送信します。
o Upon receiving the Join Request, the AC uses the following process:
o 結合リクエストを受信すると、ACは次のプロセスを使用します。
o The AC creates the Join Response, and ensures that the Session ID message element matches the value found in the Join Request.
o ACはJoin Responseを作成し、セッションIDメッセージ要素がJoinリクエストで見つかった値と一致するようにします。
o If certificate-based security is used, the AC:
o 証明書ベースのセキュリティが使用される場合、AC：
o adds the Certificate-AC to the Certificate message element.
o 証明書-ACを証明書メッセージ要素に追加します。
o creates a random 'AC Nonce' and encrypts it using the following algorithm E-wtp(Kpub, XNonce XOR 'AC Nonce'). The encrypted contents are added to the ANonce's message element payload.
o ランダムな「AC nonce」を作成し、次のアルゴリズムe-WTP（kpub、xnonce xor 'ac nonce'）を使用して暗号化します。暗号化されたコンテンツは、Anonceのメッセージ要素ペイロードに追加されます。
o If a pre-shared-key-based security is used, the AC:
o 恥ずかしがり屋ベースのセキュリティが使用されている場合、AC：
o creates RK0 through the following algorithm: RK0 = KDF-256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || AC-MAC}, where WTP-MAC is the WTP's MAC address in the form "xx:xx:xx:xx:xx:xx". Similarly, the AC-MAC is an ASCII encoding of the AC's MAC address, of the form "xx:xx:xx:xx: xx:xx". The resulting K0 is split into the following:
o 次のアルゴリズムを介してRK0を作成します：RK0 = KDF-256 {PSK、 "LWAPPPSK TOP K0" ||セッションID ||wtp-mac ||AC-MAC}、WTP-MACは「xx：xx：xx：xx：xx：xx」という形式のWTPのMacアドレスです。同様に、AC-MACは、「xx：xx：xx：xx：xx：xx」という形式のACのMacアドレスのASCIIエンコードです。結果のK0は以下に分割されます。
o The first 16 octets are known as RK0E, and are used as an encryption key.
o 最初の16個のオクテットはRK0Eとして知られており、暗号化キーとして使用されます。
o The second 16 octets are known as RK0M, and are used for MIC'ing purposes.
o 2番目の16個のオクテットはRK0Mとして知られており、マイクの目的に使用されます。
o The AC creates a random 'AC Nonce' and encrypts it using the following algorithm: AES-E(RK0E, XNonce XOR 'AC Nonce'). The encrypted contents are added to the ANonce's message element payload.
o ACはランダムな「AC NonCe」を作成し、次のアルゴリズムを使用して暗号化します：AES-E（RK0E、XNONCE XOR 'AC NonCE'）。暗号化されたコンテンツは、Anonceのメッセージ要素ペイロードに追加されます。
o The AC adds a MIC to the contents of the Join Response using AES-CMAC(RK0M, Join Response) and adds the resulting hash to the PSK-MIC (Section 6.2.9) message element.
o ACは、AES-CMAC（RK0M、結合応答）を使用して結合応答の内容にマイクを追加し、結果のハッシュをPSK-MIC（セクション6.2.9）メッセージ要素に追加します。
o Upon receiving the Join Response, the WTP uses the following process: o If a pre-shared key is used, the WTP authenticates the Join Response's PSK-MIC message element. If authentication fails, the packet is dropped.
o 結合応答を受信すると、WTPは次のプロセスを使用します。O事前共有キーを使用する場合、WTPはJoin ResponseのPSK-Micメッセージ要素を認証します。認証が失敗した場合、パケットが削除されます。
o The WTP decrypts the ANonce message element and XOR's the value with XNonce to retrieve the 'AC Nonce'. The ANonce payload is referred to as ciphertext below:
o WTPは、ANONCEメッセージ要素を解読し、XORの値はXNONCEで「AC NonCe」を取得します。Anonceペイロードは、以下のciphertextと呼ばれます。
o If a pre-shared key is used, use AES-D(RK0E, ciphertext). The 'AC Nonce' is then recovered using XNonce XOR plaintext.
o 事前に共有キーを使用する場合は、AES-D（RK0E、暗号文）を使用します。「AC NonCe」は、Xnonce Xor Plantextを使用して回収されます。
o If certificates are used, use d-wtp(Kpriv, ciphertext). The 'AC Nonce' is then recovered using XNonce XOR plaintext.
o 証明書を使用する場合は、D-WTP（KPRIV、ciphertext）を使用します。「AC NonCe」は、Xnonce Xor Plantextを使用して回収されます。
o The WTP creates a random 'WTP Nonce'.
o WTPは、ランダムな「WTP nonce」を作成します。
o The WTP uses the KDF function to create a 64-octet session key (SK). The KDF function used is as follows: KDF-512{'WTP Nonce' || 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC-MAC}. The KDF function is defined in [7].
o WTPは、KDF関数を使用して、64オクテットセッションキー（SK）を作成します。使用されるKDF関数は次のとおりです。KDF-512 {'wtp nonce' ||「AC NonCe」、「LWAPP Key Generation」、WTP-MAC ||AC-MAC}。KDF関数は[7]で定義されています。
o SK is then broken down into three separate session keys with different purposes:
o その後、SKは異なる目的で3つの別々のセッションキーに分類されます。
o The first 16 octets are known as SK1C, and are used as a confirmation key.
o 最初の16個のオクテットはSK1Cとして知られており、確認キーとして使用されます。
o The second 16 octets are known as SK1E, and are as the encryption key.
o 2番目の16個のオクテットはSK1Eとして知られており、暗号化キーとなっています。
o The third 16 octets are known as SK1D, and are used as the keywrap key.
o 3番目の16個のオクテットはSK1Dとして知られており、キーワップキーとして使用されます。
o The fourth 16 octets are known as IV, and are used as the Initialization Vector during encryption.
o 4番目の16オクテットはIVとして知られており、暗号化中に初期化ベクトルとして使用されます。
o The WTP creates the Join ACK message.
o WTPはJoin ACKメッセージを作成します。
o If certificate-based security is used, the AC:
o 証明書ベースのセキュリティが使用される場合、AC：
o encrypts the 'WTP Nonce' using the following algorithm: E-ac(Kpub, 'WTP Nonce'). The encrypted contents are added to the WNonce's message element payload.
o 次のアルゴリズムを使用して「wtp nonce」を暗号化します：e-ac（kpub、 'wtp nonce'）。暗号化されたコンテンツは、wnonceのメッセージ要素ペイロードに追加されます。
o If a pre-shared-key-based security is used, the AC:
o 恥ずかしがり屋ベースのセキュリティが使用されている場合、AC：
o encrypts the 'WTP Nonce' using the following algorithm: AES-E(RK0E, 'WTP Nonce'). The encrypted contents are added to the WNonce's message element payload.
o 次のアルゴリズムを使用して「wtp nonce」を暗号化します：aes-e（rk0e、 'wtp nonce'）。暗号化されたコンテンツは、wnonceのメッセージ要素ペイロードに追加されます。
o The WTP adds a MIC to the contents of the Join ACK using AES-CMAC(SK1M, Join ACK) and adds the resulting hash to the PSK-MIC (Section 6.2.9) message element.
o WTPは、AES-CMAC（SK1M、JOIN ACK）を使用してJoin ACKの内容にマイクを追加し、結果のハッシュをPSK-MIC（セクション6.2.9）メッセージ要素に追加します。
o The WTP then transmits the Join ACK to the AC.
o WTPは、結合をACに送信します。
o Upon receiving the Join ACK, the AC uses the following process:
o Join ACKを受信すると、ACは次のプロセスを使用します。
o The AC authenticates the Join ACK through the PSK-MIC message element. If authentic, the AC decrypts the WNonce message element to retrieve the 'WTP Nonce'. If the Join ACK cannot be authenticated, the packet is dropped.
o ACは、PSK-MICメッセージ要素を介して結合ACKを認証します。本物の場合、ACはWNONCEメッセージ要素を復号化して「WTP nonce」を取得します。Join ACKを認証できない場合、パケットはドロップされます。
o The AC decrypts the WNonce message element to retrieve the 'WTP Nonce'. The WNonce payload is referred to as ciphertext below:
o ACは、wnonceメッセージ要素を復号化して「wtp nonce」を取得します。wnonceペイロードは、以下のciphertextと呼ばれます。
o If a pre-shared key is used, use AES-D(RK0E, ciphertext). The plaintext is then considered the 'WTP Nonce'.
o 事前に共有キーを使用する場合は、AES-D（RK0E、暗号文）を使用します。次に、プレーンテキストは「wtp nonce」と見なされます。
o If certificates are used, use d-ac(Kpriv, ciphertext). The plaintext is then considered the 'WTP Nonce'.
o 証明書を使用する場合は、D-AC（KPRIV、ciphertext）を使用します。次に、プレーンテキストは「wtp nonce」と見なされます。
o The AC then uses the KDF function to create a 64-octet session key (SK). The KDF function used is as follows: KDF-512{'WTP Nonce' || 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC-MAC}. The KDF function is defined in [7]. The SK is split into SK1C, SK1E, SK1D, and IV, as previously noted.
o 次に、ACはKDF関数を使用して、64オクテットセッションキー（SK）を作成します。使用されるKDF関数は次のとおりです。KDF-512 {'wtp nonce' ||「AC NonCe」、「LWAPP Key Generation」、WTP-MAC ||AC-MAC}。KDF関数は[7]で定義されています。前述のように、SKはSK1C、SK1E、SK1D、およびIVに分割されます。
o The AC creates the Join Confirm.
o ACはJoinの確認を作成します。
o The AC adds a MIC to the contents of the Join Confirm using AES-CMAC(SK1M, Join Confirm) and adds the resulting hash to the MIC (Section 6.2.9) message element.
o ACは、AES-CMAC（SK1M、結合確認）を使用して結合確認のコンテンツにマイクを追加し、結果のハッシュをMIC（セクション6.2.9）メッセージ要素に追加します。
o The AC then transmits the Join Confirm to the WTP.
o 次に、ACはJoinの確認をWTPに送信します。
o Upon receiving the Join Confirm, the WTP uses the following process:
o 結合確認を受信すると、WTPは次のプロセスを使用します。
o The WTP authenticates the Join Confirm through the PSK-MIC message element. If the Join Confirm cannot be authenticated, the packet is dropped.
o WTPは、PSK-MICメッセージ要素を介して結合確認を認証します。結合確認書を認証できない場合、パケットはドロップされます。
o SK1E is now plumbed into the AC and WTP's crypto engine as the AES-CCM LWAPP control encryption session key. Furthermore, the random IV is used as the base Initialization Vector. From this point on, all control protocol payloads between the WTP and AC are encrypted and authenticated using the new session key.
o SK1Eは、AES-CCM LWAPPコントロール暗号化セッションキーとしてACおよびWTPのCryptoエンジンに配管されています。さらに、ランダムIVはベース初期化ベクトルとして使用されます。この時点から、WTPとACの間のすべての制御プロトコルペイロードは暗号化され、新しいセッションキーを使用して認証されます。
Since AC-WTP associations will tend to be relatively long-lived, it is sensible to periodically refresh the encryption and authentication keys; this is referred to as "rekeying". When the key lifetime reaches 95% of the configured value, identified in the KeyLifetime timer (see Section 12), the rekeying will proceed as follows:
AC-WTPの関連付けは比較的長寿命になる傾向があるため、暗号化と認証キーを定期的に更新することが賢明です。これは「再キーイング」と呼ばれます。キーライフタイムがKeyLifetimeタイマーで識別される構成値の95％に達すると（セクション12を参照）、再キーイングは次のように進行します。
o The WTP creates RK0 through the previously defined KDF algorithm: RK0 = KDF-256{SK1D, "LWAPP PSK Top K0" || Session ID || WTP-MAC || AC-MAC}. Note that the difference in this specific instance is that SK1D that was previously generated is used instead of the PSK. Note this is used in both the certificate and pre-shared key modes. The resulting RK0 creates RK0E, RK0M.
o WTPは、以前に定義されたKDFアルゴリズムを介してRK0を作成します：rk0 = kdf-256 {sk1d、 "lwapp psk top k0" ||セッションID ||wtp-mac ||AC-MAC}。この特定のインスタンスの違いは、以前に生成されたSK1DがPSKの代わりに使用されることであることに注意してください。これは、証明書と事前に共有キーモードの両方で使用されています。結果のRK0はRK0E、RK0Mを作成します。
o The remaining steps used are identical to the join process, with the exception that the rekey messages are used instead of join messages, and the fact that the messages are encrypted using the previously created SK1E. This means the Join Request is replaced with the Rekey Request, the Join Response is replaced with the Rekey Response, etc. The two differences between the rekey and the join process are:
o 使用される残りの手順は、結合メッセージの代わりにRekeyメッセージが使用されていることを除いて、およびメッセージが以前に作成されたSK1Eを使用して暗号化されるという事実を除いて、参加プロセスと同じです。これは、結合要求がRekeyリクエストに置き換えられ、結合応答がRekey Responseなどに置き換えられることを意味します。
o The Certificate-WTP and Certificate-AC are not included in the Rekey-Request and Rekey-Response, respectively.
o 証明書WTPおよび証明書-ACは、それぞれReke-RequestとReke-Responseに含まれていません。
o Regardless of whether certificates or pre-shared keys were used in the initial key derivation, the process now uses the pre-shared key mode only, using SK1D as the "PSK".
o 最初のキー派生で証明書または事前に共有キーが使用されたかどうかに関係なく、このプロセスは、SK1Dを「PSK」として使用して、事前共有キーモードのみを使用するようになりました。
o The Key Update Request is sent to the AC.
o キーアップデートリクエストはACに送信されます。
o The newly created SK1E is now plumbed into the AC and WTP's crypto engine as the AES-CCM LWAPP control encryption session key. Furthermore, the new random IV is used as the base Initialization Vector. From this point on, all control protocol payloads between the WTP and AC are encrypted and authenticated using the new session key.
o 新しく作成されたSK1Eは、AES-CCM LWAPPコントロール暗号化セッションキーとしてACおよびWTPのCryptoエンジンに配管されています。さらに、新しいランダムIVは、ベース初期化ベクトルとして使用されます。この時点から、WTPとACの間のすべての制御プロトコルペイロードは暗号化され、新しいセッションキーを使用して認証されます。
If either the WTP or the AC do not receive an expected response by the time the ResponseTimeout timer expires (see Section 12), the WTP MUST delete the new and old session information, and reset the state machine to the Idle state.
WTPまたはACのいずれかが、応答タイムアウトタイマーが期限切れになるまでに予想される応答を受け取らない場合（セクション12を参照）、WTPは新しいおよび古いセッション情報を削除し、状態マシンをアイドル状態にリセットする必要があります。
Following a rekey process, both the WTP and the AC keep the previous encryption for 5-10 seconds in order to be able to process packets that arrive out of order.
Rekeyプロセスに続いて、WTPとACの両方が以前の暗号化を5〜10秒間保持して、順番に到着するパケットを処理できるようにします。
Validation of the certificates by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509v3 certificates MUST include the Extensions field [10] and MUST include the NetscapeComment [11] extension.
ACとWTPによる証明書の検証が必要であるため、ACのみがACの関数を実行し、WTPのみがWTPの関数を実行できるようにします。ACまたはWTPに対する関数のこの制限には、ACが使用する証明書がWTPが使用する証明書と区別できる必要があることが必要です。この差別化を達成するには、X.509V3証明書には拡張機能フィールド[10]を含める必要があり、netScapeComment [11]拡張機能を含める必要があります。
For an AC, the value of the NetscapeComment extension MUST be the string "CAPWAP AC Device Certificate". For a WTP, the value of the NetscapeComment extension MUST be the string "CAPWAP WTP Device Certificate".
ACの場合、NetScapeComment拡張の値は、文字列「CapWap ACデバイス証明書」でなければなりません。WTPの場合、NetScapeComment拡張の値は文字列「CapWap WTPデバイス証明書」でなければなりません。
Part of the LWAPP certificate validation process includes ensuring that the proper string is included in the NetscapeComment extension, and only allowing the LWAPP session to be established if the extension does not represent the same role as the device validating the certificate. For instance, a WTP MUST NOT accept a certificate whose NetscapeComment field is set to "CAPWAP WTP Device Certificate".
LWAPP証明書の検証プロセスの一部には、適切な文字列がNetScapeComment拡張機能に含まれるようにすることと、拡張機能が証明書を検証するデバイスと同じ役割を表していない場合にのみLWAPPセッションを確立できるようにすることが含まれます。たとえば、WTPは、NetScapeCommentフィールドが「CapWap WTPデバイス証明書」に設定されている証明書を受け入れてはなりません。
This section defines the extensions required for the LWAPP protocol to be used with the IEEE 802.11 protocol.
このセクションでは、LWAPPプロトコルがIEEE 802.11プロトコルで使用するために必要な拡張機能を定義します。
The LWAPP protocol, when used with IEEE 802.11 devices, requires a specific behavior from the WTP and the AC, specifically in terms of which 802.11 protocol functions are handled.
LWAPPプロトコルは、IEEE 802.11デバイスで使用される場合、特に802.11プロトコル関数が処理されるという点で、WTPとACからの特定の動作を必要とします。
For both the Split and Local MAC approaches, the CAPWAP functions, as defined in the taxonomy specification, reside in the AC.
分割とローカルのMACアプローチの両方について、CAPWAP関数は、分類仕様で定義されているように、ACに存在します。
This section shows the division of labor between the WTP and the AC in a Split MAC architecture. Figure 3 shows the clear separation of functionality among LWAPP components.
このセクションでは、Split MacアーキテクチャのWTPとACの間の分業を示しています。図3は、LWAPPコンポーネント間の機能の明確な分離を示しています。
Function Location
Distribution Service AC
Integration Service AC
Beacon Generation WTP
Probe Response WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc AC
802.11e
Classifying AC
Scheduling WTP/AC
Queuing WTP
802.11i
802.1X/EAP AC
Key Management AC
802.11 Encryption/Decryption WTP or AC
Figure 3: Mapping of 802.11 Functions for Split MAC Architecture
図3：分割Macアーキテクチャの802.11関数のマッピング
The Distribution and Integration services reside on the AC, and therefore all user data is tunneled between the WTP and the AC. As noted above, all real-time 802.11 services, including the control protocol and the beacon and Probe Response frames, are handled on the WTP.
分布および統合サービスはACに存在するため、すべてのユーザーデータがWTPとACの間にトンネルが付けられています。上記のように、制御プロトコルとビーコンおよびプローブ応答フレームを含むすべてのリアルタイム802.11サービスは、WTPで処理されます。
All remaining 802.11 MAC management frames are supported on the AC, including the Association Request, which allows the AC to be involved in the access policy enforcement portion of the 802.11 protocol. The 802.1X and 802.11i key management function are also located on the AC.
残りのすべての802.11 Mac管理フレームは、Acsociationリクエストを含むACでサポートされています。これにより、ACは802.11プロトコルのアクセスポリシー執行部分に関与します。802.1xおよび802.11iキー管理機能もACにあります。
While the admission control component of 802.11e resides on the AC, the real-time scheduling and queuing functions are on the WTP. Note that this does not exclude the AC from providing additional policing and scheduling functionality.
802.11Eの入場制御コンポーネントはACに存在しますが、リアルタイムスケジューリングとキューイング機能はWTPにあります。これは、ACが追加のポリシングおよびスケジューリング機能を提供することを除外しないことに注意してください。
Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP.
次の図では、「（ - ）」の使用は、フレームの処理がWTPで行われることを示していることに注意してください。
Client WTP AC
Beacon
<-----------------------------
Probe Request
----------------------------( - )------------------------->
Probe Response
<-----------------------------
802.11 AUTH/Association
<--------------------------------------------------------->
Add Mobile (Clear Text, 802.1X Only)
<------------------------->
802.1X Authentication & 802.11i Key Exchange
<--------------------------------------------------------->
Add Mobile (AES-CCMP, PTK=x)
<------------------------->
802.11 Action Frames
<--------------------------------------------------------->
802.11 DATA (1)
<---------------------------( - )------------------------->
Figure 4: Split MAC Message Flow
図4：MACメッセージフローを分割します
Figure 4 provides an illustration of the division of labor in a Split MAC architecture. In this example, a WLAN has been created that is configured for 802.11i, using AES-CCMP for privacy. The following process occurs:
図4は、分割Macアーキテクチャにおける分業の図を示しています。この例では、プライバシーにAES-CCMPを使用して、802.11i用に構成されたWLANが作成されています。次のプロセスが発生します。
o The WTP generates the 802.11 beacon frames, using information provided to it through the Add WLAN (see Section 11.8.1.1) message element.
o WTPは、ADD WLAN（セクション11.8.1.1を参照）メッセージ要素を介して提供される情報を使用して、802.11ビーコンフレームを生成します。
o The WTP processes the Probe Request and responds with a corresponding Probe Response. The problem request is then forwarded to the AC for optional processing.
o WTPはプローブ要求を処理し、対応するプローブ応答で応答します。問題要求は、オプションの処理のためにACに転送されます。
o The WTP forwards the 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client.
o WTPは、802.11認証および関連付けをACに転送します。これは、クライアントへの応答を担当します。
o Once the association is complete, the AC transmits an LWAPP Add Mobile Request to the WTP (see Section 11.7.1.1). In the above example, the WLAN is configured for 802.1X, and therefore the '802.1X only' policy bit is enabled.
o アソシエーションが完了すると、ACはLWAPP追加モバイル要求をWTPに送信します（セクション11.7.1.1を参照）。上記の例では、WLANは802.1xで構成されているため、「802.1xのみ」ポリシービットが有効になります。
o If the WTP is providing encryption/decryption services, once the client has completed the 802.11i key exchange, the AC transmits another Add Mobile Request to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP), as well as the encryption key to use. If encryption/decryption is handled in the AC, the Add Mobile Request would have the encryption policy set to "Clear Text".
o WTPが暗号化/復号化サービスを提供している場合、クライアントが802.11iキーエクスチェンジを完了すると、ACはWTPに別のモバイル要求を送信し、クライアント（この場合はAES-CCMP）を実施するためのセキュリティポリシーを述べています。使用する暗号化キーと同様に。暗号化/復号化がACで処理された場合、ADDモバイルリクエストには、暗号化ポリシーが「クリアテキスト」に設定されます。
o The WTP forwards any 802.11 Action frames received to the AC.
o WTPは、ACに受信した802.11アクションフレームをすべて転送します。
o All client data frames are tunneled between the WTP and the AC. Note that the WTP is responsible for encrypting and decrypting frames, if it was indicated in the Add Mobile Request.
o すべてのクライアントデータフレームは、WTPとACの間にトンネル化されます。ADDモバイル要求に示されている場合、WTPはフレームを暗号化および復号化する責任があることに注意してください。
This section shows the division of labor between the WTP and the AC in a Local MAC architecture. Figure 5 shows the clear separation of functionality among LWAPP components.
このセクションでは、ローカルMacアーキテクチャのWTPとACの間の分業を示しています。図5は、LWAPPコンポーネント間の機能の明確な分離を示しています。
Function Location
Distribution Service WTP
Integration Service WTP
Beacon Generation WTP
Probe Response WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc WTP
802.11e
Classifying WTP
Scheduling WTP
Queuing WTP
802.11i
802.1X/EAP AC
Key Management AC
802.11 Encryption/Decryption WTP
Figure 5: Mapping of 802.11 Functions for Local AP Architecture
図5：ローカルAPアーキテクチャの802.11関数のマッピング
Given that Distribution and Integration Services exist on the WTP, client data frames are not forwarded to the AC, with the exception listed in the following paragraphs.
WTPに分布と統合サービスが存在することを考えると、クライアントデータフレームはACに転送されませんが、例外は次の段落にリストされています。
While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response if it deems it necessary.
MacはWTPで終了しますが、ACがWTP内のモビリティイベントを認識する必要があります。結果として、WTPは802.11 AssociationリクエストをACに転送する必要があり、ACはそれが必要と思われる場合、失敗した関連応答で返信する場合があります。
The 802.1X and 802.11i Key Management function resides in the AC. Therefore, the WTP MUST forward all 802.1X/Key Management frames to the AC and forward the associated responses to the station.
802.1xおよび802.11iキー管理関数はACにあります。したがって、WTPはすべての802.1x/キー管理フレームをACに転送し、関連する応答をステーションに転送する必要があります。
Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP.
次の図では、「（ - ）」の使用は、フレームの処理がWTPで行われることを示していることに注意してください。
Client WTP AC
Beacon
<-----------------------------
Probe
<---------------------------->
802.11 AUTH
<-----------------------------
802.11 Association
<---------------------------( - )------------------------->
Add Mobile (Clear Text, 802.1X Only)
<------------------------->
802.1X Authentication & 802.11i Key Exchange
<--------------------------------------------------------->
802.11 Action Frames
<--------------------------------------------------------->
Add Mobile (AES-CCMP, PTK=x)
<------------------------->
802.11 DATA
<----------------------------->
Figure 6: Local MAC Message Flow
図6：ローカルMacメッセージフロー
Figure 6 provides an illustration of the division of labor in a Local MAC architecture. In this example, a WLAN has been created that is configured for 802.11i, using AES-CCMP for privacy. The following process occurs:
図6は、地元のMacアーキテクチャにおける分業の図を示しています。この例では、プライバシーにAES-CCMPを使用して、802.11i用に構成されたWLANが作成されています。次のプロセスが発生します。
o The WTP generates the 802.11 beacon frames, using information provided to it through the Add WLAN (see Section 11.8.1.1) message element.
o WTPは、ADD WLAN（セクション11.8.1.1を参照）メッセージ要素を介して提供される情報を使用して、802.11ビーコンフレームを生成します。
o The WTP processes the Probe Request and responds with a corresponding Probe Response.
o WTPはプローブ要求を処理し、対応するプローブ応答で応答します。
o The WTP forwards the 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client.
o WTPは、802.11認証および関連付けをACに転送します。これは、クライアントへの応答を担当します。
o Once the association is complete, the AC transmits an LWAPP Add Mobile Request to the WTP (see Section 11.7.1.1. In the above example, the WLAN is configured for 802.1X, and therefore the '802.1X only' policy bit is enabled.
o アソシエーションが完了すると、ACはLWAPPをWTPに追加するモバイルリクエストを送信します（セクション11.7.1.1.1を参照してください。上記の例では、WLANは802.1xで構成されているため、「802.1xのみ」ポリシービットが有効になります。
o The WTP forwards all 802.1X and 802.11i key exchange messages to the AC for processing.
o WTPは、すべての802.1xおよび802.11iのキー交換メッセージをACに転送します。
o The AC transmits another Add Mobile Request to the WTP, stating the security policy to enforce for the client (in this case, AES-CCMP), as well as the encryption key to use. The Add Mobile Request MAY include a VLAN name, which when present is used by the WTP to identify the VLAN on which the user's data frames are to be bridged.
o ACは、クライアント（この場合はAES-CCMP）と使用する暗号化キーを強制するためのセキュリティポリシーを記載して、WTPに別のモバイルリクエストを追加します。追加のモバイル要求には、VLAN名が含まれている場合があります。これは、WTPが存在する場合、ユーザーのデータフレームを橋渡しするVLANを識別するために使用されます。
o The WTP forwards any 802.11 Action frames received to the AC.
o WTPは、ACに受信した802.11アクションフレームをすべて転送します。
o The WTP locally bridges all client data frames, and provides the necessary encryption and decryption services.
o WTPはすべてのクライアントデータフレームを局所的に橋渡しし、必要な暗号化と復号化サービスを提供します。
It is important that LWAPP implementations react properly to mobile devices associating to the networks in how they generate Add Mobile and Delete Mobile messages. This section expands upon the examples provided in the previous section, and describes how the LWAPP control protocol is used in order to provide secure roaming.
LWAPPの実装は、モバイルメッセージを追加してモバイルメッセージを削除する方法を生成する方法で、ネットワークに関連するモバイルデバイスに適切に反応することが重要です。このセクションでは、前のセクションで提供された例を展開し、安全なローミングを提供するためにLWAPP制御プロトコルを使用する方法について説明します。
Once a client has successfully associated with the network in a secure fashion, it is likely to attempt to roam to another access point. Figure 7 shows an example of a currently associated station moving from its "Old WTP" to a new "WTP". The figure is useful for multiple different security policies, including standard 802.1X and dynamic WEP keys, WPA or even WPA2 both with key caching (where the 802.1x exchange would be bypassed) and without.
クライアントが安全な方法でネットワークに正常に関連付けられると、別のアクセスポイントにローミングしようとする可能性があります。図7は、「古いWTP」から新しい「WTP」に移動する現在関連するステーションの例を示しています。この図は、標準802.1xや動的WEPキー、WPA、またはWPA2を含む複数の異なるセキュリティポリシー（802.1x交換がバイパスされる）を含む複数の異なるセキュリティポリシーに役立ちます。
Client Old WTP WTP AC
Association Request/Response
<--------------------------------------( - )-------------->
Add Mobile (Clear Text, 802.1X Only)
<---------------->
802.1X Authentication (if no key cache entry exists)
<--------------------------------------( - )-------------->
802.11i 4-way Key Exchange
<--------------------------------------( - )-------------->
Delete Mobile
<---------------------------------->
Add Mobile (AES-CCMP, PTK=x)
<---------------->
Figure 7: Client Roaming Example
図7：クライアントローミングの例
All LWAPP transports have the following IEEE 802.11 specific bindings:
すべてのLWAPPトランスポートには、次のIEEE 802.11固有のバインディングがあります。
The interpretation of this 16-bit field depends on the direction of transmission of the packet. Refer to the figure in Section 3.1.
この16ビットフィールドの解釈は、パケットの送信方向に依存します。セクション3.1の図を参照してください。
Status
スターテス
When an LWAPP packet is transmitted from a WTP to an AC, this field is called the Status field and indicates radio resource information associated with the frame. When the message is an LWAPP control message this field is transmitted as zero.
LWAPPパケットがWTPからACに送信されると、このフィールドはステータスフィールドと呼ばれ、フレームに関連する無線リソース情報を示します。メッセージがLWAPPコントロールメッセージの場合、このフィールドはゼロとして送信されます。
The Status field is divided into the signal strength and signal-to-noise ratio with which an IEEE 802.11 frame was received, encoded in the following manner:
ステータスフィールドは、IEEE 802.11フレームを受信した信号強度と信号対雑音比に分割され、次の方法でエンコードされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSSI | SNR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm.
RSSI：RSSIは署名された8ビット値です。これは、DBMでの受信信号強度の表示です。
SNR: SNR is a signed, 8-bit value. It is the signal-to-noise ratio of the received IEEE 802.11 frame, in dB.
SNR：SNRは署名された8ビット値です。これは、DBでのIEEE 802.11フレームの信号対雑音比です。
WLANs field: When an LWAPP data message is transmitted from an AC to a WTP, this 16-bit field indicates on which WLANs the encapsulated IEEE 802.11 frame is to be transmitted. For unicast packets, this field is not used by the WTP. For broadcast or multicast packets, the WTP might require this information if it provides encryption services.
WLANSフィールド：LWAPPデータメッセージがACからWTPに送信されると、この16ビットフィールドは、カプセル化されたIEEE 802.11フレームが送信されるWLANを示します。ユニキャストパケットの場合、このフィールドはWTPで使用されません。ブロードキャストまたはマルチキャストパケットの場合、WTPは暗号化サービスを提供する場合、この情報が必要になる場合があります。
Given that a single broadcast or multicast packet might need to be sent to multiple wireless LANs (presumably each with a different broadcast key), this field is defined as a bit field. A bit set indicates a WLAN ID (see Section 11.8.1.1), which will be sent the data. The WLANS field is encoded in the following manner:
単一のブロードキャストまたはマルチキャストパケットを複数のワイヤレスLAN（おそらくそれぞれが異なるブロードキャストキーを持つ）に送信する必要がある場合があるため、このフィールドはビットフィールドとして定義されます。ビットセットは、データが送信されるWLAN ID（セクション11.8.1.1を参照）を示します。WLANSフィールドは、次の方法でエンコードされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WLAN ID(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LWAPP protocol makes assumptions regarding the BSSIDs used on the WTP. It is a requirement for the WTP to use a contiguous block of BSSIDs. The WLAN Identifier field, which is managed by the AC, is used as an offset into the BSSID list.
LWAPPプロトコルは、WTPで使用されるBSSIDに関して仮定を行っています。WTPがBSSIDの連続的なブロックを使用することは要件です。ACによって管理されるWLAN識別子フィールドは、BSSIDリストへのオフセットとして使用されます。
For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00, and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see Section 11.8.1.1), the BSSID for the specific WLAN on the WTP would be 00:01:02:00:00:02.
たとえば、WTPが00：01：02：00：00：00のベースBSSIDアドレスを持っていた場合、ACは2のWLAN識別子（セクション11.8.1.1を参照）を含むADD WLANメッセージを送信しました。WTPの特定のWLANは00：01：02：00：00：02です。
The WTP communicates the maximum number of BSSIDs that it supports during the Config Request within the IEEE 802.11 WTP WLAN Radio Configuration message element (see Section 11.9.1).
WTPは、IEEE 802.11 WTP WLAN無線構成メッセージ要素内の構成要求中にサポートするBSSIDの最大数を伝えます（セクション11.9.1を参照）。
It is recommended that 802.11 MAC management be sent by both the AC and the WTP with appropriate Quality-of-Service (QoS) values, ensuring that congestion in the network minimizes occurrences of packet loss. Therefore, a QoS-enabled LWAPP device should use:
802.11 Mac管理をACとWTPの両方から適切なサービス品質（QOS）値で送信し、ネットワーク内の輻輳がパケット損失の発生を最小限に抑えることを保証することをお勧めします。したがって、QOS対応LWAPPデバイスは以下を使用する必要があります。
802.1P: The precedence value of 6 SHOULD be used for all 802.11 MAC management messages, except for Probe Requests, which SHOULD use 4.
802.1p：6の優先順位値は、プローブ要求を除き、すべての802.11 Mac管理メッセージに使用する必要があります。
DSCP: The DSCP tag value of 46 SHOULD be used for all 802.11 MAC management messages, except for Probe Requests, which SHOULD use 34.
DSCP：46のDSCPタグ値は、プローブリクエストを除き、すべての802.11 Mac管理メッセージに使用する必要があります。
There are no LWAPP data message bindings for IEEE 802.11.
IEEE 802.11のLWAPPデータメッセージバインディングはありません。
The IEEE 802.11 binding has the following control message definitions.
IEEE 802.11バインディングには、次のコントロールメッセージ定義があります。
This section contains the 802.11-specific message elements that are used with the Mobile Config Request.
このセクションには、モバイル構成要求で使用される802.11固有のメッセージ要素が含まれています。
The Add Mobile Request is used by the AC to inform a WTP that it should forward traffic from a particular mobile station. The Add Mobile Request may also include security parameters that must be enforced by the WTP for the particular mobile.
ADDモバイル要求は、ACによって使用されて、特定のモバイルステーションからトラフィックを転送する必要があることをWTPに通知します。ADDモバイル要求には、特定のモバイルのWTPが実施する必要があるセキュリティパラメーターも含まれる場合があります。
When the AC sends an Add Mobile Request, it includes any security parameters that may be required. An AC that wishes to update a mobile's policy on a WTP may do so by simply sending a new Add Mobile message element.
ACがモバイルリクエストの追加を送信すると、必要になる可能性のあるセキュリティパラメーターが含まれます。WTPでモバイルのポリシーを更新したいACは、新しいADDモバイルメッセージ要素を単に送信するだけでそうすることができます。
When a WTP receives an Add Mobile message element, it must first override any existing state it may have for the mobile station in question. The latest Add Mobile overrides any previously received messages. If the Add Mobile message element's EAP-Only bit is set, the WTP MUST drop all 802.11 packets that do not contain EAP packets. Note that when EAP Only is set, the Encryption Policy field MAY have additional values, and therefore it is possible to inform a WTP to only accept encrypted EAP packets. Once the mobile station has successfully completed EAP authentication, the AC must send a new Add Mobile message element to push the session key down to the WTP as well as to remove the EAP Only restriction.
WTPがモバイルメッセージ要素の追加を受信した場合、最初に問題のモバイルステーションに対して既存の状態をオーバーライドする必要があります。最新のADDモバイルは、以前に受信したメッセージをオーバーライドします。モバイルメッセージ要素の追加ビットが設定されている場合、WTPはEAPパケットを含まないすべての802.11パケットをドロップする必要があります。EAPが設定されている場合、暗号化ポリシーフィールドには追加の値がある場合があるため、暗号化されたEAPパケットのみを受け入れるようにWTPに通知することが可能であることに注意してください。モバイルステーションがEAP認証を正常に完了したら、ACは新しいADDモバイルメッセージ要素を送信して、セッションキーをWTPに押し下げ、EAPのみの制限を削除する必要があります。
If the QoS field is set, the WTP MUST observe and provide policing of the 802.11e priority tag to ensure that it does not exceed the value provided by the AC.
QoSフィールドが設定されている場合、WTPは802.11E優先タグのポリシングを観察および提供して、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |E|C| Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encrypt Policy | Session Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise TSC... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise RSC... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities | WLAN ID | WME Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11e Mode | Qos | Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 29 for Add Mobile
タイプ：モバイルを追加するには29
Length: 36
長さ：36
Radio ID: An 8-bit value representing the radio.
ラジオID：ラジオを表す8ビット値。
Association ID: A 16-bit value specifying the 802.11 Association Identifier.
Association ID：802.11 Association Identifierを指定する16ビット値。
MAC Address: The mobile station's MAC address.
MACアドレス：モバイルステーションのMACアドレス。
E: The 1-bit field is set by the AC to inform the WTP that it MUST NOT accept any 802.11 data frames, other than 802.1X frames. This is the equivalent of the WTP's 802.1X port for the mobile station to be in the closed state. When set, the WTP MUST drop any non-802.1X packets it receives from the mobile station.
E：1ビットフィールドはACによって設定され、802.1xフレーム以外の802.11データフレームを受け入れてはならないことをWTPに通知します。これは、モバイルステーションが閉鎖状態にあるためのWTPの802.1xポートに相当します。設定すると、WTPはモバイルステーションから受信する非802.1xパケットをドロップする必要があります。
C: The 1-bit field is set by the AC to inform the WTP that encryption services will be provided by the AC. When set, the WTP SHOULD police frames received from stations to ensure that they comply to the stated encryption policy, but does not need to take specific cryptographic action on the frame. Similarly, for transmitted frames, the WTP only needs to forward already encrypted frames.
C：1ビットフィールドはACによって設定され、暗号化サービスがACによって提供されることをWTPに通知します。設定された場合、WTPはステーションから受け取った警察のフレームが、指定された暗号化ポリシーに準拠していることを確認する必要がありますが、フレームで特定の暗号化アクションをとる必要はありません。同様に、送信されたフレームの場合、WTPは既に暗号化されたフレームを転送する必要があります。
Encryption Policy: The policy field informs the WTP how to handle packets from/to the mobile station. The following values are supported:
暗号化ポリシー：ポリシーフィールドは、WTPにモバイルステーションからのパケットを処理する方法を通知します。次の値がサポートされています。
0 - Encrypt WEP 104: All packets to/from the mobile station must be encrypted using a standard 104-bit WEP.
0-暗号化されたWEP 104：モバイルステーションのすべてのパケットは、標準の104ビットWEPを使用して暗号化する必要があります。
1 - Clear Text: All packets to/from the mobile station do not require any additional crypto processing by the WTP.
1-テキストをクリア：モバイルステーションへの賛成でのすべてのパケットでは、WTPによる追加の暗号処理は必要ありません。
2 - Encrypt WEP 40: All packets to/from the mobile station must be encrypted using a standard 40-bit WEP.
2-暗号化されたWEP 40：モバイルステーションのすべてのパケットは、標準の40ビットWEPを使用して暗号化する必要があります。
3 - Encrypt WEP 128: All packets to/from the mobile station must be encrypted using a standard 128-bit WEP.
3-暗号化されたWEP 128：モバイルステーションのすべてのパケットは、標準の128ビットWEPを使用して暗号化する必要があります。
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station must be encrypted using a 128-bit AES-CCMP [7].
4-AES-CCMP 128の暗号化：モバイルステーションへのと出来事からのすべてのパケットは、128ビットAES-CCMPを使用して暗号化する必要があります[7]。
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must be encrypted using Temporal Key Integrity Protocol (TKIP) and authenticated using Michael [16].
5 -TKIP -MICの暗号化：モバイルステーションのすべてのパケットは、時間キーインテグリティプロトコル（TKIP）を使用して暗号化され、Michael [16]を使用して認証する必要があります。
Session Key: A 32-octet session key the WTP is to use when encrypting traffic to or decrypting traffic from the mobile station. The type of key is determined based on the Encryption Policy field.
セッションキー：32-OCTETセッションキーWTPは、トラフィックを暗号化したり、モバイルステーションからトラフィックを復号化するときに使用します。キーのタイプは、暗号化ポリシーフィールドに基づいて決定されます。
Pairwise TSC: The TKIP Sequence Counter (TSC) to use for unicast packets transmitted to the mobile.
ペアワイズTSC：モバイルに送信されたユニキャストパケットに使用するTKIPシーケンスカウンター（TSC）。
Pairwise RSC: The Receive Sequence Counter (RSC) to use for unicast packets received from the mobile.
ペアワイズRSC：モバイルから受信したユニキャストパケットに使用する受信シーケンスカウンター（RSC）。
Capabilities: A 16-bit field containing the 802.11 capabilities to use with the mobile.
機能：モバイルで使用する802.11機能を含む16ビットフィールド。
WLAN ID: An 8-bit value specifying the WLAN Identifier.
WLAN ID：WLAN識別子を指定する8ビット値。
WME Mode: An 8-bit Boolean used to identify whether the station is WME capable. A value of zero is used to indicate that the station is not Wireless Multimedia Extension (WME) capable, while a value of one means that the station is WME capable.
WMEモード：ステーションがWME能力であるかどうかを識別するために使用される8ビットブール波。ゼロの値は、ステーションがワイヤレスマルチメディア拡張機能（WME）が有能ではないことを示すために使用されますが、1つの値はステーションがWME対応であることを意味します。
802.11e Mode: An 8-bit Boolean used to identify whether the station is 802.11e-capable. A value of zero is used to indicate that the station is not 802.11e-capable, while a value of one means that the station is 802.11e-capable.
802.11eモード：ステーションが802.11e対応であるかどうかを識別するために使用される8ビットブール波。ゼロの値は、ステーションが802.11e対応ではないことを示すために使用されますが、1つの値はステーションが802.11e対応であることを意味します。
QoS: An 8-bit value specifying the QoS policy to enforce for the station. The following values are supported: PRC: TO CHECK
QOS：ステーションを実施するQoSポリシーを指定する8ビット値。次の値がサポートされています：PRC：チェックする
0 - Silver (Best Effort)
0-シルバー（最善の努力）
1 - Gold (Video)
1-ゴールド（ビデオ）
2 - Platinum (Voice)
2-プラチナ（声）
3 - Bronze (Background)
3-ブロンズ（背景）
Supported Rates: The supported rates to be used with the mobile station.
サポートレート：モバイルステーションで使用されるサポートレート。
VLAN Name: An optional variable string containing the VLAN Name on which the WTP is to locally bridge user data. Note that this field is only valid with Local MAC WTPs.
VLAN名：WTPがユーザーデータをローカルにブリッジするVLAN名を含むオプションの変数文字列。このフィールドは、ローカルMac WTPSでのみ有効であることに注意してください。
The Mobile Session Key Payload message element is sent when the AC determines that encryption of a mobile station must be performed in the WTP. This message element MUST NOT be present without the Add Mobile message element, and MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme (see Section 11.7.1.1).
モバイルセッションキーペイロードメッセージ要素は、ACがMobileステーションの暗号化をWTPで実行する必要があると判断したときに送信されます。このメッセージ要素は、モバイルメッセージ要素の追加なしでは存在してはなりません。WTPが要求された暗号化スキームのサポートを具体的に宣伝していない場合は送信しないでください（セクション11.7.1.1を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy | Session Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 105 for IEEE 802.11 Mobile Session Key
タイプ：IEEE 802.11モバイルセッションキーの105
Length: >= 11
MAC Address: The mobile station's MAC address.
MACアドレス：モバイルステーションのMACアドレス。
Encryption Policy: The policy field informs the WTP how to handle packets from/to the mobile station. The following values are supported: 0 - Encrypt WEP 104: All packets to/from the mobile station must be encrypted using a standard 104-bit WEP.
暗号化ポリシー：ポリシーフィールドは、WTPにモバイルステーションからのパケットを処理する方法を通知します。次の値がサポートされています。0-暗号化されたWEP 104：モバイルステーションのすべてのパケットは、標準の104ビットWEPを使用して暗号化する必要があります。
1 - Clear Text: All packets to/from the mobile station do not require any additional crypto processing by the WTP.
1-テキストをクリア：モバイルステーションへの賛成でのすべてのパケットでは、WTPによる追加の暗号処理は必要ありません。
2 - Encrypt WEP 40: All packets to/from the mobile station must be encrypted using a standard 40-bit WEP.
2-暗号化されたWEP 40：モバイルステーションのすべてのパケットは、標準の40ビットWEPを使用して暗号化する必要があります。
3 - Encrypt WEP 128: All packets to/from the mobile station must be encrypted using a standard 128-bit WEP.
3-暗号化されたWEP 128：モバイルステーションのすべてのパケットは、標準の128ビットWEPを使用して暗号化する必要があります。
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station must be encrypted using a 128-bit AES-CCMP [7].
4-AES-CCMP 128の暗号化：モバイルステーションへのと出来事からのすべてのパケットは、128ビットAES-CCMPを使用して暗号化する必要があります[7]。
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must be encrypted using TKIP and authenticated using Michael [16].
5 -TKIP -MICの暗号化：モバイルステーションのすべてのパケットは、TKIPを使用して暗号化され、Michael [16]を使用して認証されている必要があります。
Session Key: The session key the WTP is to use when encrypting traffic to/from the mobile station.
セッションキー：セッションキーWTPは、モバイルステーションとの間でトラフィックを暗号化するときに使用することです。
The Station QoS Profile Payload message element contains the maximum 802.11e priority tag that may be used by the station. Any packets received that exceed the value encoded in this message element must either be dropped or tagged using the maximum value permitted to the user. The priority tag must be between zero (0) and seven (7).
ステーションQoSプロファイルペイロードメッセージ要素には、ステーションが使用できる最大802.11E優先タグが含まれています。このメッセージ要素でエンコードされた値を超える受信したパケットは、ユーザーに許可されている最大値を使用してドロップまたはタグ付けする必要があります。優先タグは、ゼロ（0）と7（7）の間でなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | 802.1P Precedence Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 140 for IEEE 802.11 Station QoS Profile
タイプ：IEEE 802.11ステーションQoSプロファイルの140
Length: 12
長さ：12
MAC Address: The mobile station's MAC address.
MACアドレス：モバイルステーションのMACアドレス。
802.1P Precedence Tag: The maximum 802.1P precedence value that the WTP will allow in the Traffic Identifier (TID) field in the extended 802.11e QoS Data header.
802.1p優先順位タグ：拡張された802.11e QoSデータヘッダーのトラフィック識別子（TID）フィールドでWTPが許可する最大802.1pの優先値。
The Update Mobile QoS message element is used to change the Quality-of-Service policy on the WTP for a given mobile station.
更新モバイルQoSメッセージ要素は、特定のモバイルステーションの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | QoS Profile | Vlan Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP Tag | 802.1P Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 106 for IEEE 802.11 Update Mobile QoS
タイプ：106 IEEE 802.11のモバイルQOを更新します
Length: 14
長さ：14
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
Association ID: The 802.11 Association Identifier.
協会ID：802.11 Association Identifier。
MAC Address: The mobile station's MAC address.
MACアドレス：モバイルステーションのMACアドレス。
QoS Profile: An 8-bit value specifying the QoS policy to enforce for the station. The following values are supported:
QoSプロファイル：ステーションを実施するQoSポリシーを指定する8ビット値。次の値がサポートされています。
0 - Silver (Best Effort)
0-シルバー（最善の努力）
1 - Gold (Video)
1-ゴールド（ビデオ）
2 - Platinum (Voice)
2-プラチナ（声）
3 - Bronze (Background)
3-ブロンズ（背景）
VLAN Identifier: PRC.
VLAN識別子：PRC。
DSCP Tag: The DSCP label to use if packets are to be DSCP tagged.
DSCPタグ：パケットがDSCPタグ付けされる場合に使用するDSCPラベル。
802.1P Tag: The 802.1P precedence value to use if packets are to be 802.1P-tagged.
802.1pタグ：パケットが802.1pタグ付きになる場合に使用する802.1pの優先順位。
This section contains the 802.11-specific message elements that are used with the WTP Event Request message.
このセクションには、WTPイベントリクエストメッセージで使用される802.11固有のメッセージ要素が含まれています。
The Statistics message element is sent by the WTP to transmit its current statistics. The value contains the following fields:
統計メッセージ要素は、現在の統計を送信するために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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Tx Fragment Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tx Fragment Cnt| Multicast Tx Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Tx Cnt | Failed Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed Count | Retry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Count | Multiple Retry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multi Retry Cnt| Frame Duplicate Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Dup Cnt | RTS Success Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTS Success Cnt| RTS Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTS Failure Cnt| ACK Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACK Failure Cnt| Rx Fragment Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rx Fragment Cnt| Multicast RX Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Rx Cnt | FCS Error Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS Error Cnt| Tx Frame Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx Frame Cnt | Decryption Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Decryption Errs|
+-+-+-+-+-+-+-+-+
Type: 38 for Statistics
タイプ：統計の場合は38
Length: 57 Radio ID: An 8-bit value representing the radio.
長さ：57ラジオID：ラジオを表す8ビット値。
Tx Fragment Count: A 32-bit value representing the number of fragmented frames transmitted.
TXフラグメントカウント：送信される断片化されたフレームの数を表す32ビット値。
Multicast Tx Count: A 32-bit value representing the number of multicast frames transmitted.
マルチキャストTXカウント：送信されるマルチキャストフレームの数を表す32ビット値。
Failed Count: A 32-bit value representing the transmit excessive retries.
失敗したカウント：送信過剰の再試行を表す32ビット値。
Retry Count: A 32-bit value representing the number of transmit retries.
再試行：送信回収の数を表す32ビット値。
Multiple Retry Count: A 32-bit value representing the number of transmits that required more than one retry.
複数の再試行カウント：複数の再試行を必要とする送信の数を表す32ビット値。
Frame Duplicate Count: A 32-bit value representing the duplicate frames received.
フレームの複製カウント：受信した重複フレームを表す32ビット値。
RTS Success Count: A 32-bit value representing the number of successfully transmitted Ready To Send (RTS).
RTSの成功カウント：SEND（RTS）の準備が整った成功した送信の数を表す32ビット値。
RTS Failure Count: A 32-bit value representing the failed transmitted RTS.
RTS障害カウント：障害のある送信RTを表す32ビット値。
ACK Failure Count: A 32-bit value representing the number of failed acknowledgements.
ACK障害カウント：失敗した承認の数を表す32ビット値。
Rx Fragment Count: A 32-bit value representing the number of fragmented frames received.
RXフラグメントカウント：受信した断片化されたフレームの数を表す32ビット値。
Multicast RX Count: A 32-bit value representing the number of multicast frames received.
マルチキャストRXカウント：受信したマルチキャストフレームの数を表す32ビット値。
FCS Error Count: A 32-bit value representing the number of Frame Check Sequence (FCS) failures.
FCSエラーカウント：フレームチェックシーケンス（FCS）障害の数を表す32ビット値。
Decryption Errors: A 32-bit value representing the number of Decryption errors that occurred on the WTP. Note that this field is only valid in cases where the WTP provides encryption/ decryption services.
復号化エラー：WTPで発生した復号化エラーの数を表す32ビット値。このフィールドは、WTPが暗号化/復号化サービスを提供する場合にのみ有効であることに注意してください。
This section will define LWAPP control messages that are specific to the IEEE 802.11 binding.
このセクションでは、IEEE 802.11バインディングに固有のLWAPP制御メッセージを定義します。
The IEEE 802.11 WLAN Configuration Request is sent by the AC to the WTP in order to change services provided by the WTP. This control message is used to either create, update, or delete a WLAN on the WTP.
IEEE 802.11 WLAN構成要求は、WTPが提供するサービスを変更するために、ACからWTPに送信されます。このコントロールメッセージは、WTPでWLANを作成、更新、または削除するために使用されます。
The IEEE 802.11 WLAN Configuration Request is sent as a result of either some manual administrative process (e.g., deleting a WLAN), or automatically to create a WLAN on a WTP. When sent automatically to create a WLAN, this control message is sent after the LWAPP Configuration Request message has been received by the WTP.
IEEE 802.11 WLAN構成要求は、いくつかの手動管理プロセス（WLANの削除）のいずれかの結果として送信されるか、自動的にWTPでWLANを作成します。WLANを作成するために自動的に送信されると、LWAPP構成要求メッセージがWTPによって受信された後にこのコントロールメッセージが送信されます。
Upon receiving this control message, the WTP will modify the necessary services, and transmit an IEEE 802.11 WLAN Configuration Response.
この制御メッセージを受信すると、WTPは必要なサービスを変更し、IEEE 802.11 WLAN構成応答を送信します。
An WTP MAY provide service for more than one WLAN: therefore, every WLAN is identified through a numerical index. For instance, a WTP that is capable of supporting up to 16 SSIDs could accept up to 16 IEEE 802.11 WLAN Configuration Request messages that include the Add WLAN message element.
WTPは複数のWLANにサービスを提供する場合があります。したがって、すべてのWLANは数値インデックスを介して識別されます。たとえば、最大16個のSSIDをサポートできるWTPは、ADD WLANメッセージ要素を含む最大16個のIEEE 802.11 WLAN構成要求メッセージを受け入れる可能性があります。
Since the index is the primary identifier for a WLAN, an AC SHOULD attempt to ensure that the same WLAN is identified through the same index number on all of its WTPs. An AC that does not follow this approach MUST find some other means of maintaining a WLAN Identifier to SSID mapping table.
インデックスはWLANの主要な識別子であるため、ACはすべてのWTPで同じインデックス番号を介して同じWLANが識別されるようにしようと試みる必要があります。このアプローチに従わないACは、SSIDマッピングテーブルにWLAN識別子を維持する他の手段を見つける必要があります。
The following subsections define the message elements that are of value for this LWAPP operation. Only one message MUST be present.
次のサブセクションでは、このLWAPP操作に価値のあるメッセージ要素を定義します。1つのメッセージのみが存在する必要があります。
The Add WLAN message element is used by the AC to define a wireless LAN on the WTP. The value contains the following format:
ADD WLANメッセージ要素は、ACによってWTP上のワイヤレスLANを定義するために使用されます。値には次の形式が含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN Capability | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Shared Key | WPA Data Len |WPA IE Data ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSN Data Len |RSN IE Data ...| Reserved .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS | Auth Type |Broadcast SSID | Reserved... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSID ... |
+-+-+-+-+-+-+-+-+
Type: 7 for IEEE 802.11 Add WLAN
タイプ：IEEE 802.11の7つのwlanを追加します
Length: >= 298
Radio ID: An 8-bit value representing the radio.
ラジオID：ラジオを表す8ビット値。
WLAN Capability: A 16-bit value containing the capabilities to be advertised by the WTP within the Probe and Beacon messages.
WLAN機能：プローブおよびビーコンメッセージ内のWTPによって宣伝される機能を含む16ビット値。
WLAN ID: A 16-bit value specifying the WLAN Identifier.
WLAN ID：WLAN識別子を指定する16ビット値。
Encryption Policy: A 32-bit value specifying the encryption scheme to apply to traffic to and from the mobile station.
暗号化ポリシー：モバイルステーションとの間のトラフィックに適用する暗号化スキームを指定する32ビット値。
The following values are supported:
次の値がサポートされています。
0 - Encrypt WEP 104: All packets to/from the mobile station must be encrypted using a standard 104-bit WEP.
0-暗号化されたWEP 104：モバイルステーションのすべてのパケットは、標準の104ビットWEPを使用して暗号化する必要があります。
1 - Clear Text: All packets to/from the mobile station do not require any additional crypto processing by the WTP.
1-テキストをクリア：モバイルステーションへの賛成でのすべてのパケットでは、WTPによる追加の暗号処理は必要ありません。
2 - Encrypt WEP 40: All packets to/from the mobile station must be encrypted using a standard 40-bit WEP.
2-暗号化されたWEP 40：モバイルステーションのすべてのパケットは、標準の40ビットWEPを使用して暗号化する必要があります。
3 - Encrypt WEP 128: All packets to/from the mobile station must be encrypted using a standard 128-bit WEP.
3-暗号化されたWEP 128：モバイルステーションのすべてのパケットは、標準の128ビットWEPを使用して暗号化する必要があります。
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station must be encrypted using a 128-bit AES-CCMP [7].
4-AES-CCMP 128の暗号化：モバイルステーションへのと出来事からのすべてのパケットは、128ビットAES-CCMPを使用して暗号化する必要があります[7]。
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must be encrypted using TKIP and authenticated using Michael [16].
5 -TKIP -MICの暗号化：モバイルステーションのすべてのパケットは、TKIPを使用して暗号化され、Michael [16]を使用して認証されている必要があります。
6 - Encrypt CKIP: All packets to/from the mobile station must be encrypted using Cisco TKIP.
6 -CKIPの暗号化：モバイルステーションへのとMobileからのすべてのパケットは、Cisco TKIPを使用して暗号化する必要があります。
Key: A 32-byte session key to use with the encryption policy.
キー：暗号化ポリシーで使用する32バイトセッションキー。
Key-Index: The Key Index associated with the key.
Key-Index：キーに関連付けられたキーインデックス。
Shared Key: A 1-byte Boolean that specifies whether the key included in the Key field is a shared WEP key. A value of zero is used to state that the key is not a shared WEP key, while a value of one is used to state that the key is a shared WEP key.
共有キー：キーフィールドに含まれるキーが共有WEPキーであるかどうかを指定する1バイトのブール値。ゼロの値は、キーが共有WEPキーではないことを述べるために使用されますが、1つの値は、キーが共有WEPキーであると述べるために使用されます。
WPA Data Len: Length of the WPA Information Element (IE).
WPAデータレン：WPA情報要素の長さ（つまり）。
WPA IE: A 32-byte field containing the WPA Information Element.
WPA IE：WPA情報要素を含む32バイトフィールド。
RSN Data Len: Length of the Robust Security Network (RSN) IE.
RSNデータレン：堅牢なセキュリティネットワーク（RSN）の長さIE。
RSN IE: A 64-byte field containing the RSN Information Element.
RSN IE：RSN情報要素を含む64バイトフィールド。
Reserved: A 49-byte reserved field, which MUST be set to zero (0).
予約済み：49バイトの予約済みフィールド。これはゼロ（0）に設定する必要があります。
WME Data Len: Length of the WME IE.
WMEデータレン：WMEの長さ。
WME IE: A 32-byte field containing the WME Information Element.
WME IE：WME情報要素を含む32バイトフィールド。
DOT11E Data Len: Length of the 802.11e IE.
dot11e data len：802.11eの長さie。
DOT11E IE: A 32-byte field containing the 802.11e Information Element.
DOT11E IE：802.11E情報要素を含む32バイトフィールド。
QOS: An 8-bit value specifying the QoS policy to enforce for the station.
QOS：ステーションを実施するQoSポリシーを指定する8ビット値。
The following values are supported:
次の値がサポートされています。
0 - Silver (Best Effort)
0-シルバー（最善の努力）
1 - Gold (Video)
1-ゴールド（ビデオ）
2 - Platinum (Voice) 3 - Bronze (Background)
2-プラチナ（声）3-ブロンズ（背景）
Auth Type: An 8-bit value specifying the station's authentication type.
認証タイプ：ステーションの認証タイプを指定する8ビット値。
The following values are supported:
次の値がサポートされています。
0 - Open System
0-オープンシステム
1 - WEP Shared Key
1 -WEP共有キー
2 - WPA/WPA2 802.1X
2 -WPA/WPA2 802.1x
3 - WPA/WPA2 PSK
3 -WPA/WPA2 PSK
Broadcast SSID: A Boolean indicating whether the SSID is to be broadcast by the WTP. A value of zero disables SSID broadcast, while a value of one enables it.
ブロードキャストSSID：SSIDがWTPによってブロードキャストされるかどうかを示すブール値。ゼロの値はSSIDブロードキャストを無効にしますが、1つの値はそれを有効にします。
Reserved: A 40-byte reserved field.
予約済み：40バイトの予約済みフィールド。
SSID: The SSID attribute is the service set identifier that will be advertised by the WTP for this WLAN.
SSID：SSID属性は、このWLANのWTPによって宣伝されるサービスセット識別子です。
The Delete WLAN message element is used to inform the WTP that a previously created WLAN is to be deleted. The value contains the following fields:
削除WLANメッセージ要素は、以前に作成されたWLANが削除されることをWTPに通知するために使用されます。値には次のフィールドが含まれています。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 28 for IEEE 802.11 Delete WLAN
タイプ：IEEE 802.11の場合28 wlanを削除します
Length: 3
長さ：3
Radio ID: An 8-bit value representing the radio
ラジオID：ラジオを表す8ビット値
WLAN ID: A 16-bit value specifying the WLAN Identifier
WLAN ID：WLAN識別子を指定する16ビット値
The Update WLAN message element is used by the AC to define a wireless LAN on the WTP. The value contains the following format:
更新WLANメッセージ要素は、ACによってWTPでワイヤレスLANを定義するために使用されます。値には次の形式が含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |Encrypt Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy | Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Shared Key | WLAN Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for IEEE 802.11 Update WLAN
タイプ：34 IEEE 802.11 Update WLANの場合
Length: 43
長さ：43
Radio ID: An 8-bit value representing the radio.
ラジオID：ラジオを表す8ビット値。
WLAN ID: A 16-bit value specifying the WLAN Identifier.
WLAN ID：WLAN識別子を指定する16ビット値。
Encryption Policy: A 32-bit value specifying the encryption scheme to apply to traffic to and from the mobile station.
暗号化ポリシー：モバイルステーションとの間のトラフィックに適用する暗号化スキームを指定する32ビット値。
The following values are supported:
次の値がサポートされています。
0 - Encrypt WEP 104: All packets to/from the mobile station must be encrypted using a standard 104-bit WEP.
0-暗号化されたWEP 104：モバイルステーションのすべてのパケットは、標準の104ビットWEPを使用して暗号化する必要があります。
1 - Clear Text: All packets to/from the mobile station do not require any additional crypto processing by the WTP.
1-テキストをクリア：モバイルステーションへの賛成でのすべてのパケットでは、WTPによる追加の暗号処理は必要ありません。
2 - Encrypt WEP 40: All packets to/from the mobile station must be encrypted using a standard 40-bit WEP.
2-暗号化されたWEP 40：モバイルステーションのすべてのパケットは、標準の40ビットWEPを使用して暗号化する必要があります。
3 - Encrypt WEP 128: All packets to/from the mobile station must be encrypted using a standard 128-bit WEP.
3-暗号化されたWEP 128：モバイルステーションのすべてのパケットは、標準の128ビットWEPを使用して暗号化する必要があります。
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station must be encrypted using a 128-bit AES-CCMP [7].
4-AES-CCMP 128の暗号化：モバイルステーションへのと出来事からのすべてのパケットは、128ビットAES-CCMPを使用して暗号化する必要があります[7]。
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must be encrypted using TKIP and authenticated using Michael [16].
5 -TKIP -MICの暗号化：モバイルステーションのすべてのパケットは、TKIPを使用して暗号化され、Michael [16]を使用して認証されている必要があります。
6 - Encrypt CKIP: All packets to/from the mobile station must be encrypted using Cisco TKIP.
6 -CKIPの暗号化：モバイルステーションへのとMobileからのすべてのパケットは、Cisco TKIPを使用して暗号化する必要があります。
Key: A 32-byte session key to use with the encryption policy.
キー：暗号化ポリシーで使用する32バイトセッションキー。
Key-Index: The Key Index associated with the key.
Key-Index：キーに関連付けられたキーインデックス。
Shared Key: A 1-byte Boolean that specifies whether the key included in the Key field is a shared WEP key. A value of zero means that the key is not a shared WEP key, while a value of one is used to state that the key is a shared WEP key.
共有キー：キーフィールドに含まれるキーが共有WEPキーであるかどうかを指定する1バイトのブール値。ゼロの値は、キーが共有WEPキーではないことを意味しますが、1つの値は、キーが共有WEPキーであると述べるために使用されます。
WLAN Capability: A 16-bit value containing the capabilities to be advertised by the WTP within the Probe and Beacon messages.
WLAN機能：プローブおよびビーコンメッセージ内のWTPによって宣伝される機能を含む16ビット値。
The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN Configuration Request.
IEEE 802.11 WLAN構成応答は、IEEE 802.11 WLAN構成要求の受領の確認として、WTPによってACに送信されます。
This LWAPP control message does not include any message elements.
このLWAPPコントロールメッセージには、メッセージ要素は含まれていません。
The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order to report asynchronous events to the AC. There is no reply message expected from the AC, except that the message is acknowledged via the reliable transport.
IEEE 802.11 WTPイベントLWAPPメッセージは、ACに非同期イベントを報告するためにWTPで使用されます。メッセージが信頼できる輸送を介して認められることを除いて、ACから予想される返信メッセージはありません。
When the AC receives the IEEE 802.11 WTP Event, it will take whatever action is necessary, depending upon the message elements present in the message.
ACがIEEE 802.11 WTPイベントを受信すると、メッセージに存在するメッセージ要素に応じて、必要なアクションが必要になります。
The IEEE 802.11 WTP Event message MUST contain one of the following message elements described in the next subsections.
IEEE 802.11 WTPイベントメッセージには、次のサブセクションで説明されている次のメッセージ要素のいずれかを含める必要があります。
The MIC Countermeasures message element is sent by the WTP to the AC to indicate the occurrence of a MIC failure.
マイク対策要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 61 for IEEE 802.11 MIC Countermeasures
タイプ：61 IEEE 802.11マイク対策の場合
Length: 8 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
長さ：8無線ID：無線識別子は、通常、WTPのインターフェイスインデックスを指します。
WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, on which the MIC failure occurred.
WLAN ID：この8ビットの符号なし整数には、MIC障害が発生したWLAN識別子が含まれます。
MAC Address: The MAC address of the mobile station that caused the MIC failure.
MACアドレス：MIC故障を引き起こしたモバイルステーションのMACアドレス。
The WTP Radio Fail Alarm Indication message element is sent by the WTP to the AC when it detects a radio failure.
WTP無線障害アラーム表示メッセージ要素は、無線障害を検出するとWTPによってACに送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Type | Status | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 95 for WTP Radio Fail Alarm Indication
タイプ：WTPラジオフェイルアラーム表示の95
Length: 4
長さ：4
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
Type: The type of radio failure detected. The following values are supported:
タイプ：検出された無線障害の種類。次の値がサポートされています。
1 - Receiver
1-受信機
2 - Transmitter
2-送信機
Status: An 8-bit Boolean indicating whether the radio failure is being reported or cleared. A value of zero is used to clear the event, while a value of one is used to report the event.
ステータス：無線障害が報告されているかクリアされているかを示す8ビットブール波。ゼロの値はイベントをクリアするために使用され、1つの値はイベントを報告するために使用されます。
Pad: Reserved field MUST be set to zero (0).
PAD：予約済みフィールドはゼロ（0）に設定する必要があります。
The IEEE 802.11 Message Element binding has the following definitions:
IEEE 802.11メッセージ要素バインディングには、次の定義があります。
Conf Conf Conf Add Req Resp Upd Mobile
conf conf add req resp upd mobile
IEEE 802.11 WTP WLAN Radio Configuration X X X
IEEE 802.11 Rate Set X X
IEEE 802.11 Multi-domain Capability X X X
IEEE 802.11 MAC Operation X X X
IEEE 802.11 Tx Power X X X
IEEE 802.11 Tx Power Level X
IEEE 802.11 Direct Sequence Control X X X
IEEE 802.11 OFDM Control X X X
IEEE 802.11 Supported Rates X X
IEEE 802.11 Antenna X X X
IEEE 802.11 CFP Status X X
IEEE 802.11 Broadcast Probe Mode X X
IEEE 802.11 WTP Mode and Type X? X
IEEE 802.11 WTP Quality of Service X X
IEEE 802.11 MIC Error Report From Mobile X
IEEE 802.11 Update Mobile QoS X
IEEE 802.11 Mobile Session Key X
The WTP WLAN radio configuration is used by the AC to configure a Radio on the WTP. The message element value contains the following Fields:
WTP WLAN無線構成は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | Occupancy Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CFP Per | CFP Maximum Duration | BSS ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSS ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSS ID | Beacon Period | DTIM Per |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Country String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Of BSSIDs |
+-+-+-+-+-+-+-+-+
Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration
タイプ：8 IEEE 802.11 WTP WLAN無線構成の場合
Length: 20
長さ：20
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
Occupancy Limit: This attribute indicates the maximum amount of time, in Time Units (TUs), that a point coordinator MAY control the usage of the wireless medium without relinquishing control for long enough to allow at least one instance of Distributed Coordination Function (DCF) access to the medium. The default value of this attribute SHOULD be 100, and the maximum value SHOULD be 1000.
占有制限：この属性は、時間単位（TUS）の最大時間を示しています。ポイントコーディネーターは、分散調整関数（DCF）の少なくとも1つのインスタンスを許可するのに十分な長さの制御を放棄することなく、ワイヤレスメディアの使用を制御できることを示しています。媒体へのアクセス。この属性のデフォルト値は100でなければならず、最大値は1000でなければなりません。
CFP Period: The attribute describes the number of DTIM intervals between the start of Contention-Free Periods (CFPs).
CFP期間：属性は、競合のない期間（CFP）の開始の間のDTIM間隔の数を記述します。
CFP Maximum Duration: The attribute describes the maximum duration of the CFP in TU that MAY be generated by the Point Coordination Function (PCF).
CFPの最大期間：属性は、ポイント調整関数（PCF）によって生成される可能性のあるTUのCFPの最大持続時間を記述します。
BSSID: The WLAN Radio's base MAC address. For WTPs that support more than a single WLAN, the value of the WLAN Identifier is added to the last octet of the BSSID. Therefore, a WTP that supports 16 WLANs MUST have 16 MAC addresses reserved for it, and the last nibble is used to represent the WLAN ID.
BSSID：WLANラジオのベースMACアドレス。単一のWLANを超えるWTPSの場合、WLAN識別子の値がBSSIDの最後のオクテットに追加されます。したがって、16のWLANをサポートするWTPには、16のMacアドレスが予約されている必要があり、最後のニブルはWLAN IDを表すために使用されます。
Beacon Period: This attribute specifies the number of TUs that a station uses for scheduling Beacon transmissions. This value is transmitted in Beacon and Probe Response frames.
ビーコン期間：この属性は、ステーションがビーコン送信のスケジューリングに使用するTUの数を指定します。この値は、ビーコンおよびプローブ応答フレームで送信されます。
DTIM Period: This attribute specifies the number of Beacon intervals that elapses between transmission of Beacons frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames.
DTIM期間：この属性は、DTIMカウントフィールドが0であるTIM要素を含むビーコンフレームの伝送の間で経過するビーコン間隔の数を指定します。この値は、ビーコンフレームのDTIM周期フィールドで送信されます。
Country Code: This attribute identifies the country in which the station is operating. The first two octets of this string is the two-character country code as described in document ISO/IEC 3166- 1. The third octet MUST be one of the following:
国コード：この属性は、駅が運営されている国を識別します。この文字列の最初の2つのオクテットは、ドキュメントISO/IEC 3166-で説明されている2文字の国コードです。3番目のオクテットは次のいずれかでなければなりません。
1. an ASCII space character, if the regulations under which the station is operating encompass all environments in the country,
1. ASCIIスペースの特徴、駅が運営している規制に国内のすべての環境を網羅する場合、
2. an ASCII 'O' character, if the regulations under which the station is operating are for an outdoor environment only, or
2. ASCII 'o'キャラクター、ステーションが動作している規制が屋外環境のみである場合、または
3. an ASCII 'I' character, if the regulations under which the station is operating are for an indoor environment only.
3. ASCII 'i'キャラクター。ステーションが動作している規制が屋内環境のみである場合。
Number of BSSIDs: This attribute contains the maximum number of BSSIDs supported by the WTP. This value restricts the number of logical networks supported by the WTP.
BSSIDSの数：この属性には、WTPがサポートするBSSIDの最大数が含まれています。この値は、WTPがサポートする論理ネットワークの数を制限します。
The Rate Set message element value is sent by the AC and contains the supported operational rates. It contains the following fields:
レートセットメッセージ要素値は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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Rate Set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for IEEE 802.11 Rate Set
タイプ：16 IEEE 802.11レートセットの場合
Length: 4
長さ：4
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Rate Set: The AC generates the Rate Set that the WTP is to include in its Beacon and Probe messages.
レートセット：ACは、WTPがビーコンとプローブメッセージに含めるレートセットを生成します。
The Multi-Domain Capability message element is used by the AC to inform the WTP of regulatory limits. The value contains the following fields:
マルチドメイン機能メッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | First Channel # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Channels | Max Tx Power Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 for IEEE 802.11 Multi-Domain Capability
タイプ：IEEE 802.11マルチドメイン機能の場合
Length: 8
長さ：8
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Reserved: MUST be set to zero First Channel #: This attribute indicates the value of the lowest channel number in the subband for the associated domain country string.
予約：最初のチャネル＃に設定する必要があります＃：この属性は、関連するドメイン国の文字列のサブバンドの最低チャネル数の値を示します。
Number of Channels: This attribute indicates the value of the total number of channels allowed in the subband for the associated domain country string.
チャネルの数：この属性は、関連するドメイン国の文字列にサブバンドで許可されるチャネルの総数の値を示します。
Max Tx Power Level: This attribute indicates the maximum transmit power, in dBm, allowed in the subband for the associated domain country string.
Max TXパワーレベル：この属性は、関連するドメイン国の文字列のサブバンドで許可されるDBMの最大送信電力を示します。
The MAC Operation message element is sent by the AC to set the 802.11 MAC parameters on the WTP. The value contains the following fields:
Mac操作メッセージ要素は、ACによって送信され、WTPに802.11 Macパラメーターを設定します。値には次のフィールドが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | RTS Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Short Retry | Long Retry | Fragmentation Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 11 for IEEE 802.11 MAC Operation
タイプ：IEEE 802.11 Mac操作の場合11
Length: 16
長さ：16
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
RTS Threshold: This attribute indicates the number of octets in a Management Protocol Data Unit (MPDU), below which an RTS/CTS (clear to send) handshake MUST NOT be performed. An RTS/CTS handshake MUST be performed at the beginning of any frame exchange sequence where the MPDU is of type Data or Management, the MPDU has an individual address in the Address1 field, and the length of the MPDU is greater than this threshold. Setting this attribute to be larger than the maximum MAC Service Data Unit (MSDU) size MUST have the effect of turning off the RTS/CTS handshake for frames of Data or Management type transmitted by this Station (STA). Setting this attribute to zero MUST have the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA. The default value of this attribute MUST be 2347.
RTSしきい値：この属性は、管理プロトコルデータユニット（MPDU）のオクテットの数を示します。MPDUがタイプデータまたは管理の任意のフレーム交換シーケンスの先頭に、RTS/CTSハンドシェイクを実行する必要があり、MPDUにはaddress1フィールドに個別のアドレスがあり、MPDUの長さはこのしきい値よりも大きくなります。この属性の設定は、最大MACサービスデータユニット（MSDU）サイズよりも大きくなるように設定すると、このステーション（STA）が送信したデータまたは管理型のフレームに対してRTS/CTSハンドシェイクをオフにする効果が必要です。この属性をゼロに設定するには、このSTAが送信したデータまたは管理タイプのすべてのフレームに対してRTS/CTSの握手をオンにする効果が必要です。この属性のデフォルト値は2347でなければなりません。
Short Retry: This attribute indicates the maximum number of transmission attempts of a frame, the length of which is less than or equal to RTSThreshold, that MUST be made before a failure condition is indicated. The default value of this attribute MUST be 7.
短い再試行：この属性は、フレームの伝送試行の最大数を示します。その長さはrtSthresholdよりも等しく、故障条件が示される前に行う必要があります。この属性のデフォルト値は7でなければなりません。
Long Retry: This attribute indicates the maximum number of transmission attempts of a frame, the length of which is greater than dot11RTSThreshold, that MUST be made before a failure condition is indicated. The default value of this attribute MUST be 4.
長い再試行：この属性は、フレームの伝送試行の最大数を示します。その長さは、障害条件が示される前に行う必要があるDOT11RTSTHRESHOLDよりも大きくなります。この属性のデフォルト値は4でなければなりません。
Fragmentation Threshold: This attribute specifies the current maximum size, in octets, of the MPDU that MAY be delivered to the PHY. An MSDU MUST be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers. An MSDU or MAC Management Protocol Data Unit (MMPDU) MUST be fragmented when the resulting frame has an individual address in the Address1 field, and the length of the frame is larger than this threshold. The default value for this attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the attached PHY and MUST never exceed the lesser of 2346 or the aMPDUMaxLength of the attached PHY. The value of this attribute MUST never be less than 256.
断片化しきい値：この属性は、PHYに配信されるMPDUの現在の最大サイズのオクテットを指定します。MACヘッダーとトレーラーを追加した後、そのサイズがこの属性の値を超える場合、MSDUはフラグメントに分割する必要があります。MSDUまたはMAC管理プロトコルデータユニット（MMPDU）は、結果のフレームにAddress1フィールドに個別のアドレスがあり、フレームの長さがこのしきい値よりも大きい場合に断片化する必要があります。この属性のデフォルト値は、2346の低いまたは接続されたPhyのampDumaxLengthの長さである必要があり、2346の低いものまたは接続されたPhyのAmpDumaxLengthを超えてはなりません。この属性の値は、256未満でなければなりません。
Tx MSDU Lifetime: This attribute specifies the elapsed time in TU, after the initial transmission of an MSDU, after which, further attempts to transmit the MSDU MUST be terminated. The default value of this attribute MUST be 512.
TX MSDU Lifetime：この属性は、MSDUの最初の送信後、MSDUをさらに送信する試みを終了する必要があるTUでの経過時間を指定します。この属性のデフォルト値は512でなければなりません。
Rx MSDU Lifetime: This attribute specifies the elapsed time, in TU, after the initial reception of a fragmented MMPDU or MSDU, after which, further attempts to reassemble the MMPDU or MSDU MUST be terminated. The default value MUST be 512.
RX MSDU Lifetime：この属性は、断片化されたMMPDUまたはMSDUの最初の受信後、TUでの経過時間を指定します。その後、MMPDUまたはMSDUを再組み立てしようとする試みを終了する必要があります。デフォルト値は512でなければなりません。
The Tx Power message element value is bi-directional. When sent by the WTP, it contains the current power level of the radio in question. When sent by the AC, it contains the power level to which the WTP MUST adhere:
TX Powerメッセージ要素値は双方向です。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | Current Tx Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 12 for IEEE 802.11 Tx Power
タイプ：IEEE 802.11 TX Powerの場合は12
Length: 4
長さ：4
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
Current Tx Power: This attribute contains the transmit output power in mW.
現在のTX電源：この属性には、MWの送信出力電力が含まれています。
The Tx Power Level message element is sent by the WTP and contains the different power levels supported. The value contains the following fields:
TXパワーレベルのメッセージ要素は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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Num Levels | Power Level [n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 13 for IEEE 802.11 Tx Power Level
タイプ：13 IEEE 802.11 TXパワーレベル
Length: >= 4
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Num Levels: The number of power level attributes.
NUMレベル：電力レベルの属性の数。
Power Level: Each power level fields contains a supported power level, in mW.
パワーレベル：各パワーレベルフィールドには、MWのサポートされたパワーレベルが含まれています。
The Direct Sequence Control message element is a bi-directional element. When sent by the WTP, it contains the current state. When sent by the AC, the WTP MUST adhere to the values. This element is only used for 802.11b radios. The value has the following fields.
直接シーケンスコントロールメッセージ要素は、双方向の要素です。WTPから送信されると、現在の状態が含まれます。ACから送信されると、WTPは値に付着する必要があります。この要素は、802.11bラジオにのみ使用されます。値には次のフィールドがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | Current Chan | Current CCA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Energy Detect Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 14 for IEEE 802.11 Direct Sequence Control
タイプ：IEEE 802.11直接シーケンス制御の場合14
Length: 8
長さ：8
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
Current Channel: This attribute contains the current operating frequency channel of the Direct Sequence Spread Spectrum (DSSS) PHY.
現在のチャネル：この属性には、直接シーケンススプレッドスペクトル（DSSS）Phyの現在の動作周波数チャネルが含まれています。
Current CCA: The current Controlled Channel Access (CCA) method in operation. Valid values are:
現在のCCA：操作中の現在の制御チャネルアクセス（CCA）メソッド。有効な値は次のとおりです。
1 - energy detect only (edonly)
1-エネルギー検出のみ（エドンリー）
2 - carrier sense only (csonly)
2-キャリアセンスのみ（csonly）
4 - carrier sense and energy detect (edandcs)
4-キャリアセンスとエネルギー検出（EDANDCS）
8 - carrier sense with timer (cswithtimer)
8-タイマー付きキャリアセンス（cswithtimer）
16 - high-rate carrier sense and energy detect (hrcsanded)
16-高級キャリアセンスとエネルギー検出（HRCSANDED）
Energy Detect Threshold: The current Energy Detect Threshold being used by the DSSS PHY.
エネルギー検出しきい値：DSSS Phyが使用する現在のエネルギー検出しきい値。
The Orthogonal Frequency Division Multiplexing (OFDM) Control message element is a bi-directional element. When sent by the WTP, it contains the current state. When sent by the AC, the WTP MUST adhere to the values. This element is only used for 802.11a radios. The value contains the following fields:
直交周波数除算マルチプレックス（OFDM）制御メッセージ要素は、双方向の要素です。WTPから送信されると、現在の状態が含まれます。ACから送信されると、WTPは値に付着する必要があります。この要素は、802.11aラジオにのみ使用されます。値には次のフィールドが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | Current Chan | Band Support |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TI Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15 for IEEE 802.11 OFDM Control
タイプ：15 IEEE 802.11 OFDMコントロール
Length: 8
長さ：8
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Reserved: MUST be set to zero
予約済み：ゼロに設定する必要があります
Current Channel: This attribute contains the current operating frequency channel of the OFDM PHY.
現在のチャネル：この属性には、OFDM Phyの現在の動作周波数チャネルが含まれています。
Band Supported: The capability of the OFDM PHY implementation to operate in the three U-NII bands. Coded as an integer value of a 3-bit field as follows:
サポート：3つのU-NIIバンドで動作するOFDM PHY実装の機能。次のように、3ビットフィールドの整数値としてコード化されています。
Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII band
ビット0-下部（5.15-5.25 GHz）U-NIIバンドで操作できる
Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII band
ビット1-中央で操作できる（5.25-5.35 GHz）U-NIIバンド
Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII band
ビット2-アッパー（5.725-5.825 GHz）U-NIIバンドで動作することができます
For example, for an implementation capable of operating in the lower and mid bands, this attribute would take the value.
たとえば、低バンドとミッドバンドで動作できる実装の場合、この属性は値を取ります。
TI Threshold: The threshold being used to detect a busy medium (frequency). CCA MUST report a busy medium upon detecting the RSSI above this threshold.
TIしきい値：忙しい媒体（周波数）を検出するために使用されるしきい値。CCAは、このしきい値を超えるRSSIを検出する際に、忙しい媒体を報告する必要があります。
The Antenna message element is communicated by the WTP to the AC to provide information on the antennas available. The AC MAY use this element to reconfigure the WTP's antennas. The value contains the following fields:
アンテナメッセージ要素は、WTPによって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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Diversity | Combiner | Antenna Cnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna Selection [0..N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 41 for IEEE 802.11 Antenna
タイプ：IEEE 802.11アンテナの場合41
Length: >= 8
Radio ID: An 8-bit value representing the radio to configure.
ラジオID：構成するラジオを表す8ビット値。
Diversity: An 8-bit value specifying whether the antenna is to provide receive diversity. The following values are supported:
多様性：アンテナが受信多様性を提供するかどうかを指定する8ビット値。次の値がサポートされています。
0 - Disabled
0-無効
1 - Enabled (may only be true if the antenna can be used as a receive antenna)
1-有効になっている（アンテナを受信アンテナとして使用できる場合にのみ当てはまる場合があります）
Combiner: An 8-bit value specifying the combiner selection. The following values are supported:
コンビナー：コンビナーの選択を指定する8ビット値。次の値がサポートされています。
1 - Sectorized (Left)
1-セクター化（左）
2 - Sectorized (Right)
2-セクター（右）
3 - Omni
3-オムニ
4 - Mimo
4-ミモ
Antenna Count: An 8-bit value specifying the number of Antenna Selection fields.
アンテナカウント：アンテナ選択フィールドの数を指定する8ビット値。
Antenna Selection: One 8-bit antenna configuration value per antenna in the WTP. The following values are supported:
アンテナ選択：WTPのアンテナごとに1つの8ビットアンテナ構成値。次の値がサポートされています。
1 - Internal Antenna
1-内部アンテナ
2 - External Antenna
2-外部アンテナ
The Supported Rates message element is sent by the WTP to indicate the rates that it supports. The value contains the following fields:
サポートされているレートメッセージ要素は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for IEEE 802.11 Supported Rates
タイプ：16 IEEE 802.11のサポートレート
Length: 4
長さ：4
Radio ID: An 8-bit value representing the radio.
ラジオID：ラジオを表す8ビット値。
Supported Rates: The WTP includes the Supported Rates that its hardware supports. The format is identical to the Rate Set message element.
サポートレート：WTPには、ハードウェアがサポートするサポートレートが含まれています。形式は、レートセットメッセージ要素と同じです。
The CFP Status message element is sent to provide the CF Polling configuration.
CFPステータスメッセージ要素は、CFポーリング構成を提供するために送信されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 48 for IEEE 802.11 CFP Status
タイプ：IEEE 802.11 CFPステータスの48
Length: 2
長さ：2
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
Status: An 8-bit Boolean containing the status of the CF Polling feature. A value of zero disables CFP Status, while a value of one enables it.
ステータス：CFポーリング機能のステータスを含む8ビットブール。ゼロの値はCFPステータスを無効にしますが、1つの値はそれを有効にします。
The WTP Mode and Type message element is used to configure a WTP to operate in a specific mode.
WTPモードとタイプメッセージ要素は、特定のモードで動作するようにWTPを構成するために使用されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 54 for IEEE 802.11 WTP Mode and Type
タイプ：54 IEEE 802.11 WTPモードとタイプの場合
Length: 2
長さ：2
Mode: An 8-bit value describing the type of information being sent. The following values are supported:
モード：送信される情報の種類を説明する8ビット値。次の値がサポートされています。
0 - Split MAC
0-分割MAC
2 - Local MAC
2-ローカルマック
Type: The type field is not currently used.
タイプ：タイプフィールドは現在使用されていません。
The Broadcast Probe Mode message element indicates whether a WTP will respond to NULL SSID Probe requests. Since broadcast NULL Probes are not sent to a specific BSSID, the WTP cannot know which SSID the sending station is querying. Therefore, this behavior must be global to the WTP.
ブロードキャストプローブモードメッセージ要素は、WTPがNULL SSIDプローブ要求に応答するかどうかを示します。ブロードキャストヌルプローブは特定のBSSIDに送信されないため、WTPは送信ステーションがどのSSIDがクエリをしているかを知ることができません。したがって、この動作はWTPにとってグローバルでなければなりません。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+
Type: 51 for IEEE 802.11 Broadcast Probe Mode
タイプ：51 IEEE 802.11ブロードキャストプローブモードの場合
Length: 1
長さ：1
Status: An 8-bit Boolean indicating the status of whether a WTP shall respond to a NULL SSID Probe request. A value of zero disables the NULL SSID Probe response, while a value of one enables it.
ステータス：WTPがnull SSIDプローブリクエストに応答するかどうかのステータスを示す8ビットブール値。ゼロの値はnull ssidプローブ応答を無効にしますが、1つの値はそれを有効にします。
The WTP Quality of Service message element value is sent by the AC to the WTP to communicate quality-of-service configuration information.
WTP Quality of Serviceメッセージ要素値は、ACからWTPに送信され、サービス品質構成情報を通知します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Tag Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 57 for IEEE 802.11 WTP Quality of Service Length: 12
タイプ：57 IEEE 802.11 WTPサービス品質長：12
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
Tag Packets: A value indicating whether LWAPP packets should be tagged for QoS purposes. The following values are currently supported:
タグパケット：QoS目的でLWAPPパケットにタグを付けるべきかどうかを示す値。現在、次の値がサポートされています。
0 - Untagged
0-未編成
1 - 802.1P
1-802.1p
2 - DSCP
2 -DSCP
Immediately following the above header is the following data structure. This data structure will be repeated five times, once for every QoS profile. The order of the QoS profiles is Uranium, Platinum, Gold, Silver, and Bronze.
上記のヘッダーの直後に、次のデータ構造があります。このデータ構造は、QoSプロファイルごとに1回、5回繰り返されます。QoSプロファイルの順序は、ウラン、プラチナ、ゴールド、シルバー、ブロンズです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queue Depth | CWMin | CWMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CWMax | AIFS | CBR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dot1P Tag | DSCP Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Queue Depth: The number of packets that can be on the specific QoS transmit queue at any given time.
キューの深さ：特定のQoS送信キューにあるパケットの数は、いつでもキューを送信します。
CWMin: The Contention Window minimum value for the QoS transmit queue.
CWMIN：QOS送信キューの競合ウィンドウの最小値。
CWMax: The Contention Window maximum value for the QoS transmit queue.
CWMAX：QOS送信キューのコンチェンションウィンドウの最大値。
AIFS: The Arbitration Inter Frame Spacing to use for the QoS transmit queue.
AIFS：QoS送信キューに使用する仲裁間のフレーム間隔。
CBR: The Constant Bit Rate (CBR) value to observe for the QoS transmit queue.
CBR：QoS送信キューを観察する一定のビットレート（CBR）値。
Dot1P Tag: The 802.1P precedence value to use if packets are to be 802.1P tagged.
dot1pタグ：パケットが802.1pにタグ付けされる場合に使用する802.1pの優先順位値。
DSCP Tag: The DSCP label to use if packets are to be DSCP tagged.
DSCPタグ：パケットがDSCPタグ付けされる場合に使用するDSCPラベル。
The MIC Error Report From Mobile message element is sent by an AC to a WTP when it receives a MIC failure notification via the Error bit in the EAP over LAN (EAPOL)-Key frame.
モバイルメッセージ要素からのMICエラーレポートは、LAN（Eapol）-KeyフレームのEAPでエラービットを介してマイク障害通知を受信すると、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client MAC Address | BSSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 79 for IEEE 802.11 MIC Error Report From Mobile
タイプ：79 IEEE 802.11モバイルからのマイクエラーレポート
Length: 14
長さ：14
Client MAC Address: The Client MAC address of the station reporting the MIC failure.
クライアントMACアドレス：マイク障害を報告するステーションのクライアントMACアドレス。
BSSID: The BSSID on which the MIC failure is being reported.
BSSID：マイク障害が報告されているBSSID。
Radio ID: The Radio Identifier, typically refers to some interface index on the WTP.
無線ID：ラジオ識別子は、通常、WTPのインターフェイスインデックスを指します。
WLAN ID: The WLAN ID on which the MIC failure is being reported.
WLANは次のとおりです。WLANは、マイク障害が報告されていることです。
This section lists IEEE 802.11-specific values for any generic LWAPP message elements that include fields whose values are technology-specific.
このセクションには、値がテクノロジー固有のフィールドを含む一般的なLWAPPメッセージ要素のIEEE 802.11固有の値がリストされています。
IEEE 802.11 uses the following values:
IEEE 802.11は次の値を使用します。
4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7].
4-AES-CCMP 128を暗号化：WTPは、[7]で定義されているようにAES-CCMPをサポートします。
5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in [16].
5-暗号化TKIP -MIC：WTPは[16]で定義されているように、TKIPとマイケルをサポートします。
A WTP or AC that implements LWAPP discovery MUST implement the following timers.
LWAPP発見を実装するWTPまたはACは、次のタイマーを実装する必要があります。
The maximum time allowed between sending Discovery Requests from the interface, in seconds. Must be no less than 2 seconds and no greater than 180 seconds.
インターフェイスから発見要求を送信するまでに許可される最大時間は、数秒で。2秒以上、180秒以下でなければなりません。
Default: 20 seconds.
デフォルト：20秒。
The minimum time, in seconds, a WTP MUST wait after failing to receive any responses to its Discovery Requests, before it MAY again send Discovery Requests.
最小時間、数秒で、WTPは、発見要求への応答を受け取っていない後、再び発見リクエストを送信する前に待つ必要があります。
Default: 30
デフォルト：30
The minimum time, in seconds, a WTP MUST wait without having received Echo Responses to its Echo Requests, before the destination for the Echo Request may be considered dead. Must be no less than 2*EchoInterval seconds and no greater than 240 seconds.
最小時間、数秒で、Echo要求の宛先が死んでいると見なされる前に、Echoリクエストに対するエコー応答を受け取ったことなく、WTPが待機する必要があります。2*エコーインターバル秒、240秒以下でなければなりません。
Default: 60
デフォルト：60
The minimum time, in seconds, between sending Echo Requests to the AC with which the WTP has joined.
最低時間は、WTPが参加したACにエコーリクエストを送信する間の最小時間。
Default: 30
デフォルト：30
The minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response, before sending a Join Request.
最小時間、数秒で、Join Requestを送信する前に、Discovery Responseを受信した後、WTPが待機する必要があります。
Default: 5
デフォルト：5
The minimum time, in seconds, that a non-acknowledged LWAPP packet will be retransmitted.
最低時間、数秒で、概要のないLWAPPパケットが再送信されます。
Default: 3
デフォルト：3
The minimum time, in seconds, in which an LWAPP Request message must be responded to.
LWAPP要求メッセージを応答する必要がある秒単位での最小時間。
Default: 1
デフォルト：1
The maximum time, in seconds, that an LWAPP session key is valid.
LWAPPセッションキーが有効であるという最大時間、数秒で。
Default: 28800
デフォルト：28800
A WTP or AC that implements LWAPP discovery MUST allow for the following variables to be configured by system management; default values are specified so as to make it unnecessary to configure any of these variables in many cases.
LWAPP発見を実装するWTPまたはACは、システム管理によって次の変数を構成する必要があります。多くの場合、これらの変数のいずれかを構成する必要がないように、デフォルト値が指定されています。
The maximum number of Discovery Requests that will be sent after a WTP boots.
WTPブーツの後に送信される発見要求の最大数。
Default: 10
デフォルト：10
The number of discoveries transmitted by a WTP to a single AC. This is a monotonically increasing counter.
WTPによって単一のACに送信される発見の数。これは単調に増加するカウンターです。
The number of retransmissions for a given LWAPP packet. This is a monotonically increasing counter.
特定のLWAPPパケットの再送信の数。これは単調に増加するカウンターです。
The maximum number of retransmissions for a given LWAPP packet before the link layer considers the peer dead.
リンクレイヤーがピアデッドと見なされる前の特定のLWAPPパケットの再送信の最大数。
Default: 5
デフォルト：5
There are two specific situations where a NAT system may be used in conjunction with LWAPP. The first consists of a configuration where the WTP is behind a NAT system. Given that all communication is initiated by the WTP, and all communication is performed over IP using a single UDP port, the protocol easily traverses NAT systems in this configuration.
NATシステムをLWAPPと組み合わせて使用できる2つの特定の状況があります。最初は、WTPがNATシステムの背後にある構成で構成されています。すべての通信がWTPによって開始され、すべての通信が単一のUDPポートを使用してIPを介して実行されることを考えると、プロトコルはこの構成でNATシステムを簡単に通過できます。
The second configuration is one where the AC sits behind a NAT, and there are two main issues that exist in this situation. First, an AC communicates its interfaces and associated WTP load on these interfaces, through the WTP Manager Control IP Address. This message element is currently mandatory, and if NAT compliance became an issue, it would be possible to either:
2番目の構成は、ACがNATの後ろに位置するものであり、この状況には2つの主要な問題があります。まず、ACは、WTP Manager Control IPアドレスを介して、これらのインターフェイス上のインターフェイスと関連するWTP負荷を通知します。このメッセージ要素は現在必須であり、NATコンプライアンスが問題になった場合、次のことを可能にします。
1. make the WTP Manager Control IP Address optional, allowing the WTP to simply use the known IP address. However, note that this approach would eliminate the ability to perform load balancing of WTP across ACs, and therefore is not the recommended approach.
1. WTPマネージャーコントロールIPアドレスをオプションにし、WTPが既知のIPアドレスを単純に使用できるようにします。ただし、このアプローチは、ACS間のWTPの負荷分散を実行する能力を排除するため、推奨されるアプローチではないことに注意してください。
2. allow an AC to be able to configure a NAT'ed address for every associated AC that would generally be communicated in the WTP Manager Control IP Address message element.
2. ACが、一般にWTPマネージャーコントロールIPアドレスメッセージ要素で通信されるすべての関連するACのNAT'edアドレスを構成できるようにします。
3. require that if a WTP determines that the AC List message element consists of a set of IP addresses that are different from the AC's IP address it is currently communicating with, then assume that NAT is being enforced, and require that the WTP communicate with the original AC's IP address (and ignore the WTP Manager Control IP Address message element(s)).
3. ACリストメッセージ要素が現在通信しているACのIPアドレスとは異なるIPアドレスのセットで構成されていることをWTPが判断した場合、NATが施行されていると仮定し、WTPが元のものと通信することを要求することが必要です。ACのIPアドレス（およびWTPマネージャーコントロールIPアドレスメッセージ要素を無視します）。
Another issue related to having an AC behind a NAT system is LWAPP's support for the CAPWAP Objective to allow the control and data plane to be separated. In order to support this requirement, the LWAPP protocol defines the WTP Manager Data IP Address message element, which allows the AC to inform the WTP that the LWAPP data frames are to be forwarded to a separate IP address. This feature MUST be disabled when an AC is behind a NAT. However, there is no easy way to provide some default mechanism that satisfies both the data/ control separation and NAT objectives, as they directly conflict with each other. As a consequence, user intervention will be required to support such networks.
NATシステムの背後にACを持つことに関連する別の問題は、CAPWAP目標に対するLWAPPのサポートであり、コントロールとデータプレーンを分離できるようにします。この要件をサポートするために、LWAPPプロトコルはWTPマネージャーデータIPアドレスメッセージ要素を定義します。これにより、ACはLWAPPデータフレームを別のIPアドレスに転送することをWTPに通知できます。ACがNATの背後にある場合、この機能は無効にする必要があります。ただし、データ/制御分離とNATの目標の両方を満たすデフォルトメカニズムを提供する簡単な方法は、互いに直接競合するためです。結果として、そのようなネットワークをサポートするには、ユーザーの介入が必要になります。
LWAPP has a feature that allows for all of the AC's identities supporting a group of WTPs to be communicated through the AC List message element. This feature must be disabled when the AC is behind a NAT and the IP address that is embedded would be invalid.
LWAPPには、WTPのグループをサポートするACリストメッセージ要素を介して通信できるすべてのACのアイデンティティを可能にする機能があります。ACがNATの背後にある場合、この機能は無効にする必要があり、埋め込まれたIPアドレスが無効になります。
The LWAPP protocol has a feature that allows an AC to configure a static IP address on a WTP. The WTP Static IP Address Information message element provides such a function; however, this feature SHOULD NOT be used in NAT'ed environments, unless the administrator is familiar with the internal IP addressing scheme within the WTP's private network, and does not rely on the public address seen by the AC.
LWAPPプロトコルには、ACがWTPで静的IPアドレスを構成できるようにする機能があります。WTP静的IPアドレス情報メッセージ要素は、そのような関数を提供します。ただし、管理者がWTPのプライベートネットワーク内の内部IPアドレス指定スキームに精通しており、ACが見たパブリックアドレスに依存していない場合を除き、この機能はNATの環境では使用しないでください。
When a WTP detects the duplicate address condition, it generates a message to the AC, which includes the Duplicate IP Address message element. Once again, it is important to note that the IP address embedded within this message element would be different from the public IP address seen by the AC.
WTPが複製アドレス条件を検出すると、ACへのメッセージが生成されます。これには、重複するIPアドレスメッセージ要素が含まれます。繰り返しになりますが、このメッセージ要素に埋め込まれたIPアドレスは、ACで見られるパブリックIPアドレスとは異なることに注意することが重要です。
LWAPP uses either an authenticated key exchange or key agreement mechanism to ensure peer authenticity and establish fresh session keys to protect the LWAPP communications.
LWAPPは、認証されたキー交換またはキー契約メカニズムのいずれかを使用して、ピアの信頼性を確保し、LWAPP通信を保護するための新鮮なセッションキーを確立します。
The LWAPP protocol defines a join phase, which allows a WTP to bind a session with an AC. During this process, a session key is mutually derived, and secured either through an X.509 certificate or a pre-shared key. The resulting key exchange generates an encryption session key, which is used to encrypt the LWAPP control packets, and a key derivation key.
LWAPPプロトコルは、JONフェーズを定義します。これにより、WTPがACでセッションをバインドできます。このプロセス中に、セッションキーが相互に派生し、X.509証明書または事前に共有キーのいずれかを介して保護されます。結果のキーエクスチェンジは、暗号化セッションキーを生成します。これは、LWAPPコントロールパケットとキー派生キーを暗号化するために使用されます。
During the established secure communication, the WTP and AC may rekey using the key update process, which is identical to the join phase, meaning the session keys are mutually derived. However, the exchange described for pre-shared session keys is always used for the key update, with the pre-shared key set to the derivation key created either during the join, or the last key update if one has occurred. The key update results in a new derivation key, which is used in the next key update, as well as an encryption session key to encrypt the LWAPP control packets.
確立された安全な通信中、WTPとACは、結合フェーズと同一のキーアップデートプロセスを使用して再キーを使用する場合があります。つまり、セッションキーは相互に派生します。ただし、事前に共有セッションキーについて説明した交換は、常にキーアップデートに使用され、接続中に作成された派生キーに設定されているか、または発生した場合の最後のキーアップデートのいずれかに作成されます。キーアップデートでは、次のキーアップデートで使用される新しい派生キーと、LWAPPコントロールパケットを暗号化する暗号化セッションキーが表示されます。
Replay protection of the Join Request is handled through an exchange of nonces during the join (or key update) phase. The Join Request includes an XNonce, which is included in the AC's authenticated Join Reply's encrypted ANonce message element, allowing for the two messages to be bound. Upon receipt of the Join Reply, the WTP generates the WNonce, and generates a set of session keys using a KDF function. One of these keys is used to MIC the Join ACK. The AC responds with a Join Confirm, which must also include a MIC, and therefore be capable of deriving the same set of session keys.
結合要求のリプレイ保護は、参加（またはキーアップデート）フェーズ中のNoncesの交換を通じて処理されます。Join Requestには、ACの認証されたJoin Replyの暗号化されたAnonceメッセージ要素に含まれるXnonceが含まれており、2つのメッセージをバインドできます。結合返信を受信すると、WTPはWNONCEを生成し、KDF関数を使用してセッションキーのセットを生成します。これらのキーの1つは、結合ACKをマイクするために使用されます。ACは、マイクも含める必要があるJoin Confismで応答し、したがって同じセッションキーのセットを導出することができます。
In both the X.509 certificate and pre-shared key modes, an initialization vector is created through the above mentioned KDF function. The IV and the KDF created encryption key are used to encrypt the LWAPP control frames.
X.509証明書と事前共有キーモードの両方で、上記のKDF関数を介して初期化ベクトルが作成されます。IVとKDF作成された暗号化キーは、LWAPPコントロールフレームを暗号化するために使用されます。
Given that authentication in the Join exchange does not occur until the WTP transmits the Join ACK message, it is crucial that an AC not delete any state for a WTP it is servicing until an authentication Join ACK has been received. Otherwise, a potential Denial-of-Service attack exists, whereby sending a spoofed Join Request for a valid WTP would cause the AC to reset the WTP's connection.
Join Exchangeでの認証は、WTPがJoin ACKメッセージを送信するまで発生しないことを考えると、ACがACKを受信するまで保証するWTPの状態を削除しないことが重要です。それ以外の場合、潜在的なサービス拒否攻撃が存在します。これにより、有効なWTPのスプーフィングされた参加要求を送信すると、ACはWTPの接続をリセットします。
It is important to note that Perfect Forward Secrecy is not a requirement for the LWAPP protocol.
完全なフォワードの秘密はLWAPPプロトコルの要件ではないことに注意することが重要です。
Note that the LWAPP protocol does not add any new vulnerabilities to 802.11 infrastructure that makes use of WEP for encryption purposes. However, implementors SHOULD discourage the use of WEP to allow the market to move towards technically sound cryptographic solutions, such as 802.11i.
LWAPPプロトコルは、暗号化目的でWEPを使用する802.11インフラストラクチャに新しい脆弱性を追加しないことに注意してください。ただし、実装者は、WEPの使用を阻止して、市場が802.11iなどの技術的に健全な暗号化ソリューションに向かって移動できるようにする必要があります。
LWAPP uses public key cryptography to ensure trust between the WTP and the AC. One question that periodically arises is why the Join Request is not signed. Signing this request would not be optimal for the following reasons:
LWAPPは、公開キーの暗号化を使用して、WTPとACの間の信頼を確保しています。定期的に発生する質問の1つは、参加要求に署名されない理由です。このリクエストに署名することは、次の理由で最適ではありません。
1. The Join Request is replayable, so a signature doesn't provide much protection unless the switches keep track of all previous Join Requests from a given WTP.
1. 結合リクエストは再生可能であるため、特定のWTPからの以前のすべての参加要求をスイッチが追跡しない限り、署名はあまり保護されません。
2. Replay detection is handled during the Join Reply and Join ACK messages.
2. リプレイ検出は、結合返信中に処理され、ACKメッセージに参加します。
3. A signed Join Request provides a potential Denial-of-Service attack on the AC, which would have to authenticate each (potentially malicious) message.
3. 署名された参加要求は、ACに対するサービス拒否攻撃の可能性を提供します。これは、それぞれ（潜在的に悪意のある）メッセージを認証する必要があります。
The WTP-Certificate that is included in the Join Request MUST be validated by the AC. It is also good practice that the AC perform some form of authorization, ensuring that the WTP in question is allowed to establish an LWAPP session with it.
参加要求に含まれるWTP認証は、ACによって検証する必要があります。また、ACが何らかの形の承認を実行し、問題のWTPがLWAPPセッションを確立できるようにすることをお勧めします。
Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an attacker to perform a brute-force or dictionary attack to recover the secret.
限られたエントロピーの固定共有秘密（たとえば、比較的短い、または人間によって選択されたため、その長さが示すよりも少ないエントロピーを含む可能性がある）の使用により、攻撃者がブルートフォースまたは辞書を実行できる場合があります秘密を回復するための攻撃。
It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a functionality for generating a new random PSK, taking RFC 1750 [4] into account.
管理者がPSKを手動で構成できるようにする実装は、RFC 1750 [4]を考慮に入れて、新しいランダムPSKを生成する機能を提供することをお勧めします。
Since the key generation does not expose the nonces in plaintext, there are no practical passive attacks possible.
キージェネレーションはプレーンテキストで非速度を公開しないため、実用的なパッシブ攻撃はありません。
The authors wish to thank Michael Vakulenko for contributing text that describes how LWAPP can be used over a Layer 3 (IP) network.
著者は、layer 3（IP）ネットワークでLWAPPを使用する方法を説明するテキストを貢献してくれたMichael Vakulenkoに感謝します。
The authors would also like to thanks Russ Housley and Charles Clancy for their assistance in providing a security review of the LWAPP specification. Charles' review can be found in [12].
著者はまた、LWAPP仕様のセキュリティレビューを提供する際の支援について、Russ HousleyとCharles Clancyに感謝したいと思います。チャールズのレビューは[12]にあります。
[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] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[2] 国立標準技術研究所、「Advanced Encryption Standard（AES）」、Fips Pub 197、2001年11月、<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>。
[3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[3] ホワイティング、D。、ハウスリー、R。、およびN.ファーガソン、「CBC-MAC（CCM）とのカウンター」、RFC 3610、2003年9月。
[4] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[4] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[5] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[5] Mather、J.、ed。、およびM. Kojo、ed。、「Mobility関連用語」、RFC 3753、2004年6月。
[6] "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks
- Specific requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications", IEEE
Standard 802.11, 2007,
<http://standards.ieee.org/getieee802/download/802.11-2007.pdf>
[7] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i, July 2004, http://standards.ieee.org/getieee802/download/802.11i-2004.pdf
[7] 「情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理レイヤー（PHY）仕様修正6：中アクセス制御（MAC）セキュリティ強化」」、IEEE Standard 802.11i、2004年7月、http：//standards.ieeee.org/getieee802/download/802.11i-2004.pdf
[8] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982.
[8] クラーク、D。、「IPデータグラム再組み立てアルゴリズム」、RFC 815、1982年7月。
[9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[9] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Lap Algorithm」、RFC 3394、2002年9月。
[10] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[10] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC5280、2008年5月。
[11] "Netscape-Defined Certificate Extensions", <http://www.redhat.com/docs/manuals/cert-system/admin/7.1/app_ext.html#35336>.
[11] 「netscape-defined証明書拡張機能」、<http://www.redhat.com/docs/manuals/cert-system/admin/7.1/app_ext.html#3536>。
[12] Clancy, C., "Security Review of the Light-Weight Access Point Protocol", May 2005, <http://www.cs.umd.edu/~clancy/docs/lwapp-review.pdf>.
[12] Clancy、C。、「Light-Weight Access Point Protocolのセキュリティレビュー」、2005年5月、<http://www.cs.umd.edu/~clancy/docs/lwapp-review.pdf>。
[13] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[13] Reynolds、J.、ed。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[15] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[15] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[16] "WiFi Protected Access (WPA) rev 1.6", April 2003.
[16] 「WiFi Protected Access（WPA）Rev 1.6」、2003年4月。
Authors' Addresses
著者のアドレス
Pat R. Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5269 EMail: pcalhoun@cisco.com
PAT R. Calhoun Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134電話：1 408-853-5269メール：pcalhoun@cisco.com
Rohit Suri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5548 EMail: rsuri@cisco.com
Rohit Suri Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134電話：1 408-853-5548メール：rsuri@cisco.com
Nancy Cam-Winget Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-0532 EMail: ncamwing@cisco.com
Nancy Cam-Winget Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134電話：1 408-853-0532メール：ncamwing@cisco.com
Scott Kelly EMail: scott@hyperthought.com
Scott Kellyメール：scott@hyperthought.com
Michael Glenn Williams GWhiz Arts & Sciences 1560 Newbury Road, Suite 1-204 Newbury Park, CA 91320 Phone: +1 805-499-1994 EMail: gwhiz@gwhiz.com
マイケルグレンウィリアムズGWHIZ ARTS＆SCIENCES 1560 Newbury Road、Suite 1-204 Newbury Park、CA 91320電話：1 805-499-1994メール：gwhiz@gwhiz.com
Sue Hares Phone: +1 734-604-0332 EMail: shares@ndzh.com
Sue Hares電話：1 734-604-0332メール：shares@ndzh.com
Bob O'Hara EMail: bob.ohara@computer.org
ボブ・オハラメール：bob.ohara@computer.org