Subject: [Capwap] Motivations for CAPWAP Header change - FOR WG MEETING

From: "David T. Perkins" <[email-masked]>
Date: Mon, 6 Nov 2006 13:38:12 -0800 (PST)

HI,

Below are a summary of the motivations for the CAPWAP
header change and the proposal in the message from
Sun, 23-jul-2006:

1) Clean separation components.
Discussion:
 In -03 draft, the header is 4 32-bit components, with the last
 two being optional. The first 32-bit component has some sub-fields
 that are applicable to both control and data messages, but also
 has sub-fields that are applicable only to data. The 2nd component
 is common to both data and control, and the option 3rd and 4th
 components are only for data messages.
 The proposal defines a clean separation of components for data
 and control. The common header specifies sub-fields that
 are applicable to both data and control. The components that
 are specific to data or control follow the single common
 component.

2) Fragmentation.
Discussion:
 Both the data and control messages NEED and, thus, MUST
 have support for fragmentation cause by path max message
 size being smaller than CAPWAP message size. There is
 a small difference with the fragmentation in between the
 -03 and the proposal, which is the proposal id defined
 and encoded so that the values of the fields that control
 fragmentation are always valid, regardless of whether
 or not the message is fragmented. 

3) Data Message Header differences.
Discussion:
 There is little differences between the -03 draft for
 data message header (after step 1 above has been done)
 and the proposal.

4) Control Message Header differences
Discussion:
 The big difference is in how the -03 draft and the proposal
 supports retries. I believe the -03 draft WILL NOT WORK
 due to DTLS suppression of duplicates. This issue is
 described in the proposal. The proposal has a mechanism
 that does work with DTLS (and also with non-conforming
 DTLS implementations).

The proposal was made to simplify the header, and thus
improve the probablity that there would be interoperable
implementations, and to provide a valid mechanism for
retries.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap