RFC 5415
Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
Pages: 155
Proposed Standard
→ Errata
Obsoletes: 5414
Updated by: 8553 8996
Proposed Standard
→ Errata
Obsoletes: 5414
Updated by: 8553 8996
Part 3 of 6 – Pages 40 to 67
3. CAPWAP Transport
Communication between a WTP and an AC is established using the standard UDP client/server model. The CAPWAP protocol supports both UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, UDP is used for the CAPWAP Control and Data channels. When run over IPv6, the CAPWAP Control channel always uses UDP, while the CAPWAP Data channel may use either UDP or UDP-Lite. UDP-Lite is the default transport protocol for the CAPWAP Data channel. However, if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is used for the CAPWAP Data channel. This section describes how the CAPWAP protocol is carried over IP and UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol message element, Section 4.6.14, describes the rules to use in determining which transport protocol is to be used. In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which they received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port.3.1. UDP Transport
One of the CAPWAP protocol requirements is to allow a WTP to reside behind a middlebox, firewall, and/or Network Address Translation (NAT) device. Since a CAPWAP session is initiated by the WTP (client) to the well-known UDP port of the AC (server), the use of UDP is a logical choice. When CAPWAP is run over IPv4, the UDP checksum field in CAPWAP packets MUST be set to zero. CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP Control channel, as defined in Section 1.4. The CAPWAP control port at the AC is the well-known UDP port 5246. The CAPWAP control port at the WTP can be any port selected by the WTP. CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP Data channel, as defined in Section 1.4. The CAPWAP data port at the AC is the well-known UDP port 5247. If an AC permits the administrator to change the CAPWAP control port, the CAPWAP data port MUST be the next consecutive port number. The CAPWAP data port at the WTP can be any port selected by the WTP.
3.2. UDP-Lite Transport
When CAPWAP is run over IPv6, UDP-Lite is the default transport protocol, which reduces the checksum processing required for each packet (compared to the use of UDP over IPv6 [RFC2460]). When UDP- Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. UDP-Lite uses the same port assignments as UDP.3.3. AC Discovery
The AC Discovery phase allows the WTP to determine which ACs are available and choose the best AC with which to establish a CAPWAP session. The Discovery phase occurs when the WTP enters the optional Discovery state. A WTP does not need to complete the AC Discovery phase if it uses a pre-configured AC. This section details the mechanism used by a WTP to dynamically discover candidate ACs. A WTP and an AC will frequently not reside in the same IP subnet (broadcast domain). When this occurs, the WTP must be capable of discovering the AC, without requiring that multicast services are enabled in the network. When the WTP attempts to establish communication with an AC, it sends the Discovery Request message and receives the Discovery Response message from the AC(s). The WTP MUST send the Discovery Request message to either the limited broadcast IP address (255.255.255.255), the well-known CAPWAP multicast address (224.0.1.140), or to the unicast IP address of the AC. For IPv6 networks, since broadcast does not exist, the use of "All ACs multicast address" (FF0X:0:0:0:0: 0:0:18C) is used instead. Upon receipt of the Discovery Request message, the AC sends a Discovery Response message to the unicast IP address of the WTP, regardless of whether the Discovery Request message was sent as a broadcast, multicast, or unicast message. WTP use of a limited IP broadcast, multicast, or unicast IP address is implementation dependent. ACs, on the other hand, MUST support broadcast, multicast, and unicast discovery. When a WTP transmits a Discovery Request message 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: See [RFC5417] for more information on the use of DHCP to discover AC IP addresses. DNS: The WTP MAY support use of DNS Service Records (SRVs) [RFC2782] to discover the AC address(es). In this case, the WTP first obtains (e.g., from local configuration) the correct domain name suffix (e.g., "example.com") and performs an SRV lookup with Service name "capwap-control" and Proto "udp". Thus, the name resolved in DNS would be, e.g., "_capwap- control._udp.example.com". Note that the SRV record MAY specify a non-default port number for the control channel; the port number for the data channel is the next port number (control channel port + 1). An AC MAY also communicate alternative ACs to the WTP within the Discovery Response message through the AC IPv4 List (see Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses provided in these two message elements are intended to help the WTP discover additional ACs through means other than those listed above. The AC Name with Priority message element (see Section 4.6.5) is used to communicate a list of preferred ACs to the WTP. The WTP SHOULD attempt to utilize the ACs listed in the order provided by the AC. The Name-to-IP Address mapping is handled via the Discovery message exchange, in which the ACs provide their identity in the AC Name (see Section 4.6.4) message element in the Discovery Response message. Once the WTP has received Discovery Response messages from the candidate ACs, it MAY use other factors to determine the preferred AC. For instance, each binding defines a WTP Radio Information message element (see Section 2.1), which the AC includes in Discovery Response messages. The presence of one or more of these message elements is used to identify the CAPWAP bindings supported by the AC. A WTP MAY connect to an AC based on the supported bindings advertised.3.4. Fragmentation/Reassembly
While fragmentation and reassembly services are provided by IP, the CAPWAP protocol also provides such services. Environments where the CAPWAP protocol is used involve firewall, NAT, and "middlebox" devices, which tend to drop IP fragments to minimize possible DoS attacks. By providing fragmentation and reassembly at the application layer, any fragmentation required due to the tunneling component of the CAPWAP protocol becomes transparent to these intermediate devices. Consequently, the CAPWAP protocol can be used in any network topology including firewall, NAT, and middlebox devices.
It is important to note that the fragmentation mechanism employed by CAPWAP has known limitations and deficiencies, which are similar to those described in [RFC4963]. The limited size of the Fragment ID field (see Section 4.3) can cause wrapping of the field, and hence cause fragments from different datagrams to be incorrectly spliced together (known as "mis-associated"). For example, a 100Mpbs link with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause the Fragment ID field wrap in 8 seconds. Consequently, CAPWAP implementers are warned to properly size their buffers for reassembly purposes based on the expected wireless technology throughput. CAPWAP implementations SHOULD perform MTU Discovery (see Section 3.5), which can avoid the need for fragmentation. At the time of writing of this specification, most enterprise switching and routing infrastructure were capable of supporting "mini-jumbo" frames (1800 bytes), which eliminates the need for fragmentation (assuming the station's MTU is 1500 bytes). The need for fragmentation typically continues to exist when the WTP communicates with the AC over a Wide Area Network (WAN). Therefore, future versions of the CAPWAP protocol SHOULD consider either increasing the size of the Fragment ID field or providing alternative extensions.3.5. MTU Discovery
Once a WTP has discovered the AC with which it wishes to establish a CAPWAP session, it SHOULD perform a Path MTU (PMTU) discovery. One recommendation for performing PMTU discovery is to have the WTP transmit Discovery Request (see Section 5.1) messages, and include the MTU Discovery Padding message element (see Section 4.6.32). The actual procedures used for PMTU discovery are described in [RFC1191] for IPv4; for IPv6, [RFC1981] SHOULD be used. Alternatively, implementers MAY use the procedures defined in [RFC4821]. The WTP SHOULD also periodically re-evaluate the PMTU using the guidelines provided in these two RFCs, using the Primary Discovery Request (see Section 5.3) along with the MTU Discovery Padding message element (see Section 4.6.32). When the MTU is initially known, or updated in the case where an existing session already exists, the discovered PMTU is used to configure the DTLS component (see Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit the MTU, defined in Section 3.4.4. CAPWAP Packet Formats
This section contains the CAPWAP protocol packet formats. A CAPWAP protocol packet consists of one or more CAPWAP Transport Layer packet headers followed by a CAPWAP message. The CAPWAP message can be either of type Control or Data, where Control packets carry
signaling, and Data packets carry user payloads. The CAPWAP frame
formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP
Data and Control packets are defined below.
The CAPWAP Control protocol includes two messages that are never
protected by DTLS: the Discovery Request message and the Discovery
Response message. These messages need to be in the clear to allow
the CAPWAP protocol to properly identify and process them. The
format of these packets are as follows:
CAPWAP Control Packet (Discovery Request/Response):
+-------------------------------------------+
| IP | UDP | CAPWAP | Control | Message |
| Hdr | Hdr | Header | Header | Element(s) |
+-------------------------------------------+
All other CAPWAP Control protocol messages MUST be protected via the
DTLS protocol, which ensures that the packets are both authenticated
and encrypted. These packets include the CAPWAP DTLS Header, which
is described in Section 4.2. The format of these packets is as
follows:
CAPWAP Control Packet (DTLS Security Required):
+------------------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr |
+------------------------------------------------------------------+
\---------- authenticated -----------/
\------------- encrypted ------------/
The CAPWAP protocol allows optional protection of data packets, using
DTLS. Use of data packet protection is determined by AC policy.
When DTLS is utilized, the optional CAPWAP DTLS Header is present,
which is described in Section 4.2. The format of CAPWAP Data packets
is shown below:
CAPWAP Plain Text Data Packet :
+-------------------------------+
| IP | UDP | CAPWAP | Wireless |
| Hdr | Hdr | Header | Payload |
+-------------------------------+
DTLS Secured CAPWAP Data Packet:
+--------------------------------------------------------+
| IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
| Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr |
+--------------------------------------------------------+
\------ authenticated -----/
\------- encrypted --------/
UDP Header: All CAPWAP packets are encapsulated within either UDP,
or UDP-Lite when used over IPv6. Section 3 defines the specific
UDP or UDP-Lite usage.
CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are
prefixed with the CAPWAP DTLS Header (see Section 4.2).
DTLS Header: The DTLS Header provides authentication and encryption
services to the CAPWAP payload it encapsulates. This protocol is
defined in [RFC4347].
CAPWAP Header: All CAPWAP protocol packets use a common header that
immediately follows the CAPWAP preamble or DTLS Header. The
CAPWAP Header is defined in Section 4.3.
Wireless Payload: A CAPWAP protocol packet that contains a wireless
payload is a CAPWAP Data packet. The CAPWAP protocol does not
specify the format of the wireless payload, which is defined by
the appropriate wireless standard. Additional information is in
Section 4.4.
Control Header: The CAPWAP protocol includes a signaling component,
known as the CAPWAP Control protocol. All CAPWAP Control packets
include a Control Header, which is defined in Section 4.5.1.
CAPWAP Data packets do not contain a Control Header field.
Message Elements: A CAPWAP Control packet includes one or more
message elements, which are found immediately following the
Control Header. These message elements are in a Type/Length/Value
style header, defined in Section 4.6.
A CAPWAP implementation MUST be capable of receiving a reassembled
CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY
indicate that it supports a higher maximum message length, by
including the Maximum Message Length message element, see Section 4.6.31, in the Join Request message or the Join Response message.4.1. CAPWAP Preamble
The CAPWAP preamble is common to all CAPWAP transport headers and is used to identify the header type that immediately follows. The reason for this preamble is to avoid needing to perform byte comparisons in order to guess whether or not the frame is DTLS encrypted. It also provides an extensibility framework that can be used to support additional transport types. The format of the preamble is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Version| Type | +-+-+-+-+-+-+-+-+ Version: A 4-bit field that contains the version of CAPWAP used in this packet. The value for this specification is zero (0). Type: A 4-bit field that specifies the payload type that follows the UDP header. The following values are supported: 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) immediately follows the UDP header. If the packet is received on the CAPWAP Data channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP Data packet. If received on the CAPWAP Control channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP Control packet. If the control packet is not a Discovery Request or Discovery Response packet, the packet MUST be dropped. 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header (and DTLS packet) immediately follows the UDP header (see Section 4.2).4.2. CAPWAP DTLS Header
The CAPWAP DTLS Header is used to identify the packet as a DTLS encrypted packet. The first eight bits include the common CAPWAP Preamble. The remaining 24 bits are padding to ensure 4-byte alignment, and MAY be used in a future version of the protocol. The DTLS packet [RFC4347] always immediately follows this header. The format of the CAPWAP DTLS Header is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The
CAPWAP Preamble's Payload Type field MUST be set to one (1).
Reserved: The 24-bit field is reserved for future use. All
implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support.
4.3. CAPWAP Header
All CAPWAP protocol messages are encapsulated using a common header
format, regardless of the CAPWAP Control or CAPWAP Data transport
used to carry the messages. However, certain flags are not
applicable for a given transport. Refer to the specific transport
section in order to determine which flags are valid.
Note that the optional fields defined in this section MUST be present
in the precise order shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment ID | Frag Offset |Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Radio MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Wireless Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The
CAPWAP Preamble's Payload Type field MUST be set to zero (0). If
the CAPWAP DTLS Header is present, the version number in both
CAPWAP Preambles MUST match. The reason for this duplicate field
is to avoid any possible tampering of the version field in the
preamble that is not encrypted or authenticated.
HLEN: A 5-bit field containing the length of the CAPWAP transport
header in 4-byte words (similar to IP header length). This length
includes the optional headers.
RID: A 5-bit field that contains the Radio ID number for this
packet, whose value is between one (1) and 31. Given that MAC
Addresses are not necessarily unique across physical radios in a
WTP, the Radio Identifier (RID) field is used to indicate with
which physical radio the message is associated.
WBID: A 5-bit field that is the wireless binding identifier. The
identifier will indicate the type of wireless packet associated
with the radio. The following values are defined:
0 - Reserved
1 - IEEE 802.11
2 - Reserved
3 - EPCGlobal [EPCGlobal]
T: The Type 'T' bit indicates the format of the frame being
transported in the payload. When this bit is set to one (1), the
payload has the native frame format indicated by the WBID field.
When this bit is zero (0), the payload is an IEEE 802.3 frame.
F: 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.
L: The 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 WTP and AC. When this bit is one (1), the packet
is the last fragment. When this bit is (zero) 0, the packet is
not the last fragment.
W: The Wireless 'W' bit is used to specify whether the optional
Wireless Specific Information field is present in the header. A
value of one (1) is used to represent the fact that the optional
header is present.
M: The Radio MAC 'M' bit is used to indicate that the Radio MAC
Address optional header is present. This is used to communicate
the MAC address of the receiving radio.
K: The Keep-Alive 'K' bit indicates the packet is a Data Channel
Keep-Alive packet. This packet is used to map the data channel to
the control channel for the specified Session ID and to maintain
freshness of the data channel. The 'K' bit MUST NOT be set for
data packets containing user data.
Flags: A set of reserved bits for future flags in the CAPWAP Header.
All implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support.
Fragment ID: A 16-bit field whose value is assigned to each group of
fragments making up a complete set. The Fragment ID space is
managed individually for each direction 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.
Fragment Offset: A 13-bit field that indicates where in the payload
this fragment belongs during re-assembly. This field is valid
when the 'F' bit is set to 1. The fragment offset is measured in
units of 8 octets (64 bits). The first fragment has offset zero.
Note that the CAPWAP protocol does not allow for overlapping
fragments.
Reserved: The 3-bit field is reserved for future use. All
implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support.
Radio MAC Address: This optional field contains the MAC address of
the radio receiving the packet. Because the native wireless frame
format to IEEE 802.3 format causes the MAC address of the WTP's
radio to be lost, this field allows the address to be communicated
to the AC. This field is only present if the 'M' bit is set. The
HLEN field assumes 4-byte alignment, and this field MUST be padded
with zeroes (0x00) if it is not 4-byte aligned.
The field contains the basic 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The length of the MAC address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The MAC address of the receiving radio.
Wireless Specific Information: This optional field contains
technology-specific information that may be used to carry per-
packet wireless information. This field is only present if the
'W' bit is set. The WBID field in the CAPWAP Header is used to
identify the format of the Wireless-Specific Information optional
field. The HLEN field assumes 4-byte alignment, and this field
MUST be padded with zeroes (0x00) if it is not 4-byte aligned.
The Wireless-Specific Information field uses 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: The 8-bit field contains the length of the data field,
with a maximum size of 255.
Data: Wireless-specific information, defined by the wireless-
specific binding specified in the CAPWAP Header's WBID field.
Payload: This field contains the header for a CAPWAP Data Message or
CAPWAP Control Message, followed by the data contained in the
message.
4.4. CAPWAP Data Messages
There are two different types of CAPWAP Data packets: CAPWAP Data
Channel Keep-Alive packets and Data Payload packets. The first is
used by the WTP to synchronize the control and data channels and to
maintain freshness of the data channel. The second is used to
transmit user payloads between the AC and WTP. This section
describes both types of CAPWAP Data packet formats.
Both CAPWAP Data messages are transmitted on the CAPWAP Data channel.4.4.1. CAPWAP Data Channel Keep-Alive
The CAPWAP Data Channel Keep-Alive packet is used to bind the CAPWAP control channel with the data channel, and to maintain freshness of the data channel, ensuring that the channel is still functioning. The CAPWAP Data Channel Keep-Alive packet is transmitted by the WTP when the DataChannelKeepAlive timer expires (see Section 4.7.2). When the CAPWAP Data Channel Keep-Alive packet is transmitted, the WTP sets the DataChannelDeadInterval timer. In the CAPWAP Data Channel Keep-Alive packet, all of the fields in the CAPWAP Header, except the HLEN field and the 'K' bit, are set to zero upon transmission. Upon receiving a CAPWAP Data Channel Keep- Alive packet, the AC transmits a CAPWAP Data Channel Keep-Alive packet back to the WTP. The contents of the transmitted packet are identical to the contents of the received packet. Upon receiving a CAPWAP Data Channel Keep-Alive packet, the WTP cancels the DataChannelDeadInterval timer and resets the DataChannelKeepAlive timer. The CAPWAP Data Channel Keep-Alive packet is retransmitted by the WTP in the same manner as the CAPWAP Control messages. If the DataChannelDeadInterval timer expires, the WTP tears down the control DTLS session, and the data DTLS session if one existed. The CAPWAP Data Channel Keep-Alive packet contains the following payload immediately following the CAPWAP Header (see Section 4.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Length | Message Element [0..N] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Element Length: The 16-bit Length field indicates the number of bytes following the CAPWAP Header, with a maximum size of 65535. Message Element[0..N]: The message element(s) carry the information pertinent to each of the CAPWAP Data Channel Keep-Alive message. The following message elements MUST be present in this CAPWAP message: Session ID, see Section 4.6.37.
4.4.2. Data Payload
A CAPWAP protocol Data Payload packet encapsulates a forwarded wireless frame. The CAPWAP protocol defines two different modes of encapsulation: IEEE 802.3 and native wireless. IEEE 802.3 encapsulation requires that for 802.11 frames, the 802.11 *Integration* function be performed in the WTP. An IEEE 802.3- encapsulated user payload frame has the following format: +------------------------------------------------------+ | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | +------------------------------------------------------+ The CAPWAP protocol also defines the native wireless encapsulation mode. The format of the encapsulated CAPWAP Data frame is subject to the rules defined by the specific wireless technology binding. Each wireless technology binding MUST contain a section entitled "Payload Encapsulation", which defines the format of the wireless payload that is encapsulated within CAPWAP Data packets. For 802.3 payload frames, the 802.3 frame is encapsulated (excluding the IEEE 802.3 Preamble, Start Frame Delimiter (SFD), and Frame Check Sequence (FCS) fields). If the encapsulated frame would exceed the transport layer's MTU, the sender is responsible for the fragmentation of the frame, as specified in Section 3.4. The CAPWAP protocol can support IEEE 802.3 frames whose length is defined in the IEEE 802.3as specification [FRAME-EXT].4.4.3. Establishment of a DTLS Data Channel
If the AC and WTP are configured to tunnel the data channel over DTLS, the proper DTLS session must be initiated. To avoid having to reauthenticate and reauthorize an AC and WTP, the DTLS data channel SHOULD be initiated using the TLS session resumption feature [RFC5246]. The AC DTLS implementation MUST NOT initiate a data channel session for a DTLS session for which there is no active control channel session.4.5. CAPWAP Control Messages
The CAPWAP Control protocol provides a control channel between the WTP and the AC. Control messages are divided into the following message types: Discovery: CAPWAP Discovery messages are used to identify potential ACs, their load and capabilities.
Join: CAPWAP Join messages are used by a WTP to request service from
an AC, and for the AC to respond to the WTP.
Control Channel Management: CAPWAP Control channel management
messages are used to maintain the control channel.
WTP Configuration Management: The WTP Configuration messages are
used by the AC to deliver a specific configuration to the WTP.
Messages that retrieve statistics from a WTP are also included in
WTP Configuration Management.
Station Session Management: Station Session Management messages are
used by the AC to deliver specific station policies to the WTP.
Device Management Operations: Device management operations are used
to request and deliver a firmware image to the WTP.
Binding-Specific CAPWAP Management Messages: Messages in this
category are used by the AC and the WTP to exchange protocol-
specific CAPWAP management messages. These messages may or may
not be used to change the link state of a station.
Discovery, Join, Control Channel Management, WTP Configuration
Management, and Station Session Management CAPWAP Control messages
MUST be implemented. Device Management Operations messages MAY be
implemented.
CAPWAP Control messages sent from the WTP to the AC indicate that the
WTP is operational, providing an implicit keep-alive mechanism for
the WTP. The Control Channel Management Echo Request and Echo
Response messages provide an explicit keep-alive mechanism when other
CAPWAP Control messages are not exchanged.
4.5.1. Control Message Format
All CAPWAP Control messages are sent encapsulated within the CAPWAP
Header (see Section 4.3). Immediately following the CAPWAP Header is
the 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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] ...
+-+-+-+-+-+-+-+-+-+-+-+-+
4.5.1.1. Message Type
The Message Type field identifies the function of the CAPWAP Control message. To provide extensibility, the Message Type field is comprised of an IANA Enterprise Number [RFC3232] and an enterprise- specific message type number. The first three octets contain the IANA Enterprise Number in network byte order, with zero used for CAPWAP base protocol (this specification) defined message types. The last octet is the enterprise-specific message type number, which has a range from 0 to 255. The Message Type field is defined as: Message Type = IANA Enterprise Number * 256 + Enterprise Specific Message Type Number The CAPWAP protocol reliability mechanism requires that messages be defined in pairs, consisting of both a Request and a Response message. The Response message MUST acknowledge the Request message. The assignment of CAPWAP Control Message Type Values always occurs in pairs. All Request messages have odd numbered Message Type Values, and all Response messages have even numbered Message Type Values. The Request value MUST be assigned first. As an example, assigning a Message Type Value of 3 for a Request message and 4 for a Response message is valid, while assigning a Message Type Value of 4 for a Response message and 5 for the corresponding Request message is invalid. When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored.
The valid values for CAPWAP Control Message Types are specified in
the table below:
CAPWAP Control Message Message Type
Value
Discovery Request 1
Discovery Response 2
Join Request 3
Join Response 4
Configuration Status Request 5
Configuration Status Response 6
Configuration Update Request 7
Configuration Update Response 8
WTP Event Request 9
WTP Event Response 10
Change State Event Request 11
Change State Event Response 12
Echo Request 13
Echo Response 14
Image Data Request 15
Image Data Response 16
Reset Request 17
Reset Response 18
Primary Discovery Request 19
Primary Discovery Response 20
Data Transfer Request 21
Data Transfer Response 22
Clear Configuration Request 23
Clear Configuration Response 24
Station Configuration Request 25
Station Configuration Response 26
4.5.1.2. Sequence Number
The Sequence Number field is an identifier value used to match
Request and Response packets. When a CAPWAP packet with a Request
Message Type Value is received, the value of the Sequence Number
field is copied into the corresponding Response message.
When a CAPWAP Control message is sent, the sender's internal sequence
number counter is monotonically incremented, ensuring that no two
pending Request messages have the same sequence number. The Sequence
Number field wraps back to zero.
4.5.1.3. Message Element Length
The Length field indicates the number of bytes following the Sequence
Number field.
4.5.1.4. Flags
The Flags field MUST be set to zero.4.5.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. When a WTP or AC receives a CAPWAP message without a message element that is specified as mandatory for the CAPWAP message, then the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Missing Mandatory Message Element" is returned to the sender. When a WTP or AC receives a CAPWAP message with a message element that the WTP or AC does not recognize, the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Unrecognized Message Element" and one or more Returned Message Element message elements is included, containing the unrecognized message element(s).4.5.2. Quality of Service
The CAPWAP base protocol does not provide any Quality of Service (QoS) recommendations for use with the CAPWAP Data messages. Any wireless-specific CAPWAP binding specification that has QoS requirements MUST define the application of QoS to the CAPWAP Data messages. The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. Section 9.1.1 of [RFC3168] describes two levels of ECN functionality: full functionality and limited functionality. CAPWAP ACs and WTPs SHALL implement the limited functionality and are RECOMMENDED to implement the full functionality described in [RFC3168].
4.5.2.1. Applying QoS to CAPWAP Control Message
It is recommended that CAPWAP 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 CAPWAP Control channel disconnects. Therefore, a QoS-enabled CAPWAP device SHOULD use the following values: 802.1Q: The priority tag of 7 SHOULD be used. DSCP: The CS6 per-hop behavior Service Class SHOULD be used, which is described in [RFC2474]).4.5.3. Retransmissions
The CAPWAP Control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1). Response messages are not explicitly acknowledged; therefore, if a Response message is not received, the original Request message is retransmitted. Implementations MUST keep track of the sequence number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same sequence number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message is received, meaning one where the sequence number is smaller, it MUST be ignored. A newer Request message, meaning one whose sequence number is larger, is processed as usual. Note: A sequence number is considered "smaller" when s1 is smaller than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or (s1>s2 and (s1-s2)>128). Both the WTP and the AC can only have a single request outstanding at any given time. Retransmitted Request messages MUST NOT be altered by the sender. After transmitting a Request message, the RetransmitInterval (see Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are used to determine if the original Request message needs to be retransmitted. The RetransmitInterval timer is used the first time the Request is retransmitted. The timer is then doubled every
subsequent time the same Request message is retransmitted, up to MaxRetransmit but no more than half the EchoInterval timer (see Section 4.7.7). Response messages are not subject to these timers. If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new sequence number, and be treated as a new Request message by the receiver. Note that there is a high chance that both the WTP and the AC's sequence numbers will become out of sync. When a Request message is retransmitted, it MUST be re-encrypted via the DTLS stack. If the peer had received the Request message, and the corresponding Response message was lost, it is necessary to ensure that retransmitted Request messages are not identified as replays by the DTLS stack. Similarly, any cached Response messages that are retransmitted as a result of receiving a retransmitted Request message MUST be re-encrypted via DTLS. Duplicate Response messages, identified by the Sequence Number field in the CAPWAP Control message header, SHOULD be discarded upon receipt.4.6. CAPWAP Protocol Message Elements
This section defines the CAPWAP Protocol message elements that are included in CAPWAP protocol control messages. Message elements are used to carry information needed in control messages. Every message element is identified by the Type Value field, defined below. The total length of the message elements is indicated in the message element's length field. All of the message element definitions in this document use a diagram similar to the one below in order to depict its format. Note that to simplify this specification, these diagrams do not include the header fields (Type and Length). The header field values are defined in the message element descriptions.
Unless otherwise specified, a control message that lists a set of supported (or expected) message elements MUST NOT expect the message elements to be in any specific order. The sender MAY include the message elements in any order. Unless otherwise noted, one message element of each type is present in a given control message. Unless otherwise specified, any configuration information sent by the AC to the WTP MAY be saved to non-volatile storage (see Section 8.1) for more information). 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 ... | +-+-+-+-+-+-+-+-+ The 16-bit Type field identifies the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. The value of zero (0) is reserved and MUST NOT be used. The rest of the Type field values are allocated as follows: Usage Type Values CAPWAP Protocol Message Elements 1 - 1023 IEEE 802.11 Message Elements 1024 - 2047 Reserved for Future Use 2048 - 3071 EPCGlobal Message Elements 3072 - 4095 Reserved for Future Use 4096 - 65535 The table below lists the CAPWAP protocol Message Elements and their Type values.
CAPWAP Message Element Type Value AC Descriptor 1 AC IPv4 List 2 AC IPv6 List 3 AC Name 4 AC Name with Priority 5 AC Timestamp 6 Add MAC ACL Entry 7 Add Station 8 Reserved 9 CAPWAP Control IPV4 Address 10 CAPWAP Control IPV6 Address 11 CAPWAP Local IPV4 Address 30 CAPWAP Local IPV6 Address 50 CAPWAP Timers 12 CAPWAP Transport Protocol 51 Data Transfer Data 13 Data Transfer Mode 14 Decryption Error Report 15 Decryption Error Report Period 16 Delete MAC ACL Entry 17 Delete Station 18 Reserved 19 Discovery Type 20 Duplicate IPv4 Address 21 Duplicate IPv6 Address 22 ECN Support 53 Idle Timeout 23 Image Data 24 Image Identifier 25 Image Information 26 Initiate Download 27 Location Data 28 Maximum Message Length 29 MTU Discovery Padding 52 Radio Administrative State 31 Radio Operational State 32 Result Code 33 Returned Message Element 34 Session ID 35 Statistics Timer 36 Vendor Specific Payload 37 WTP Board Data 38 WTP Descriptor 39 WTP Fallback 40 WTP Frame Tunnel Mode 41 Reserved 42
Reserved 43 WTP MAC Type 44 WTP Name 45 Unused/Reserved 46 WTP Radio Statistics 47 WTP Reboot Statistics 48 WTP Static IP Address Information 494.6.1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stations | Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Active WTPs | Max WTPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security | R-MAC Field | Reserved1 | DTLS Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC Information Sub-Element... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 for AC Descriptor Length: >= 12 Stations: The number of stations currently served by the AC Limit: The maximum number of stations supported by the AC Active WTPs: The number of WTPs currently attached to the AC Max WTPs: The maximum number of WTPs supported by the AC Security: An 8-bit mask specifying the authentication credential type supported by the AC (see Section 2.4.4). The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reserved |S|X|R| +-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support.
S: The AC supports the pre-shared secret authentication, as
described in Section 12.6.
X: The AC supports X.509 Certificate authentication, as
described in Section 12.7.
R: A reserved bit for future use. All implementations
complying with this protocol MUST set to zero any bits that
are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not
defined for the version of the protocol they support.
R-MAC Field: The AC supports the optional Radio MAC Address field
in the CAPWAP transport header (see Section 4.3). The following
enumerated values are supported:
0 - Reserved
1 - Supported
2 - Not Supported
Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined
for the version of the protocol they support.
DTLS Policy: The AC communicates its policy on the use of DTLS for
the CAPWAP data channel. The AC MAY communicate more than one
supported option, represented by the bit field below. The WTP
MUST abide by one of the options communicated by AC. The field
has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |D|C|R|
+-+-+-+-+-+-+-+-+
Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support.
D: DTLS-Enabled Data Channel Supported
C: Clear Text Data Channel Supported
R: A reserved bit for future use. All implementations
complying with this protocol MUST set to zero any bits that
are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not
defined for the version of the protocol they support.
AC Information Sub-Element: The AC Descriptor message element
contains multiple AC Information sub-elements, and defines two
sub-types, each of which MUST be present. The AC Information sub-
element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Type | AC Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC Information Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AC Information Vendor Identifier: A 32-bit value containing the
IANA-assigned "Structure of Management Information (SMI)
Network Management Private Enterprise Codes".
AC Information Type: Vendor-specific encoding of AC information
in the UTF-8 format [RFC3629]. The following enumerated values
are supported. Both the Hardware and Software Version sub-
elements MUST be included in the AC Descriptor message element.
The values listed below are used in conjunction with the AC
Information Vendor Identifier field, whose value MUST be set to
zero (0). This field, combined with the AC Information Vendor
Identifier set to a non-zero (0) value, allows vendors to use a
private namespace.
4 - Hardware Version: The AC's hardware version number.
5 - Software Version: The AC's Software (firmware) version
number.
AC Information Length: Length of vendor-specific encoding of AC
information, with a maximum size of 1024.
AC Information Data: Vendor-specific encoding of AC information.
4.6.2. AC IPv4 List
The AC IPv4 List message element is used to configure a WTP with the
latest list of ACs available for the WTP to join.
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: 2 for AC IPv4 List
Length: >= 4
AC IP Address: An array of 32-bit integers containing AC IPv4
Addresses, containing no more than 1024 addresses.
4.6.3. AC IPv6 List
The AC IPv6 List message element is used to configure a WTP with the
latest list of ACs available for the WTP to join.
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: 3 for AC IPV6 List
Length: >= 16
AC IP Address: An array of 128-bit integers containing AC IPv6
Addresses, containing no more than 1024 addresses.
4.6.4. AC Name
The AC Name message element contains an UTF-8 [RFC3629]
representation of the AC 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: 4 for AC Name
Length: >= 1
Name: A variable-length UTF-8 encoded string [RFC3629] containing
the AC's name, whose maximum size MUST NOT exceed 512 bytes.
4.6.5. AC Name with Priority
The AC Name with Priority message element is sent by the AC to the
WTP to configure preferred ACs. The number of instances of this
message element is equal to the number of ACs configured on the WTP.
The WTP also uses this message element to send its configuration to
the AC.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 for AC Name with Priority
Length: >= 2
Priority: A value between 1 and 255 specifying the priority order
of the preferred AC. For instance, the value of one (1) is used
to set the primary AC, the value of two (2) is used to set the
secondary, etc.
AC Name: A variable-length UTF-8 encoded string [RFC3629] containing the AC name, whose maximum size MUST NOT exceed 512 bytes.4.6.6. AC Timestamp
The AC Timestamp message element is sent by the AC to synchronize the WTP clock. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 6 for AC Timestamp Length: 4 Timestamp: The AC's current time, allowing all of the WTPs to be time synchronized in the format defined by Network Time Protocol (NTP) in RFC 1305 [RFC1305]. Only the most significant 32 bits of the NTP time are included in this field.4.6.7. Add MAC ACL Entry
The Add MAC Access Control List (ACL) Entry message element is used by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP no longer provides 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-volatile memory on the WTP. The MAC ACL table on the WTP is cleared every time the WTP establishes a new session with an 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num of Entries| Length | MAC Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 7 for Add MAC ACL Entry Length: >= 8 Num of Entries: The number of instances of the Length/MAC Address fields in the array. This value MUST NOT exceed 255.
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: MAC addresses to add to the ACL.
4.6.8. Add Station
The Add Station message element is used by the AC to inform a WTP
that it should forward traffic for a station. The Add Station
message element is accompanied by technology-specific binding
information element(s), which may include security parameters.
Consequently, the security parameters MUST be applied by the WTP for
the station.
After station policy has been delivered to the WTP through the Add
Station message element, an AC MAY change any policies by sending a
modified Add Station message element. When a WTP receives an Add
Station message element for an existing station, it MUST override any
existing state for the station.
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 | Length | MAC Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Name...
+-+-+-+-+-+-+-+-+
Type: 8 for Add Station
Length: >= 8
Radio ID: An 8-bit value representing the radio, whose value is
between one (1) and 31.
Length: The length of the MAC Address field. The formats and
lengths specified in [EUI-48] and [EUI-64] are supported.
MAC Address: The station's MAC address.
VLAN Name: An optional variable-length UTF-8 encoded string
[RFC3629], with a maximum length of 512 octets, containing the
VLAN Name on which the WTP is to locally bridge user data. Note
this field is only valid with WTPs configured in Local MAC mode.
(next page on part 4)