Capwap study notes--initial knowledge of Capwap (IV.)

2.5.7 Capwap transmission mechanism

The standard UDP client/server model is used to establish communication between WTP and AC.

The CAPWAP protocol supports UDP and Udp-lite [RFC3828].

¢ on IPV4, the Capwap control and data channels use UDP. At this point the UDP checksum in the CAPWAP message must be set to 0. The Capwap control report on AC Wen Duankou is known as UDP port 5246, datagram Wen Duankou is known as UDP port 5247, and WTP can choose Capwap Control and data port at will.

¢ on IPV6, the Capwap control channel generally uses UDP, and the data channel can use UDP or udp-lite. The udp-lite is the default data channel transport protocol. When using the Udp-lite protocol, the checksum must be 8. The port used by the Udp-lite is consistent with UDP.

2.5.8 Shard, reassembly, MTU Discovery

The CAPWAP protocol provides the allocation and reorganization of IP packets on the application layer, and because of the tunneling mechanism, the transmission medium in the middle of message fragmentation is transparent. The CAPWAP protocol can therefore be used on any network architecture (firewalls, NAT, etc.).

Capwap implementation of the Shard mechanism is also limited and insufficient, the protocol RFC4963 described in detail.

Capwap performs MTU discovery to avoid sharding.

Once the WTP discovers AC and wants to establish a capwap session with this AC, it must perform a path MTU (PMTU) discovery. IPV4 's PMTU discovery process is described in detail in RFC1191. IPv6 use RFC4821.

2.5.9 Message Format

The CAPWAP protocol reliability mechanism requires that messages must be paired, consisting of requests and responses. All request messages have an odd message type value, and all response message type values are even.

If the WTP or AC receives a message that is not known, the message type is odd, then the message type value is added one and then responds to the sender, with the "message type not known" element in the response. If you do not know the message type is even, then this message will be ignored.

A brief introduction to the 2.5.9.1 Udp-lite protocol

The Udp-lite protocol is more adaptable to the network error rate, but it is not sensitive to minor errors, such as the playback of real-time video.

So how does it differ from the traditional UDP protocol?

The traditional UDP protocol is a complete verification of its payload (Payload), if some of the bits (even if only one) has changed, then the entire packet can be discarded, in some cases, the cost of losing this package is very large, especially when the package is relatively large.

In the Udp-lite protocol, it is necessary for a packet to verify its payload, or to verify how many bits are controlled by the user, and the Udp-lite protocol is to represent its checksum coverage with the length field of the UDP protocol. So when the checksum coverage field of the Udp-lite protocol equals the length of the entire UDP packet (including UDP headers and loads), the Udp-lite-generated package will be identical to the traditional UDP packet. In fact, Linux supports the Udp-lite protocol by adding a setsockopt option on top of the original UDP protocol to control the transmission and acceptance of the checksum coverage.

Brief introduction of 2.5.9.2 Capwap message

The Capwap control protocol includes two messages that will never be DTLS protected: Discovery request and Discovery Response.

The message format is as follows:

The remaining Capwap control protocol messages must be encrypted by the DTLS protocol and therefore include a capwap DTLS Header.

The CAPWAP protocol DTLS encryption of data packets is optional.

Capwap Header Format:

¢UDP Header: All CAPWAP messages are encapsulated in UDP or Udp-lite (IPv6).

¢capwap DTLS: All DTLS encrypted CAPWAP messages have this header prefix.

¢DTLS Head: DTLS head provides authentication and encryption services for CAPWAP loads. DTLS is defined in the RFC4347.

¢capwap Head: All CAPWAP protocol messages are in the same header, which is located after the Capwap pre-code or DTLS header.

¢ Wireless Load: The CAPWAP protocol message that contains the wireless payload is called a CAPWAP data message. The CAPWAP protocol does not impose a requirement on the format of the wireless payload, but is determined by the wireless protocol standard.

¢ Control head: The CAPWAP protocol contains a signal element called the Capwap control protocol. All Capwap control messages contain a control head, and the CAPWAP data message does not contain the header.

¢ Message element: The Capwap control message contains one or more message elements, which follow the element after the control header. These message elements appear in TLV format (type/length/value)

2.5.9.2.1 Pre-judgment code

