Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

From: Abhijit Choudhury <[email-masked]>
Date: Mon, 29 Jan 2007 21:08:06 -0800 (PST)

Hi Sudhanshu,
Please see my responses in-line,.

Thanks,
Abhijit

----- Original Message ----
From: Sudhanshu <[email-masked]>
To: Abhijit Choudhury <[email-masked]>; [email-masked]
Sent: Monday, January 29, 2007 7:39:16 PM
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

Abhijit, 
 
Don’t hang on to your calculation of 32 bit per packet in 1G pipe line.
 
CAPWAP is not designed only for the Greenfield deployments. And there will be lots of a/b/g APs which will be supporting CAPWAP, if it ever became a popular standard.
There will be hardly any AP with real 1G throughput any time soon. Most of them will be supporting max ~ 2xx mbps. And overhead has to be calculated on 2xx Mbps. 

[Abhijit]  The 1G link I referred to was the link between the WTP and AC.   The up-link of WTPs will be
              gradually changing over to 10/100/1000 MACs as Gig interfaces on L2/L3 switches become 
              ubiquitous.   In that case, no matter what your WTP throughput, the 
              CAPWAP encapsulated packet will be transmitted by the WTP towards the AC at 1G rate.  The special
              packet format is reducing the header by 32 bits, which means  32ns is being optimized away on this link.  
              You have to justify that that amount of time is worth adding additional code in the data path.

Not every architecture/every system will support the pure pipe line processing. And in that case, 4 byte DMA back-n-forth may be unnecessary overhead on memory bandwidth and processing both in AP and Switch 

[Abhijit]  Typically DMA is done on chunks of data.  Packet descriptors  are often allocated for 32, 64 or 128 bytes at a time.
             It is not clear that reducing your packet length by 4 bytes will make much of a difference in storage or 
             DMA bandwidth.

CAPWAP is not designed for the LAN environment only. In that case 1G bandwidth is a luxury, even in today’s world.
 
[Abhijit]  Agreed. But you have to look at where the primary use of CAPWAP is going to be.

If you to look back and review why after 3+ years, we still don’t have a standard, everybody may have their own opinion. But in the best interest of moving forward, let’s looks for the consensus.
 
[Abhijit]  That is the goal of this mailing list - creating consensus.  All I am saying is that there are 
              bigger issues to be finalized before we start discussing optimizations.

_Suds

From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Sunday, January 28, 2007 10:50 PM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)
 
Folks,
 
I'm sure there are many more optimizations that can be
made in the spec. It's been close to three years since
this WG started, and we still don't have a spec out.
Meanwhile, the WLAN industry has been impatiently waiting
for this standard.  It can be argued that if this spec 
is not ratified soon it might lose its relevance. 
At this point in time, as a group, we need to 
focus on fixing items that need fixing because they 
are broken. We cannot afford to spend time
debating "nice-to-have"s and changing perfectly working
items in the spec because we want to make some minor
optimizations. 
 
If the packet format in the current spec is broken, we 
should surely fix it. If 32 bits on a 1Gig link 
is all that is being optimized by this new packet 
format and additional code in the data path, I'd argue 
that this is not what this WG should be spending its time on. 
There are a whole bunch of decisions that need to be made 
before this spec can be sent out for last call. We need to
focus on those items and get this spec out asap.
.
Thanks,
Abhijit
 
-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 11:57 PM
To: Bob O'Hara (boohara)
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Bob,

I see no reason why this optimization can not be used in the control
channel as well. If so, then the concerns about the data and control
channel having to be exactly the same are eliminated with the added
benefit of improved performance in each case.

That said, I think we could improve the format a bit based on feedback
from Sudhanshu and some new observations based on the idea of packet
header overlay.

The basic idea is that Version and Type fields are what is needed for
the "preamble" and exist for every type of packet. However, only
8 bits are required. We then define the DTLS shim and CAPWAP Header to
include the preamble. The resulting format is something like this:

