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

From: Abhijit Choudhury <[email-masked]>
Date: Sun, 28 Jan 2007 22:49:41 -0800 (PST)

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

____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

_________________________________________________________________
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: Mon, 29 Jan 2007 19:39:16 -0800

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

_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,

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

CAPWAP DTLS shim:

         0                   1                   2                   3

CAPWAP DTLS shim:

         0                   1                   2                   3

CAPWAP Header:

         0                   1                   2                   3

Other notes:

Thanks,

Jim

32 bits.

ACs.

Specifically
encrypted/
DTLS

 

  _____  

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