Subject: [Capwap] Proposed resolution for Issue 146

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 11:36:13 -0800

All,

Issue 146 includes a variety of change requests to the CAPWAP headers. I
sent a recently proposed resolution that describes how encrypted packets
are identified from packets in the clear, so that part of issue 146 has
been addressed. This e-mail will touch on the other three major change
requests in issue 146.

1. Separate Fragmentation Header. Issue 146 separates the fragmentation
header from the control header, which is called  the CAPWAP
Fragmentation Control Header. Furthermore, the issue proposes that the
CAPWAP Data (or control) Header only appear in the first fragment. The
following describes the actual proposal:

<dave's proposal>
   CAPWAP Unprotected Data Packet:
   +------------------------------[--------]----------+
   | IP  | UDP  | CAPWAP | CAPWAP | CAPWAP | Wireless |
   | Hdr | Hdr  | Pkt    | Frag   | Data   | Payload  |
   |     |      | Hdr    | Ctrl   | Hdr    | Frag     |
   +------------------------------[--------]----------+
                                   only in
                                   first fragment
[...]
     CAPWAP Fragmentation Control Header: Used for fragmentation
           of CAPWAP PDUs. A CAPWAP PDU that will not fit in
           one UDP packet will be fragmented into multiple
           CAPWAP packets.
[...]
  CAPWAP Fragmentation Control 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|Res|     CAPWAP PDU ID             |   Fragment Offset       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     M: The More 'M' bit indicates whether there are more fragment
       packets needed to be combined to reassemble a complete
       CAPWAP PDU.  When this bit is 1, there are more fragment
       packets.  When this bit is 0, there are no more fragments
       and this packet completes the CAPWAP PDU.

     Res: The bits are reserved, and must be zero.

     CAPWAP PDU ID: A 16-bit field whose value is assigned to each
       CAPWAP PDU.  The CAPWAP PDU ID space is managed independently
       for every WTP/AC pair, for each end (an AC or WTP), and for
       each CAPWAP stream (data or control).  For example, if AC #1
       communicates with WTP #1 and WTP #2, there will be the
       following independent CAPWAP PDU IDs:
          WTP #1: ID1 for control going to AC #1
                  ID2 for data going to AC #1
          WTP #2: ID3 for control going to AC #1
                  ID4 for data going to AC #1
          AC #1:  ID5 for control going to WTP #1
                  ID6 for data going to WTP #1
                  ID7 for control going to WTP #2
                  ID8 for data going to WTP #2
       The value for each CAPWAP PDU ID is incremented with each
       new CAPWAP PDU sent whether or not the PDU is fragmented.
       The value wraps to zero after the maximum value has been
       used to identify a CAPWAP PDU. When a new session
       is established, the initial value is a randomly generated
       number.

     Fragment Offset: A 13 bit field that indicates where in the CAPWAP
       PDU will this fragment belong during re-assembly.  This
       field should always have a valid value. For the first
       or only packet of a CAPWAP PDU, the value must be zero.
       The fragment offset is measured in units of 8 octets
       (64 bits).  This provides a maximum size of a CAPWAP
       PDU to be 16 bits (which is 65536 octets).
       Note the CAPWAP protocol does not allow for overlapping
       fragments. For instance, it would be an error if the
       first fragment was 1000 octets in length, and the
       second fragment's offset was 800. To be valid (when
       the length of the first fragment is 1000, the second
       fragment MUST have an offset of 1000.
       (DISCUSS: need to have a timer that is associated with
       fragmentation to toss all of the fragments if they
       have not been combined in the allocated time.)
[...]
<dave's proposal>

This proposal does two things. The first is to shift the bits around in
the packet (frag is a separate header). The proposal also introduces the
'M'ore bit which is used to indicate whether more data is coming, which
the current spec already supports via the 'F' and 'L' bits. I do not
believe that shifting bits around and renaming them really increases the
quality of the specification, nor do I believe there is a strong need to
move all of the fragmentation data into a separate header.

The second major change states that all subsequent fragments do not need
to include a CAPWAP data/control header. I again do not believe that
this change provides enough value to justify accepting it. While it does
reduce the packet size (by a few bytes over the wire), it does introduce
complexity in the packet handling logic where packets can have separate
header sizes. I believe that having a constant header size is much
simple for the reassembly logic to perform its task.

Pat's recommendation: Reject the request.

2. Changes to the control/data header.

Dave's proposal also fundamentally changes the format of the headers so
that the data and control headers are very different. For instance, he
proposes the data header have the following format:

<dave's proposal>
   CAPWAP Data 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RID     | HLEN    |  WBID   |T|W|M|          Res              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 (optional) Radio MAC Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            (optional) Wireless Specific Information           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</dave's proposal>

While the control header has the following format (and does not include
the above header):

<dave's proposal>
   CAPWAP Control 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Message Type                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Msg ID       | Retry#|F| Res |     Length of Msg Elements    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</dave's proposal>

I am having a hard time agreeing with the proposed change. First, there
are various fields in the current CAPWAP header, which Dave proposes is
only required for data frames, that are useful for control messages. For
instance, the RID field is useful to knowing for which radio the packet
has relevance. Furthermore, the WBID is useful in understanding the
wireless binding for which the control packet is to be used for. Yes,
there are a couple of bits in the flags that have no relevance for
control packets, but I don't think that justifies creating vastly
different header formats.

The control header currently defined in the CAPWAP protocol currently
has the format:

<current spec>
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message Type                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Seq Num    |        Msg Element Length     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Time Stamp                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Msg Element [0..N] ...
     +-+-+-+-+-+-+-+-+-+-+-+-+
</current spec>

What Dave is proposing here is to rename the Seq Num to Msg ID, which I
don't believe is necessary. However, Dave is also proposing a Retry
number field, which is monotonically increased everytime a packet is
retransmitted. This is a concept that has been discussed in various
other working groups at the IETF, and to date I am not aware of any
protocol that has made use of it. It has been discussed in the AAA ad
nauseum, and was not adopted. The issue here is why it matters what the
retry number is? If a packet is received and it has a value of two, why
should the receiver handle it any different from a value of one? The Seq
Num is used to detect duplicate packets, so we already have a way to
identify a retransmission. Just because a packet was lost in the network
doesn't cause the receiver to treat the packet any differently. 

The 'F' bit is used to identify a request from a response, but this is
already supported in the Message Type. Dave's proposal requires that all
of the message types be renumbered so the request and the responses
share the same type, and we use the 'F' bit. I MUCH prefer that we keep
the current scheme of having an explicit request and response type,
which makes the document easier to read as the message type names do not
need to be qualified with a separate bit.

Pat's recommendation: Reject the request.

3. Changes to the Message Element Header.

Dave's proposal is to increase the message type field from 16 to 32
bits. As some of you probably recall, the field was originally 8 bits
wide, and after many discussions, the list agreed that 16 bits was
sufficient. I see no reason to reopen this discussion.

Pat's recommendation: Reject the request.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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