CAPWAP Preamble
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

    Version:  A 4 bit field which contains the version of CAPWAP used in
       this packet.  The value for this draft is zero (0).

    Payload Type:  A 4 bit field which specifies the payload type that
       follows the preamble header.  Unsupported values MUST be silently
       dropped. The following values are supported:

       0 -  Clear text.  If the packet is received on the data UDP port,
          the CAPWAP stack MUST treat this as a clear text CAPWAP data
          packet.  If received on the control UDP port, the CAPWAP stack
          MUST treat this as a clear text CAPWAP control packet.  If the
          control packet is not a Discovery Request or Response packet,
          it is illegal and MUST be dropped.

       1 -  DTLS Payload.  The packet is either a DTLS packet and MAY be
          a data or control packet, based on the UDP port it was
received
          on (see section Section 3.1).

CAPWAP DTLS shim:

         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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |                    Reserved
|

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

Or, said slightly differently:

CAPWAP DTLS shim:

         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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Preamble      |                    Reserved
|

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

For the header we then have the following:

CAPWAP Header:

         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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |  HLEN   |  RID    |  WBID
|T|F|L|W|M|K|Flags|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset         |Rsvd
|

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

Note, Version/Type are the CAPWAP preamble.

Essentially, what we have created a de-multiplexing scheme that has the
following properties:

  - Its performance characteristics are no worse than those of the -04
    preamble. In fact, demuxing directly off the preamble type is
    very attractive from a performance perspective.
  - It does not waste 32 bits in the clear path case.
  - It works equally well for the data path and the control path so
    it is a universal solution.
  - It provides for a powerful extensibility feature that will enhance
    the longevity of the protocol.

Other notes:

  - I have transposed RID and HLEN to give the hint of a TLV structure.
    I think this is a useful concept that we should support in the
    protocol.

  - I belive the F and L flags could be moved to the Rsvd area of the
    fragmentation super frame as suggested by David Perkins. This opens
    up some more flag space in the first super frame.

Thanks,

Jim

Bob O'Hara (boohara) wrote:
>  
> It's always fun to be part of an exercise to optimize something until 
> it can't be optimized any further, and let's be clear about it.  That 
> is what we are doing here.  The current preamble, common to both 
> control and data packets, works.  What is being proposed is to make 
> the data packet preamble as short as possible, by reducing its size by
32 bits.
> This comes at the cost of having the control and data packet formats 
> diverge.
> 
> Let me propose some reasons for keeping the preamble of the control 
> and data packets the same as they were.
> 
> 1. A DTLS-protected packet, either control or data, is handled exactly

> the same way to produce the decrypted CAPWAP payload.  This decrypted 
> payload can then be passed to software for processing (either control 
> or
> data) or can be passed to fast path hardware for data path processing.
> 
> 2. 32 bits take exactly 32ns to transmit at a gigabit per second, 
> which is likely to be the predominant connection for both WTPs and
ACs.
> Optimizing the protocol to save these 32ns is a foolish economy.  Is 
> there a dire cost that we encounter, in order to send these bits?
> 
> 3. Having two different CAPWAP preambles doubles the cost of 
> development of this portion of the protocol (particularly if the 
> CAPWAP header cracking is done in hardware), doubles the hardware 
> necessary to process this portion of the packet (perhaps even that 
> necessary to process the entire packet), and doubles the number of
bugs to discover and fix.
> 
> I believe these practical reasons outweigh the reasons presented for 
> making the change to the header.
> 
>  -Bob
>  
> -----Original Message-----
> From: Jim Murphy [mailto:[email-masked]]
> Sent: Thursday, January 25, 2007 12:19 AM
> To: [email-masked]
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part 
> of
> 146)
> 
> 
> Please consider the following alternative proposal to optimize the 
> data channel when no DTLS encryption is present. With this proposal, 
> CAPWAP data channels running in the clear will not require the CAPWAP 
> preamble. However, CAPWAP data channels running DTLS must have the 
> CAPWAP preamble.
> 
> The CAPWAP preamble is modified 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
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |Version| Type  |                    Reserved
> |P|
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
>      P: Must be 1. Indicates that this is a CAPWAP preamble.
> [...]
> 
> The CAPWAP Header is modified 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
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags
> |P|
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
>      P: Must be 0. Indicates that this is a CAPWAP preamble.
> [...]
> 
> The basic idea is to overlay the CAPWAP preamble and the first
> 32 bits of the CAPWAP Header. Note the intentional overlap of the 
> Version field and the P bit. Essentially the P bit is a type indicator

