Subject: [Capwap] Comments on CAPWAP packet formats

From: "David T. Perkins" <[email-masked]>
Date: Tue, 23 Jan 2007 12:03:26 -0800 (PST)

HI,

First, I'm having problems following the decisions
on the "FLUX-MUX" issue, so there may be some
problems with the below. If so, I apologize.

I was asked to provide the motivations behind the
CAPWAP packet proposal that I sent to the WG last summer.
I hope the following helps. Questions/comments welcome.

--------------------------------------

Reasons for Changes to CAPWAP packet header
-------------------------------------------

Intro
-----

There are the following types of CAPWAP messages:
1) DTLS protected tunnelled data
2) Unprotected tunneled data
3) Unprotected Discover Request/Response
4) DTLS protected CAPWAP control messages

Attributes:
1) Message fragmentation (needed by all)
2) Message drop recovery (needed only by control,
                           and maybe only protected control)
3) Message syntax version (needed by all)
4) Message source/target specification (needed only by data)

Latest proposal is that all control has the following "preamble":
         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                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Then, based on the value of the Type field, possibly a DTLS header.

Then, the rest of the message.

Important Terminology
---------------------
1) CAPWAP packet - the contents of a UDP packet (after UDP
                     reassembly)
2) CAPWAP message - a complete CAPWAP "application level" message
                     that may have been reassembled from multiple
                     CAPWAP packets

Changes for Control Messages
----------------------------

Since both Data and Control messages MUST support fragmentation,
I propose that the fragmentation control come after the preamble
and (if present) the DTLS header. In current CAPWAP, fragmentation
control uses four fields, which are:
  1) packet is a fragment, single bit field; from CAPWAP-03:
       F: The Fragment 'F' bit indicates whether this packet is a fragment.
       When this bit is one (1), the packet is a fragment and MUST be
       combined with the other corresponding fragments to reassemble the
       complete information exchanged between the WTP and AC.
  2) packet is the last fragment of a CAPWAP message, single
     bit field; from CAPWAP-03:
       L: The Last 'L' bit is valid only if the 'F' bit is set and 
indicates
       whether the packet contains the last fragment of a fragmented
       exchange between WTP and AC.  When this bit is 1, the packet is
       the last fragment.  When this bit is 0, the packet is not the last
       fragment.
  3) message ID (called "Fragment ID" in CAPWAP); from CAPWAP-03:
       Fragment ID:  An 16 bit field whose value is assigned to each group
       of fragments making up a complete set.  The fragment ID space is
       managed individually for every WTP/AC pair.  The value of Fragment
       ID is incremented with each new set of fragments.  The Fragment ID
       wraps to zero after the maximum value has been used to identify a
       set of fragments.
  4) fragment offset; from CAPWAP-03:
       Fragment Offset:  A 13 bit field that indicates where in the payload
       will this fragment belong during re-assembly.  This field is valid
       when the 'F' bit is set to 1.  The fragment offset is measured in
       units of 8 octets (64 bits).  The first fragment has offset zero.
       Note the CAPWAP protocol does not allow for overlapping fragments.
       For instance, fragment 0 would include offset 0 with a payload
       length of 1000, while fragment 1 include offset 900 with a payload
       length of 600.

Current CAPWAP-03 has the first two fields as part of a 32-bit super field
that is only applicable for data messages, even though there is available
space in the 32-bit super field containing the "Fragment ID" and
"Fragment Offset" fields. Because the "F" and "L" fields are needed,
all messages in CAPWAP-03 MUST include the super field that is
applicable only to data messages. This is wasteful, and confusing.
Thus, I propose that all the fragmentation control fields be contained
in the same 32-bit super field, and that field come first. Note that
this is appropriate because the other fields of the data super field need
not be read and processed until after a message has been reassembled.

Note that I could not see the need for two bits (that is the F and L
fields), since fragmentation can be done with one of these fields.
The result is the following proposal for fragmentation control:

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |res|M|   CAPWAP message ID           |   Fragment Offset       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       res:  The 2-bit field is reserved for future use.  All
       implementations complying with this protocol MUST set to zero any
       bits that are reserved in the version of the protocol supported by
       that implementation.  Receivers MUST ignore all bits not defined
       for the version of the protocol they support.

       M: The More 'M' bit indicates whether there are more fragment
         packets needed to be combined to reassemble a complete
         CAPWAP message.  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 message.

       CAPWAP Message ID: A 16-bit field whose value is assigned to
       each CAPWAP message.  The CAPWAP message 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 message 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 message ID is incremented with each
       new CAPWAP message sent whether or not the PDU is fragmented.
       (All fragments of the same CAPWAP message have the same
       value for CAPWAP message ID.)
       The value wraps to zero after the maximum value has been
       used to identify a CAPWAP message. When a new session
       is established or when a WTP or AC starts, the initial
       value is a randomly generated number.

       Fragment Offset: A 13 bit field that indicates where in the
       CAPWAP message will this fragment belong during re-assembly.
       This field should always have a valid value. For the first
       or only packet of a CAPWAP message, 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
       message 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.)
         (DISCUSS: the units of 8 octets was copied from
         earlier CAPWAP drafts. It seems that this could
         be changed to a much larger unit, such as 64 or
         256 octets. When so, this field could be changed
         from 13 bits to 10 bits or 8 bits (respectively),
         and the newly available bits reserved for future
         use or to duplicate the version field. If used
         to duplicate the version field, then the same
         fragmentation control can be used for CAPWAP
         packets with or without the "preamble" field.)