The first 8 bits of the 2 CAPWAP headers are pre-determined to quickly determine if the message has been DTLS encrypted. The first 4 bits indicate the CAPWAP version, the current version number is 0, and the last 4-bit value is 1 o'clock is the CAPWAP DTLS header, and the value 0 o'clock is the CAPWAP header.

0

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

| version| Type |

2.5.9.2.2 CAPWAP DTLS Header

This message is identified by DTLS encryption. The length is 32 bits, including 8-bit pre-judgement code and 24-bit reserve code.

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 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.5.9.2.3 CAPWAP Header

All messages in the CAPWAP protocol contain the CAPWAP header, the control message is received in the control channel, and the data message is received in the data channel.

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 .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The pieces of the message are composed as follows:

(1) CAPWAP preamble:8-bit pre-judgment code.

(2) Hlen:5, indicating the length of the first CAPWAP.

(3) The Rid:5-bit radio frequency identifier that indicates the source of this message.

(4) Wbid:5-bit wireless frame identifier, indicating the type of wireless frame, with IEEE802.11, IEEE802.16 and EPCGlobal 3 kinds.

(5) T: 1-bit data frame identifier, a value of 1 o'clock the data frame is a type indicated by Wbid, and a value of 0 o'clock is the IEEE802.3 data frame.

(6) F:1-bit grouping flag with a value of 1 o'clock this message is a CAPWAP packet that needs to be reorganized into a complete message with other groupings.

(7) L: 1-bit end-of-packet flag with a value of 1 o'clock this message is the last packet.

(8) The w:1-bit option flag with a value of 1 o'clock exists Wireless specific information option.

(9) The m:1-bit option flag with a value of 1 o'clock exists for the Radio MAC address option.

(10) K:1-bit survival flag indicating that this message is used to keep the connection alive and cannot carry user data.

(11) Flags:3 bit reserved flag.

(12) Fragment id:16 bit group identifier, identify different packet groupings, the same ID packet belongs to the same CAPWAP message.

(13) Fragment the position of the offset:13 bit group displacement, each grouping in the CAPWAP message.

(14) Reserved:3 bit Reserve code.

(15) Radio mac ADDRESS:32-bit radio-frequency MAC address, less than 32 bits with full 0 padding. Specifies the MAC address of the radio frequency of the message source.

(16) Wireless specific INFORMATION:32 bit special wireless information, less than 32 bits with full 0 padding. Contains special information, such as association with IEEE 802.11, IEEE802.16, and EPCGlobal.

(17) Payload: The data message is the user data, the control message is the control messages, the detailed control message definition see the literature [1].

2.5.9.3CAPWAP Data messages

There are two types of CAPWAP data messages: The CAPWAP data channel keep-alive message and the data payload message. The CAPWAP data hannel keep-alive message is used to synchronize the control and data channels to maintain the connection of the channel. Data payload messages are used to transfer user data between AC and WTP.

2.5.9.3.1 CAPWAP Data Channel keep-alive

The purpose of this message is to maintain the availability of the channel. When the datachannelkeepalive timer expires, the WTP sends the message and sets the Datachanneldeadinterval timer.

In the message, in addition to the Heln field and the K flag bit, the remaining fields and flag bits are set to 0. When the keepalive message is received, AC will respond to a keepalive message to the WTP.

WTP cancels the Datachanneldeadinterval timer and resets the datachannelkeepalive timer after receiving the keepalive message of the AC response. The WTP then re-sends the KeepAlive messages as control messages. If the AC response message is still not received when the Datachanneldeadinterval timer expires, the WTP will delete the Dtls control session and delete it if there is a data session.

The keepalive message format 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Message Element Length | Message Element [0..N] ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The message is encapsulated in the payload field of the CAPWAP message.

The Message Element length:16bit the Length field, up to 65535.

Message ELEMENT[0..N]: The keppalive message data that is carried, the Seesion ID must be carried.

2.5.9.3.2 Data Payload

The CAPWAP data payload message encapsulates the user's information that needs to be forwarded, which may be 802.3 frames or wireless data frames, see section 3.2.

Establishment of 2.5.9.3.3 DTLS data channel

If the AC and WTP are configured as DTLS tunnel transfer mode, then the Dtls SESSION must be initialized. To avoid re-authentication, authentication of AC and WTP,DTLS data channels should take advantage of the characteristics of the TLS session.