> that indicates the type of super field present. A 1 indicates a CAPWAP

> preamble, a 0 indicates the first 32 bits of the CAPWAP Header.
> 
> Any data packet on a clear (unencrypted) data channel looks as follows

> (to illustrate the use of the P bit):
> 
>         CAPWAP Plain Text Data Packet:
>         +--------------------------------+
>         | IP  | UDP | CAPWAP | Wireless  |
>         | Hdr | Hdr | Header | Payload   |
>         |     |     | P=0    |           |
>         +--------------------------------+
> 
> Any data packet on an encrypted data channel or a DTLS session 
> establishment packet looks as follows:
> 
>          DTLS Secured CAPWAP Data Packet:
>         +------------------------------------------------------+
>         | IP  | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
>         | Hdr | Hdr | p-amble| Hdr  |  Hdr   | Payload  | Trlr |
>         |     |     | P=1    |      |        |          |      |
>         +------------------------------------------------------+
>                               \----- authenticated -----/
>                                     \------- encrypted --------/
> 
> A switching entity need only check the CAPWAP Version and then the P 
> bit to determine if the CAPWAP packet needs DTLS processing.
> If the P but is not set, the switching entity may immediately assume 
> only a CAPWAP header and commences de-encapsulation and possible 
> reassembly processing.
> 
> This proposal serves the following purposes:
> 
>   - The CAPWAP preamble is present only when really needed.
Specifically
>     to identify CAPWAP packet attributes outside of the DTLS
encrypted/
>     authenticated area when DTLS is used.
> 
>   - Eliminates the waste of 32 bits of header information to convey a
>     single bit of information when in the clear.
> 
>   - Allows for the continued use of the CAPWAP preamble for other
>     purposes, such as DTLS session de-multiplexing to deal with the
>     issue of QoS reordering. (see earlier email from Mani - The QoS
DTLS
>     factor)
> 
> Please let me know if you have any questions.
> 
> Thanks,
> 
> Jim
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap

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

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

Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!

____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 30 Jan 2007 15:44:32 -0800

