capwap protocol specification editors' report

July 2007

CAPWAP Protocol Specification Editors' Report

July 2007

[email protected]

[email protected]

[email protected]

July 2007

Editors’ Report Agenda

1. Highlights from -06/-03 issue resolution

2. Highlights from -07/-04 issue resolution

3. Discussion of new issues raised since publication of -07/-04

4. Next Steps

July 2007

Resolved Issues• Issues Resolved in -06/-03

– 248: Both IPv4 and IPv6 addresses not required – 250: Clarification

onDTLSRehandshake/DTLSPeerAuthorize/DTLSIncomingSession – 252: Heartbeat timer is undefined – 217: What is frame format when WTP encrypts/decrypts – 249: UDP-Lite as optional transport for CAPWAP – 251: Retransmission of control packets is not exponential

• Issues Resolved in -07/-04– 257: WTP IPvX address – 263: KeyLifetime should be removed – 262: Capwap state transition (Join to Image download) – 261: Issue with fix to issue 244 (Header Optimization) – 254: Clarification required on use of UDP ports – 258: DHCP Option Under-Specified – 244: preamble header optimization

July 2007

Issue Resolutions in -06, -03

• Issue 248 – Both IPv4 and IPv6 addresses not required – Editorial problem. The text required the WTP to have *both* an IPv4

and an IPv6 address. The fix is that only one is now required.

• Issue 250 – Clarification on DTLSRehandshake /DTLSPeerAuthorize / DTLSIncomingSession – There were three problems that existed with the DTLS text.

Specifically:1. The DTLSRehandshake timer still existed in the spec, but rehandshake is not supported by CAPWAP.2. The state machine pointed to the DTLSPeerAuthorize notification, which was not specified in the document.3. DTLSIncomingSession notification existed, but the state machine did not refer to it. The state machine included the actual state change, but was missing the text to point to the notification.

July 2007


• Issue 252 – Heartbeat timer is undefined – The text made references to a “Heartbeat timer”,

but the actual timer is called the EchoInterval timer.

• Issue 217 – What is frame format when

WTP encrypts / decrypts – Section 2.1.1 of the binding-02 draft did not

specify which fields in the 802.11 header the WTP and AC were responsible for setting when encryption occurred in the WTP.

July 2007


• Issue 249 – UDP-Lite as optional transport for

CAPWAP – In order for hardware to be able to process UDP headers

efficiently, the spec calls for a zero (0) checksum. However, IPv6 does not allow zero (0) checksum with UDP, which caused the WG to adopt UDP-Lite when CAPWAP is run over IPv6.

• Issue 251 – Retransmission of control packets is not exponential – The CAPWAP protocol did not have any congestion

control mechanisms, which we knew would be a problem during the IESG review. The control protocol now has exponential backoff.

July 2007


• Issue 257 - WTP IPvX address – The CAPWAP protocol states that the WTP IPv4 Address

message element can be used to determine if NAT is performed. However, there is no similar IPv6 message element. This was added in order to support v4< - >v6 scenarios.

• Issue 263 - KeyLifetime should be removed – The Working Group had agreed we would not use DTLS

rekeying, but the KeyLifetime field was never removed from the spec.

• Issue 262 - Capwap state transition (Join to Image download) – When the WTP entered the Image Data state (for image

downloads), it would not initialize the Echo Request timer.

July 2007

Issue Resolutions in -07, -04• Issue 261 – Issue with fix to issue 244 (Header

Optimization) – The introduction of issue 244 (Header Optimization) created editorial

issues.• Issue 254 – Clarification required on use of UDP ports

– The specification made references to control channel, control ports, control plane, etc. The same was true for the data channel. This issue ensured that the spec used a common terminology throughout, and added definitions for both the control and data channel.

• Issue 258 – DHCP Option Under-Specified – The use of DHCP in the CAPWAP specification was inconsistent with

how DHCP options are defined. The text was removed and moved to a separate specification that follows DHCP protocol conventions.

• Issue 244 - preamble header optimization– The issue raised was that the CAPWAP headers could be optimized to

reduce the overhead and duplication of fields.

July 2007

Issues Being Addressed for -08/-05

• Issue 15: DataChannelKeepAlive – The text refers to this timer that was not defined in

the spec

• Issue 16: MAC Address Length– The text included a MAC Address field of 9 bytes

(instead of 8) in various message elements.

July 2007

Next Steps

• Plan is to submit -08/-05 after IETF meeting– Depends largely on whether transport issues need to be

addressed– Need some guidance on which issues are show stoppers

• Do the chair anticipate another WG Last Call?– Since the WG Last Call occurred on -06/-03, some

technical changes were introduced that may warrant another one.

– Do we need another IEEE review? No comments were received on the previous version

capwap protocol specification editors' report

Documents