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

[Bob O'Hara (boohara) (boohara]

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