I agree with Abhijit. Yes, it has taken us three years to get to this
point and we need to be focused on what's broken in the protocol vs.
wish lists. I would propose we add this to the wish list for the next
version of CAPWAP.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Monday, January 29, 2007 9:08 PM
	To: Sudhanshu; [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Hi Sudhanshu,
	 
	Thanks,
	Abhijit

	----- Original Message ----
	From: Sudhanshu <[email-masked]>
	To: Abhijit Choudhury <[email-masked]>; [email-masked]
	Sent: Monday, January 29, 2007 7:39:16 PM
	Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Abhijit, 

	Don't hang on to your calculation of 32 bit per packet in 1G
pipe line.

	*	CAPWAP is not designed only for the Greenfield
deployments. And there will be lots of a/b/g APs which will be
supporting CAPWAP, if it ever became a popular standard. 
	*	There will be hardly any AP with real 1G throughput any
time soon. Most of them will be supporting max ~ 2xx mbps. And overhead
has to be calculated on 2xx Mbps. 

	[Abhijit]  The 1G link I referred to was the link between the
WTP and AC.   The up-link of WTPs will be

	              gradually changing over to 10/100/1000 MACs as Gig
interfaces on L2/L3 switches become 

	              ubiquitous.   In that case, no matter what your
WTP throughput, the 

	              CAPWAP encapsulated packet will be transmitted by
the WTP towards the AC at 1G rate.  The special

	              packet format is reducing the header by 32 bits,
which means  32ns is being optimized away on this link.  

	              You have to justify that that amount of time is
worth adding additional code in the data path.

	*	Not every architecture/every system will support the
pure pipe line processing. And in that case, 4 byte DMA back-n-forth may
be unnecessary overhead on memory bandwidth and processing both in AP
and Switch 

	[Abhijit]  Typically DMA is done on chunks of data.  Packet
descriptors  are often allocated for 32, 64 or 128 bytes at a time.

	             It is not clear that reducing your packet length by
4 bytes will make much of a difference in storage or 

	             DMA bandwidth.

	*	CAPWAP is not designed for the LAN environment only. In
that case 1G bandwidth is a luxury, even in today's world.

	[Abhijit]  Agreed. But you have to look at where the primary use
of CAPWAP is going to be.

	If you to look back and review why after 3+ years, we still
don't have a standard, everybody may have their own opinion. But in the
best interest of moving forward, let's looks for the consensus.

	[Abhijit]  That is the goal of this mailing list - creating
consensus.  All I am saying is that there are 

	              bigger issues to be finalized before we start
discussing optimizations.

	_Suds

________________________________

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Sunday, January 28, 2007 10:50 PM
	To: [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of 146)

	Folks,

	optimizations. 

	.

	Thanks,

	Abhijit

	-----Original Message-----
	From: Jim Murphy [mailto:[email-masked]] 
	Sent: Friday, January 26, 2007 11:57 PM
	To: Bob O'Hara (boohara)
	Cc: [email-masked]
	Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and
part of
	146)
	
	Bob,
	
	I see no reason why this optimization can not be used in the
control
	channel as well. If so, then the concerns about the data and
control
	channel having to be exactly the same are eliminated with the
added
	benefit of improved performance in each case.
	
	That said, I think we could improve the format a bit based on
feedback
	from Sudhanshu and some new observations based on the idea of
packet
	header overlay.
	
	The basic idea is that Version and Type fields are what is
needed for
	the "preamble" and exist for every type of packet. However, only
	8 bits are required. We then define the DTLS shim and CAPWAP
Header to
	include the preamble. The resulting format is something like
this:
	
	CAPWAP Preamble
	         0
	         0 1 2 3 4 5 6 7
	        +-+-+-+-+-+-+-+-+
	        |Version| Type  |
	        +-+-+-+-+-+-+-+-+
	
	    Version:  A 4 bit field which contains the version of CAPWAP
used in
	       this packet.  The value for this draft is zero (0).
	
	    Payload Type:  A 4 bit field which specifies the payload
type that
	       follows the preamble header.  Unsupported values MUST be
silently
	       dropped. The following values are supported:
	
	       0 -  Clear text.  If the packet is received on the data
UDP port,
	          the CAPWAP stack MUST treat this as a clear text
CAPWAP data
	          packet.  If received on the control UDP port, the
CAPWAP stack
	          MUST treat this as a clear text CAPWAP control packet.
If the
	          control packet is not a Discovery Request or Response
packet,
	          it is illegal and MUST be dropped.
	
	       1 -  DTLS Payload.  The packet is either a DTLS packet
and MAY be
	          a data or control packet, based on the UDP port it was
	received
	          on (see section Section 3.1).
	
	CAPWAP DTLS shim:
	
	         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 DTLS shim:
	
	         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 Header:
	
	         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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	        |          Fragment ID          |     Frag Offset
|Rsvd
	|

	
	Essentially, what we have created a de-multiplexing scheme that
has the
	following properties:
	
	  - Its performance characteristics are no worse than those of
the -04
	    preamble. In fact, demuxing directly off the preamble type
is
	    very attractive from a performance perspective.
	  - It does not waste 32 bits in the clear path case.
	  - It works equally well for the data path and the control path
