RFC 5412
Lightweight Access Point Protocol
3. LWAPP Transport Layers
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.
3.1. LWAPP Transport Header
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. 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1.1. VER Field
A 2-bit field that contains the version of LWAPP used in this packet. The value for this document is 0.3.1.2. RID Field
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.3.1.3. C Bit
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.3.1.4. F Bit
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.
3.1.5. L Bit
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.3.1.6. Fragment ID
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.3.1.7. Length
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).3.1.8. Status and WLANS
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.3.1.9. Payload
This field contains the header for an LWAPP data message or LWAPP control message, followed by the data associated with that message.3.2. Using IEEE 802.3 MAC as LWAPP Transport
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.
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 ... |
+----------------------+
3.2.1. Framing
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.
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.
Ethertype
The Ethertype field is set to 0x88bb.
3.2.2. AC Discovery
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.
3.2.3. LWAPP Message Header Format over IEEE 802.3 MAC Transport
All of the fields described in Section 3.1 are used when LWAPP uses
the IEEE 802.3 MAC transport.
3.2.4. Fragmentation/Reassembly
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.3.2.5. Multiplexing
LWAPP control messages and data messages are distinguished by the 'C' bit in the LWAPP message header.3.3. Using IP/UDP as LWAPP Transport
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. 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 ... | +-----------------+----------------------+3.3.1. Framing
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.
3.3.2. AC Discovery
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. 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. Whether the WTP uses a limited IP broadcast, multicast or unicast IP address is implementation-dependent. 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: 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". DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to one or more AC addresses.3.3.3. LWAPP Message Header Format over IP/UDP Transport
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.3.3.1. F Bit
This flag field is not used with this transport, and MUST be set to zero.3.3.3.2. L Bit
This flag field is not used with this transport, and MUST be set to zero.
3.3.3.3. Frag ID
This field is not used with this transport, and MUST be set to zero.3.3.4. Fragmentation/Reassembly for IPv4
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.3.3.5. Fragmentation/Reassembly for IPv6
IPv6 does MTU discovery so fragmentation and re-assembly is not necessary for UDP packets.3.3.6. Multiplexing
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. 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). 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. 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.4. LWAPP Packet Definitions
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.
Transport details can be found in Section 3.4.1. LWAPP Data Messages
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. 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. The actual format of the encapsulated LWAPP data frame is subject to the rules defined under the specific wireless technology binding.4.2. LWAPP Control Messages Overview
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: Discovery: LWAPP Discovery messages are used to identify potential ACs, their load and capabilities. 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 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. Mobile Session Management: Mobile Session Management messages are used by the AC to push specific mobile policies to the WTP. Firmware Management: Messages in this category are used by the AC to push a new firmware image down to the WTP. Control Channel, WTP Configuration, and Mobile Session Management MUST be implemented. Firmware Management MAY be implemented. In addition, technology-specific bindings may introduce new control channel commands that depart from the above list.
4.2.1. Control Message Format
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: 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] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.2.1.1. Message Type
The Message Type field identifies the function of the LWAPP control message. The valid values for a Message Type are the following: 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
4.2.1.2. Sequence Number
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.
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.
4.2.1.3. Message Element Length
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).
4.2.1.4. Session ID
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.
4.2.1.5. Message Element [0..N]
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.
4.2.2. Message Element Format
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.
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.
The format of a message element uses the TLV format shown here:
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.
4.2.2.1. Generic Message Elements
This section includes message elements that are not bound to a
specific control message.
4.2.2.1.1. Vendor Specific
The Vendor-Specific Payload is used to communicate vendor-specific
information between the WTP and the AC. The value contains the
following format:
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
Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA-assigned "SMI
Network Management Private Enterprise Codes" [13].
Element ID: A 16-bit Element Identifier that is managed by the
vendor.
Value: The value associated with the vendor-specific element.
4.2.3. Quality of Service
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:
802.1P: The precedence value of 7 SHOULD be used.
DSCP: The Differentiated Services Code Point (DSCP) tag value of 46
SHOULD be used.
5. LWAPP Discovery Operations
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.
5.1. Discovery Request
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.
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.
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.
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. 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. 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. The following subsections define the message elements that MUST be included in this LWAPP operation.5.1.1. Discovery Type
The Discovery message element is used to configure a WTP to operate in a specific mode. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Discovery Type| +-+-+-+-+-+-+-+-+ Type: 58 for Discovery Type Length: 1 Discovery Type: An 8-bit value indicating how the AC was discovered. The following values are supported: 0 - Broadcast 1 - Configured
5.1.2. WTP Descriptor
The WTP Descriptor message element is used by the WTP to communicate its current hardware/firmware configuration. The value contains the following fields. 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 Length: 16 Hardware Version: A 32-bit integer representing the WTP's hardware version number. Software Version: A 32-bit integer representing the WTP's Firmware version number. Boot Version: A 32-bit integer representing the WTP's boot loader's version number. Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the RID field) supported by the WTP. Radios in Use: An 8-bit value representing the number of radios present in the WTP. 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.
5.1.3. WTP Radio Information
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. The value contains two fields, as shown: 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 Length: 2 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP. Radio Type: The type of radio present. The following values are supported: 1 - 802.11bg: An 802.11bg radio. 2 - 802.11a: An 802.11a radio. 3 - 802.16: An 802.16 radio. 4 - Ultra Wideband: A UWB radio. 7 - all: Used to specify all radios in the WTP.5.2. Discovery Response
The Discovery Response is a mechanism by which an AC advertises its services to requesting WTPs. Discovery Responses are sent by an AC after receiving a Discovery Request.
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. The following subsections define the message elements that MUST be included in this LWAPP operation.5.2.1. AC Address
The AC Address message element is used to communicate the identity of the AC. The value contains two fields, as shown: 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 Length: 7 Reserved: MUST be set to zero MAC Address: The MAC address of the AC5.2.2. AC Descriptor
The AC Descriptor message element is used by the AC to communicate its current state. The value contains the following fields: 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
Length: 17
Reserved: MUST be set to zero
Hardware Version: A 32-bit integer representing the AC's hardware
version number.
Software Version: A 32-bit integer representing the AC's Firmware
version number.
Stations: A 16-bit integer representing the number of mobile
stations currently associated with the AC.
Limit: A 16-bit integer representing the maximum number of stations
supported by the AC.
Radios: A 16-bit integer representing the number of WTPs currently
attached to the AC.
Max Radio: A 16-bit integer representing the maximum number of WTPs
supported by the AC.
Security: An 8-bit bitmask specifying the security schemes
supported by the AC. The following values are supported (see
Section 10):
1 - X.509 Certificate-Based
2 - Pre-Shared Secret
5.2.3. AC Name
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.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Type: 31 for AC Name
Length: > 0
Name: A variable-length ASCII string containing the AC's name.5.2.4. WTP Manager Control IPv4 Address
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. 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 Length: 6 IP Address: The IP address of an interface. WTP Count: The number of WTPs currently connected to the interface.5.2.5. WTP Manager Control IPv6 Address
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. 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 Length: 6 IP Address: The IP address of an interface. WTP Count: The number of WTPs currently connected to the interface.5.3. Primary Discovery Request
The Primary Discovery Request is sent by the WTP in order to determine whether its preferred (or primary) AC is available. 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. The frequency of the Primary Discovery Requests should be no more often than the sending of the Echo Request message. 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. The following subsections define the message elements that MUST be included in this LWAPP operation.5.3.1. Discovery Type
The Discovery Type message element is defined in Section 5.1.1.5.3.2. WTP Descriptor
The WTP Descriptor message element is defined in Section 5.1.2.5.3.3. WTP Radio Information
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.5.4. Primary Discovery Response
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.
Primary Discovery Responses are sent by an AC after receiving a Primary Discovery Request. 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. The following subsections define the message elements that MUST be included in this LWAPP operation.5.4.1. AC Descriptor
The Discovery Type message element is defined in Section 5.2.2.5.4.2. AC Name
The AC Name message element is defined in Section 5.2.3.5.4.3. WTP Manager Control IPv4 Address
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.5.4.4. WTP Manager Control IPv6 Address
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.
(page 39 continued on part 3)
