CAPWAP Protocol Specification Editors' Report

1
CAPWAP Protocol Specification Editors' Report

• July 2007
• pcalhoun_at_cisco.com
• mmontemurro_at_rim.com
• dstanley_at_arubanetworks.com

2
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

3
Resolved Issues

• Issues Resolved in -06/-03
• 248 Both IPv4 and IPv6 addresses not required
• 250 Clarification onDTLSRehandshake/DTLSPeerAutho
  rize/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

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

5
Issue Resolutions in -06, -03

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

6
Issue Resolutions in -06, -03

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

7
Issue Resolutions in -07, -04

• 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 v4lt - gtv6 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.

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

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

10
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