so
	    it is a universal solution.
	  - It provides for a powerful extensibility feature that will
enhance
	    the longevity of the protocol.
	
	Other notes:
	
	  - I have transposed RID and HLEN to give the hint of a TLV
structure.
	    I think this is a useful concept that we should support in
the
	    protocol.
	
	  - I belive the F and L flags could be moved to the Rsvd area
of the
	    fragmentation super frame as suggested by David Perkins.
This opens
	    up some more flag space in the first super frame.
	
	Thanks,
	
	Jim
	
	32 bits.
	
	ACs.
	>          0                   1                   2
3
	
	>          0                   1                   2
3

	

	>         |     |     | P=1    |      |        |          |
|
	Specifically
	encrypted/
	DTLS

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

	 

________________________________

	Never Miss an Email
	Stay connected with Yahoo! Mail on your mobile. Get started!
<http://us.rd.yahoo.com/evt=43909/*http:/mobile.yahoo.com/services?promo
te=mail> 

________________________________

	Access over 1 million songs - Yahoo! Music Unlimited.
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yah
oo.com/unlimited/>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Jan 2007 18:48:14 -0500

<chair hat=off>

I agree with the proposal to add this item to the wish list for  
consideration in a possible later version of CAPWAP.

Margaret

</chair>

On Jan 30, 2007, at 6:44 PM, Pat Calhoun (pacalhou) wrote:

> I agree with Abhijit. Yes, it has taken us three years to get to  
> this point and we need to be focused on what's broken in the  
> protocol vs. wish lists. I would propose we add this to the wish  
> list for the next version of CAPWAP.
>
> Pat Calhoun
> CAPWAP is not designed only for the Greenfield deployments. And  
> there will be lots of a/b/g APs which will be supporting CAPWAP, if  
> it ever became a popular standard.
> There will be hardly any AP with real 1G throughput any time soon.  
> Most of them will be supporting max ~ 2xx mbps. And overhead has to  
> be calculated on 2xx Mbps.
>
>               CAPWAP encapsulated packet will be transmitted by the  
> WTP towards the AC at 1G rate.  The special
>
> Not every architecture/every system will support the pure pipe line  
> processing. And in that case, 4 byte DMA back-n-forth may be  
> unnecessary overhead on memory bandwidth and processing both in AP  
> and Switch
>
>              It is not clear that reducing your packet length by 4  
> bytes will make much of a difference in storage or
>
>              DMA bandwidth.
>
>
> CAPWAP is not designed for the LAN environment only. In that case  
> 1G bandwidth is a luxury, even in today’s world.
>
> If you to look back and review why after 3+ years, we still don’t  
> have a standard, everybody may have their own opinion. But in the  
> best interest of moving forward, let’s looks for the consensus.
>
>
> >          0                   1                    
> 2                   3
> 8 9 0
> >          0                   1                    
> 2                   3
> 8 9 0

---

From: Jim Murphy <[email-masked]>
Date: Wed, 31 Jan 2007 14:45:47 -0800

The rejection of this proposal for reasons of expediency makes
little sense in light of recent history for the following reasons:

Firstly, I was asked by the working group chair to bring this proposal
to this list at last week's interim meeting. The implication of the
request was that indeed the proposal has merit and is worth the groups
time to consider it.

Secondly, the expediency argument is a false economy.
The working group members, both the supporters and the detractors have
already invested their time considering the proposal through a
productive dialog on this email list. As a result of this dialog,
the proposal has been enhanced to address all the technical objections
and a technically superior specification is now at hand. It seems
shameful that after all technical issues have been addressed we now want
to waste those efforts for the sake of expediency when in fact the
work to include the proposal is comparatively small.

Finally, the expediency argument is further weekend by the fact that
the proposed text is included in this email. I've included it as both
clear text and a context diff.

Thanks,

Jim