The AC DTLS implementation should not initialize the data channel session without a control channel.

2.5.9.4 Capwap Control Message

Capwap control messages are divided into the following types:

Discovery: Discovering AC,AC locations and capabilities in the network

JOIN:WTP is used to request service to AC, and AC is used to respond to WTP

Control channel Management: maintaining the controlling channels

The WTP configuration Management:ac sends the config file to the WTP.

Station Session MANAGEMENT:AC Send station strategy to WTP

Device Management Operations: Request and send firmware to WTP

Binding-specific CAPWAP Management Messages:ac and WTP are used to exchange the CAPWAP management information specified by the protocol. May exchange a station's connection status information.

2.5.9.3.1 CAPWAP Discovery Operations

¢discovery Request Message

The WTP uses discovery request to discover the AC available in the network, providing its own basic performance to AC.

¢discovery Response Message

AC uses discovery Response to inform the WTP of the requested service of the services it supports.

¢primary Discovery Request Message

WTP sends primary Discovery request for: Determine if the AC it prefers (or configures) is available or executes a path MTU Discovery

¢primary Discovery Response

AC uses primary Discovery response tells the WTP that they are currently available, with support services.

When the WTP is configured with a preferred AC, but is now connected to another AC, the primary Discovery request is sent. Since the WTP has only one Capwap state machine, the WTP sends primary in the run state Discovery REQUEST,AC does not transmit this message

2.5.9.3.2 CAPWAP Join Operations

¢join Request

After establishing a DTLS connection with AC, the WTP uses the join request to service an AC

¢join Response

AC uses the join response to inform the WTP whether it will provide services

2.5.9.3.3 Control Channel Management

¢echo Request

¢echo Response

echo Request and echo response are used to explicitly maintain the connection of the control channel when the control message is not sent

2.5.9.3.4 WTP Configuration Management

¢configuration Status Request

WTP is used to send its own current configuration to AC

¢configuration Status Response

AC provides its own configuration data to the WTP, overwriting the configuration requested by the WTP

¢configuration Update Request

Run state, AC is sent to the WTP to modify the configuration on the WTP.

¢configuration Update Response

Responding to configuration Update Request

¢change State Event Request

1: When the WTP receives the configuration status from AC RESPONSE,WTP using the Change state Event request to provide the current status of the WTP radio, verify that the AC provided configurations have been successfully applied

2: In Run, the WTP sends the change state Event request to tell AC,WTP that the unexpected changes occurred in radio.

¢change State Event Response:

Respond to change state Event Request

¢clear Configuration Request:

AC is used to request WTP to restore its own configuration to factory default values

¢clear Configuration Response

After the WTP restores the factory defaults, it sends an acknowledgement to AC.

The CAPWAP protocol provides a resilient WTP configuration management mechanism in two ways:

1:WTP without any configuration, accept any configuration provided by AC

2:WTP Save the configuration data in static memory provided by AC that is not the default value, and then restart the initialization configuration.

2.5.9.3.5 Device Management Operations (optional)

¢image Data Request

Exchange between WTP and AC for WTP to download a new firmware

¢image Data Response

Response to Image Data Response

¢reset Request

Request a WTP restart.

¢reset Response

Responding to the Reset Request

¢WTP Event Request

The WTP is used to send information to AC. The WTP event request may be sent periodically, or as a response to a WTP synchronization event.

¢WTP Event Response

Responding to the WTP Event Request

¢data Transfer Request

Send debug information on the WTP to AC

¢data Transfer Response

Responding to Data Transfer Request

The WTP Event request is a WTP sending some well-defined status information, such as decryption Error report,duplicate IPv4 address, etc., and can also be used to send vendor specific Payload

The Data Transfer request can be sent by AC or by WTP.

2.5.9.3.6 Capwap definition of the firmware download process:

Firmware downloads can occur in the image data state or the run state. The CAPWAP protocol does not provide AC to identify whether the firmware information provided by WTP is correct, or if the WTP correctly stores firmware.

2.5.9.3.7 Station Session Management

¢station Configuration Request

AC used to create, modify, delete staion session state on WTP

¢station Configuration Response

Response Station Configuration Request

——————————————————

Capwap study notes--initial knowledge of Capwap (d) (EXT)