Capwap Mailing List: Re: Proposed Resolution for Issue 224/89 (and part of 146)

[Sudhanshu (sudhanshu.ietf]

Abhijit,

 

Please see my inline comments below.

 

---

From: Abhijit Choudhury [mailto:abhijit10425 [at] yahoo.com]
Sent: Friday, January 26, 2007 5:58 PM
To: capwap [at] frascone.com
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

 

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.

[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-----

From: Sudhanshu [mailto:sudhanshu.ietf [at] gmail.com]

Sent: Friday, January 26, 2007 5:37 PM

To: Bob O'Hara (boohara); capwap [at] frascone.com

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:boohara [at] cisco.com]

Sent: Friday, January 26, 2007 4:28 PM

To: capwap [at] frascone.com

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.

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

 

[Abhijit] It's 32 bits, not 32 bytes.

          I would agree with your concern if it was 32  bytes.

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

 

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

 

[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] As I explain above, these reasons do not hold much ground.

-Suds

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

From: Jim Murphy [mailto:jmurphy [at] trapezenetworks.com]

Sent: Thursday, January 25, 2007 12:19 AM

To: capwap [at] frascone.com

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

 

---

Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.