--- Clear Text ---

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.  See section Section 3.1 for more information on the use of
    UDP.

    The CAPWAP Control protocol includes two messages that are never
    protected by DTLS.  These messages, called the Discovery Request and
    Discovery Response, need to be in the clear in order for 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.  The format of these packets are 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 encryption of the data frames,
    once again using the DTLS protocol.  Whether or not the data frames
    are encrypted is a matter of policy, which is described in a later
    section of this specification.  The format of these packets is as
    follows:

        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:  All CAPWAP packets are encapsulated within UDP.  Section
       Section 3.1 defines the specific UDP usage.

    CAPWAP DTLS Header:  All DTLS encrypted CAPWAP protocol packets are
       prefixed with the CAPWAP DTLS header.

    DTLS Header:  The DTLS header provides authentication and encrytion
       services to the CAPWAP payload it encapsulates.  This protocol is
       defined in RFC 4347 [9].

    CAPWAP Header:  All CAPWAP protocol packets use a common header that
       immediately follows the UDP header.  This header, is defined in
       Section 4.3.

    Wireless Payload:  A CAPWAP protocol packet that contains a wireless
       payload is known as a data frame.  The CAPWAP protocol does not
       dictate the format of the wireless payload, which is defined by
       the appropriate wireless standard.  Additional information is in
       Section 4.3.

    Control Header:  The CAPWAP protocol includes a signalling component,
       known as the CAPWAP control protocol.  All CAPWAP control packets
       include a Control Header, which is defined in Section 4.4.1.

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

4.1.  CAPWAP Preamble

    The CAPWAP preamble header common to all CAPWAP transport headers and
    is used to identify the header type that immediately follows.  The 
reason
    for this header to is avoid needing to perform byte comparisons in order
    to guess whether the frame is DTLS encrypted or not.  It also 
provides an
    extensibility framework that can be used to support additional transport
    types. The format of the frame is as follows:

         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

    Payload Type:  A 4 bit field which specifies the payload type that
       follows the preamble header.  The following values are supported:

       0 -  CAPWAP Header.  If the packet is received on the data UDP port,

       1 -  CAPWAP DTLS Header.  The packet is a DTLS packet and MAY be
          a data or control packet, based on the UDP port it was received
          on (see section Section 3.1).

4.2.  CAPWAP DTLS Header

    The CAPWAP DTLS header is used to identify the packet as a DTLS
    encrypted packet. The first eight bits includes the common CAPWAP
    preamble. The remaining 24 bits are padding to ensure 4 byte alignment.

         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: See section 4.1. Payload Type is hard coded to 1 for
       the CAPWAP DTLS Header.

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: See section 4.1. Payload type is hardcoded to 0.
       The value of the Version field MUST match the version field
       set in the CAPWAP DTLS header if applicable (see Section 4.2).
       The reason for this duplicate field is to avoid any possible
       tampering of the version field in the CAPWAP DTLS header which
       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 which contains the Radio ID number for this
       packet.  WTPs with multiple radios but a single MAC Address range
       use this field to indicate which radio is associated with the
       packet.

---- Context Diffs ----
*** draft-ietf-capwap-protocol-specification-04.txt	2007-01-31 
11:22:23.000000000 -0800
--- preamble-mods.txt	2007-01-31 12:06:59.000000000 -0800
***************
*** 1908,1915 ****
   4.  CAPWAP Packet Formats

      This section contains the CAPWAP protocol packet formats.  A CAPWAP
!    protocol packet consists of a CAPWAP Transport Layer packet header
!    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
--- 1908,1915 ----
   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
***************
*** 1923,1944 ****
      packets are as follows:

          CAPWAP Control Packet (Discovery Request/Response):
!        +---------------------------------------------------+
!        | IP  | UDP | CAPWAP |CAPWAP | Control | Message    |
!        | Hdr | Hdr | p-amble|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.  The format of these packets are as follows:

       CAPWAP Control Packet (DTLS Security Required):
