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

From: Abhijit Choudhury <[email-masked]>
Date: Fri, 26 Jan 2007 17:57:52 -0800 (PST)

Hi Suds,

The issue really is one of simplicity and having a
clean design. Having a fixed header format instead of
the proposed conditional one makes the
design simple, reduces development and validation effort
and reduces the chances of introducing bugs. 

Please see my comments in-line.
 
Thanks,
Abhijit
-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 5:37 PM
To: Bob O'Hara (boohara); [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)
Bob,
What has been proposed to avoid preamble in data path is nothing more than supporting more than one version number of CAPPWAP protocol. A good *HW* implementation should address it anyway. IMHO, multiple versions is going to be very common going forward as the current standard, in the interest of interoperability, has been made very restrictive.
And all the reason you have mentioned below does not look very strong to afford 4 bytes in each data packet. Please see inline comments.
-Suds
-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]]
Sent: Friday, January 26, 2007 4:28 PM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)
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.

[Suds] In the propose solution also a DTLS protected packet will always be handled in the same way. No difference. Only in case of non-protected packet there will be a difference. In that case, DTLS processing has to be bypassed any way. 

[Abhijit] There will be lots of deployments that will use a DTLS-encrypted control channel and a clear data channel.
Using the same format for the header makes the parser simpler.

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?

[Suds] Don't forget about the remote APs, where 32 byte overhead could be undesirable. 

[Abhijit] It's 32 bits, not 32 bytes. 
          I would agree with your concern if it was 32  bytes.
 
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.

[Suds] As I mentioned earlier, HW implementation is nothing more than two version of CAPOWAP supported, in a modified proposal send by me. A good HW implementation should definitely consider it to make it easier for future enhancements.

[Abhijit] Close to 3 years after we started, we are still 
          working on the first version. By the time
          the next version comes out, it'll be time to rev your    
          hardware anyway :-) So, I'd say that is a very weak reason  
          to change add this complexity.
 
I believe these practical reasons outweigh the reasons presented for making the change to the header.
[Suds] As I explain above, these reasons do not hold much ground.
-Suds
-----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

____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

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

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

---

From: "Sudhanshu" <[email-masked]>
Date: Fri, 26 Jan 2007 19:02:04 -0800

Abhijit,

Please see my inline comments below.

  _____  

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

Hi Suds,

[Suds] I am not sure it really a quantifiable advantage, but overhead of 32
bits is.

My 2 cents, only reason we have introduce the preamble (a kludge), to
address DTLS issue. So in case of clear channel, there is no need for
preamble.  

-----Original Message-----

Bob,

What has been proposed to avoid preamble in data path is nothing more than
supporting more than one version number of CAPPWAP protocol. A good *HW*
implementation should address it anyway. IMHO, multiple versions is going to
be very common going forward as the current standard, in the interest of
interoperability, has been made very restrictive.

And all the reason you have mentioned below does not look very strong to
afford 4 bytes in each data packet. Please see inline comments.

-Suds

-----Original Message-----

To: [email-masked]

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

[Suds] In the propose solution also a DTLS protected packet will always be
handled in the same way. No difference. Only in case of non-protected packet
there will be a difference. In that case, DTLS processing has to be bypassed
any way. 

[Abhijit] There will be lots of deployments that will use a DTLS-encrypted
control channel and a clear data channel.

[Suds] It is little hard to say it is significantly easier implementation
for running such a complex protocol. 

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?

[Suds] Don't forget about the remote APs, where 32 byte overhead could be
undesirable. 

[Suds] My mistake. A Typo.

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.

[Suds] As I mentioned earlier, HW implementation is nothing more than two
version of CAPOWAP supported, in a modified proposal send by me. A good HW
implementation should definitely consider it to make it easier for future
enhancements.

[Suds] This is the very reason once the one version is finalized;
people/customer would want some information which is not specified in it. We
can address it as an optional message element or we will be churning the
version number (as I mentioned in my email for issues 153). But is a
separate discussion than what we are discussing here.

I believe these practical reasons outweigh the reasons presented for making
the change to the header.

-Suds

-----Original Message-----

To: [email-masked]

146)

CAPWAP preamble.

[...]

0 1 2 3

|P|

[...]

[...]

[...]

0 1 2 3

|P|

[...]

[...]

the CAPWAP Header.

| | | P=0 | |

| | | P=1 | | | | |

factor)

Thanks,

Jim

  _____  

Expecting? Get great news right away with email
<http://us.rd.yahoo.com/evt=49982/*http:/advision.webevents.yahoo.com/mailbe
ta/newmail_tools.html>  Auto-Check.
Try the Yahoo!
<http://us.rd.yahoo.com/evt=49982/*http:/advision.webevents.yahoo.com/mailbe
ta/newmail_tools.html>  Mail Beta.