Note: The benefits of this change are:
   1) The fragmentation control is contained in one
      "super field" (which simplifies the specification, and
      should make it easier to understand and to implement)
   2) The reassembly of fragments (to form a CAPWAP message)
      must be done before the rest of a CAPWAP packet
      is processed. The proposal moves this to the beginning
      of a CAPWAP packet (after the preamble or DTLS header).
   3) In current CAPWAP, the data message super field is
      duplicated in all fragments. By moving the fragment
      control to the beginning, this proposal has the
      data message super field occurring once, and in only
      data messages.
   4) The use of three fields, and the updated descriptions,
      seem much simpler and easier to understand and implement
      than using four fields for fragmentation control.

Control Message Fields
----------------------

A control message must have field that provide the the following
capabilities:
   1) specify message type
   2) provide support for reties due to message drop
   3) provide the length of message content
   4) provide support for unknown operation type

In CAPWAP, all operations consist of a pair of messages,
which are either:
  1) a request and response, or
  2) an indication and acknowledgement
Also, CAPWAP allows new operations to be defined by IETF WGs and
by vendors without changing the CAPWAP protocol version. CAPWAP
allows both WTPs and ACs to initiate an operation. Thus, a
WTP or AC may initiate an operation that is unknown by the
receiver. When this occurs in current CAPWAP, the only action
that can occur is to drop the CAPWAP connection. This proposal
includes a solution to this problem.

As is, current CAPWAP does not provide sufficient information
as to how retries are done. This proposal provides the details.

Proposal for 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Operation Type                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Msg ID       | Retry#|I| Res |     Length of Msg Elements    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Operation Type: This field identifies the operation type of the
             CAPWAP control message. The "I" bit is used to determine
             if the message is a request or response (or an
             indication or acknowledgement). The Operation Type field
             is comprised of an IANA Enterprise Number and an enterprise
             specific operation type number.  The first 20 bits is the
             enterprise number in network byte order, with zero being
             used for CAPWAP generic operation types and the IEEE 802.11
             IANA assigned enterprise number 13277 being used for
             IEEE 802.11 technology specific operation types.  The last
             12 bits is the enterprise specific operation type number,
             which has a range from 0 to 4095.

             The value of the operation type field can be expressed as:

             Operation type value = IANA Enterprise Number * 4096 +
                               enterprise specific operation type number

       Msg ID: The message ID field is used by the CAPWAP control
             application to match responses (or acknowledgements) with
             requests (or indications). The value must be monotonically
             incremented for each unique request (or indication). After
             the maximum value is reached, the value wraps back to zero.
             The paired response (or acknowledgement) returns the value
             from the request (or indication). Note the size is 8-bits,
             and thus a maximum of 255 CAPWAP operations can be currently
             outstanding. The message ID space is managed independently
             for every WTP/AC pair, and for each end (an AC or WTP).
             For example, if AC#1 communicates with WTP #1 and WTP #2,
             there will be the following independent Message IDs:
                 WTP #1: MSG ID1 for requests (and reports) going to AC #1
                 WTP #2: MSG ID2 for requests (and reports) going to AC #1
                 AC #1: MSG ID3 for requests going to WTP #1
                        MSG ID4 for requests going to WTP #2
             When a new session is established, the initial value is
             a randomly generated number.

       Retry#: The retry number field starts at zero and is incremented
             for each message with the same value of message ID.
             After the maximum value is reached, the value wraps back
             to zero.  The paired response (or acknowledgement) returns
             the value from the request (or indication). Note the size
             is 4-bits, and thus a maximum of 16 retries can be
             be currently outstanding.
             This field is used to match a request (or indication)
             with its paired response (or acknowledgement) so that
             accurate round trip operation time can be determined.
             (DISCUSS: maybe put back here the text about how this
             works. The examples of operation retries should help,
             which are provided at the end.)

       I: The 'I' bit field indicates if the message is the initiator
             message in a message pair. A value of "1" means
             first, and "0" means second in the pair. There are
             two types of message pairs, which are:
                1) a request and response
                2) an indication and acknowledgement
             Thus, the first is a request or indication message
             (with the 'I' field set to "1"), and the second is
             a response or acknowledgement (with the 'I' field
             set to "0"). Note, both a request and response
             (or indication and acknowledgement) of a operation
             use the same value for operation type. The
             'I' bit is used to indicate which is which.
             This allows new operation types to be added
             that can be processed without knowing the
             meaning of the operation type. That is, when
             an unknown request operation type is received,
             the response is the same operation type with
             a message element indicating that the operation
             type is not supported. Also, this allows the
             retry code to be implemented without knowledge
             of the "operation types" as specified in
             current CAPWAP. This should simplify implementation.

       Res: The bits are reserved and must be zero.

       Length of Message Elements: This field indicates in octets the
             length of the message elements field, which contains zero,
             one, or more message elements. The field is 16 bits wide,
             and thus the maximum size that can be specified 64K.
             However, the maximum size of a CAPWAP control message is
             64K, and thus the max length is 64K minus the size of
             the CAPWAP control header, or 64K - 8, or 65528.

Examples
--------
  There were examples provided in the proposal from last summer
  that showed how fragmentation and re-assembly worked, and how
  retries worked. These examples are not duplicated here.

Data Message Header
-------------------

   This proposal makes limited changes for data messages.
   These are:
      1) put the fragmentation control supper field before
         the data super field
      2) move the fragmentation fields from the data super field
         to the fragmentation super field

--------------------------------------

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

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