!     +------------------------------------------------------------------+
!     | IP  | UDP | CAPWAP | DTLS | CAPWAP | Control | Message    | DTLS |
!     | Hdr | Hdr | p-amble| Hdr  | Header | Header  | Element(s) | Trlr |
!     +------------------------------------------------------------------+
!                          \----------- authenticated ------------/
!                                  \------------- encrypted -------------/

      The CAPWAP protocol allows optional encryption of the data frames,
      once again using the DTLS protocol.  Whether or not the data frames
--- 1923,1944 ----
      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.  The format of these packets are 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 encryption of the data frames,
      once again using the DTLS protocol.  Whether or not the data frames
***************
*** 1962,1986 ****

          CAPWAP Plain Text Data Packet :
!        +-----------------------------------------+
!        | IP  | UDP | CAPWAP | CAPWAP | Wireless  |
!        | Hdr | Hdr | p-amble| Header | Payload   |
!        +-----------------------------------------+

          DTLS Secured CAPWAP Data Packet:
!        +------------------------------------------------------+
!        | IP  | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
!        | Hdr | Hdr | p-amble| Hdr  |  Hdr   | Payload  | Trlr |
!        +------------------------------------------------------+
!                              \----- authenticated -----/
!                                    \------- encrypted --------/

      UDP:  All CAPWAP packets are encapsulated within UDP.  Section
         Section 3.1 defines the specific UDP usage.

!    CAPWAP preamble:  All CAPWAP protocol packets are prefixed with the
!       preable header, which is used to identify the frame type that
!       follows.  This header, is defined in Section 4.1.

      DTLS Header:  The DTLS header provides authentication and encrytion
         services to the CAPWAP payload it encapsulates.  This protocol is
--- 1962,1985 ----

          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:  All CAPWAP packets are encapsulated within UDP.  Section
         Section 3.1 defines the specific UDP usage.

!    CAPWAP DTLS Header:  All DTLS encrypted CAPWAP protocol packets are
!       prefixed with the CAPWAP DTLS header.

      DTLS Header:  The DTLS header provides authentication and encrytion
         services to the CAPWAP payload it encapsulates.  This protocol is
***************
*** 1988,1994 ****

      CAPWAP Header:  All CAPWAP protocol packets use a common header that
         immediately follows the UDP header.  This header, is defined in
!       Section 4.2.

      Wireless Payload:  A CAPWAP protocol packet that contains a wireless
         payload is known as a data frame.  The CAPWAP protocol does not
--- 1987,1993 ----

      CAPWAP Header:  All CAPWAP protocol packets use a common header that
         immediately follows the UDP header.  This header, is defined in
!       Section 4.3.

      Wireless Payload:  A CAPWAP protocol packet that contains a wireless
         payload is known as a data frame.  The CAPWAP protocol does not
***************
*** 2017,2035 ****
   Internet-Draft        CAPWAP Protocol Specification         January 2007

! 4.1.  CAPWAP preamble

!    The CAPWAP preamble header is used to help identify the payload type
!    that immediately follows.  The reason for this header to is avoid
!    needing the perform byte comparisons in order to guess whether the
!    frame is DTLS encrypted or not.  The format of the frame 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
!        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!        |Version| Type  |                    Reserved                   |
!        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version:  A 4 bit field which contains the version of CAPWAP used in
         this packet.  The value for this draft is zero (0).
--- 2016,2035 ----
   Internet-Draft        CAPWAP Protocol Specification         January 2007

! 4.1.  CAPWAP Preamble

!    The CAPWAP preamble header common to all CAPWAP transport headers and
!    is used to identify the header type that immediately follows.  The 
reason
!    for this header to is avoid needing to perform byte comparisons in 
order
!    to guess whether the frame is DTLS encrypted or not.  It also 
provides an
!    extensibility framework that can be used to support additional 
transport
!    types. The format of the frame is as follows:
!
!         0
!         0 1 2 3 4 5 6 7
!        +-+-+-+-+-+-+-+-+
!        |Version| Type  |
!        +-+-+-+-+-+-+-+-+

      Version:  A 4 bit field which contains the version of CAPWAP used in
         this packet.  The value for this draft is zero (0).
***************
*** 2037,2060 ****
      Payload Type:  A 4 bit field which specifies the payload type that
         follows the preamble header.  The following values are supported:

!       0 -  Clear text.  If the packet is received on the data UDP port,
            the CAPWAP stack MUST treat this as a clear text CAPWAP data
            packet.  If received on the control UDP port, the CAPWAP stack
            MUST treat this as a clear text CAPWAP control packet.  If the
            control packet is not a Discovery Request or Response packet,
!          it is illegal and MUST be dropped.

!       1 -  DTLS Payload.  The packet is either a DTLS packet and MAY be
            a data or control packet, based on the UDP port it was received
            on (see section Section 3.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.2.  CAPWAP Header

      All CAPWAP protocol messages are encapsulated using a common header
      format, regardless of the CAPWAP control or CAPWAP Data transport
--- 2037,2069 ----
      Payload Type:  A 4 bit field which specifies the payload type that
         follows the preamble header.  The following values are supported:

!       0 -  CAPWAP Header.  If the packet is received on the data UDP port,
            the CAPWAP stack MUST treat this as a clear text CAPWAP data
            packet.  If received on the control UDP port, the CAPWAP stack
            MUST treat this as a clear text CAPWAP control packet.  If the
            control packet is not a Discovery Request or Response packet,
!          it is illegal and MUST be dropped.

!       1 -  CAPWAP DTLS Header.  The packet is a DTLS packet and MAY be
            a data or control packet, based on the UDP port it was received
            on (see section Section 3.1).

! 4.2.  CAPWAP DTLS Header

!    The CAPWAP DTLS header is used to identify the packet as a DTLS
!    encrypted packet. The first eight bits includes the common CAPWAP
!    preamble. The remaining 24 bits are padding to ensure 4 byte alignment.
!
!         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: See section 4.1. Payload Type is hard coded to 1 for
!       the CAPWAP DTLS Header.
!
! 4.3.  CAPWAP Header

      All CAPWAP protocol messages are encapsulated using a common header
      format, regardless of the CAPWAP control or CAPWAP Data transport
***************
*** 2076,2082 ****
           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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!        |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags    |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |          Fragment ID          |     Frag Offset         |Rsvd |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 2085,2091 ----
           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 |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
***************
*** 2087,2108 ****
          |                        Payload ....                           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

!    Version:  A 4 bit field which contains the version of CAPWAP used in
!       this packet.  The value of this field MUST match the version field
!       set in the CAPWAP preamble header (see Section 4.1).  The reason
!       for this duplicate field is to avoid any possible tampering of the
!       version field in the preamble header which is not encrypted or
!       authenticated.

      RID:  A 5 bit field which contains the Radio ID number for this
         packet.  WTPs with multiple radios but a single MAC Address range
         use this field to indicate which radio is associated with the
         packet.

-    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.
-
      WBID:  A 5 bit field which is the wireless binding identifier.  The
         identifier will indicate the type of wireless packet type
         associated with the radio.  The following values are defined:
--- 2096,2117 ----
          |                        Payload ....                           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

!    CAPWAP Preamble: See section 4.1. Payload type is hardcoded to 0.
!       The value of the Version field MUST match the version field
!       set in the CAPWAP DTLS header if applicable (see Section 4.2).
!       The reason for this duplicate field is to avoid any possible
!       tampering of the version field in the CAPWAP DTLS header which
!       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 which contains the Radio ID number for this
         packet.  WTPs with multiple radios but a single MAC Address range
         use this field to indicate which radio is associated with the
         packet.

      WBID:  A 5 bit field which is the wireless binding identifier.  The
         identifier will indicate the type of wireless packet type
         associated with the radio.  The following values are defined: