Subject: [Capwap] Ver 4 or CAPWAP packet syntax

From: "David T. Perkins" <[email-masked]>
Date: Sun, 23 Jul 2006 21:12:11 -0700 (PDT)

HI,

Here is an update of my proposal for CAPWAP packet formats:

Proposal for CAPWAP Packet Format (24-jul-2006)
--------------------------------

Updated from 24-jun-2006:
1) Removed the CAPWAP pkt header and moved the fields into the
   fragmentation control header.
2) Added note about use of UDP ports for DLTS and non-DTLS
   messages
3) Updated example section to match change in fragmentation
   header field
4) Added an example to show fragmentation and retries together
5) Added note about DLTS processing of duplicates

Updates from 22-jun-2006:
1) Cleaned up terminology definitions.
1) Added clarification about initial values for the
   "CAPWAP PDU ID" and "MSG ID" fields
2) Added timing diagram showing no fragmentation and fragmentation
3) Added timing diagram showing CAPWAP control message drops
   and retries
4) Put back in MSG Seq ID into the Control header, but re-labeled
   as retry num, and reordered fields.

Updates from 8-jun-2006:
1) Made to look closer to CAPWAP-02
2) Added CAPWAP Fragmentation Header so that both control
    and data supported fragmentation
3) Updated descriptions of fields of packets
4) Changed how fragmentation is indicated.
5) Modified so that the Data (or Control) header is
   on in the first fragment of a CAPWAP PDU
6) Cleaned up Data Header, now that fragmentation
   is in a separate header and made the remaining
   fields match those in CAPWAP-02
7) Updated the Control Header so that it closely
   resembles CAPWAP-02, except for 'F' field.

Updates from 7-jun-2006:
1) changed diagrams to make DTLS experts happier
2) renamed "CAPWAP MUX Hdr" to "CAPWAP Pkt Hdr",
    and made it 2 octets long instead of 1 octet
3) made the packet types start at 1 instead of zero
4) fixed a few typos
5) changed the formulas for the message type value and
   message element type value to multiply the IANA
   enterprise number by 4096 (shift left by 12) instead
   of 256 (shift left by 8). This means the the
   enterprise value must be encoded in 20 bits,
   and the specific type value in 12 bits. I checked
   the assignment of Enterprise numbers, and there are
   now approximately 16K, and also checked the OUI
   assignments and there are approximately 51K. Thus,
   20 bits (1M) should be enough!
---------------------------------

  CAPWAP Packet formats:

  NOTE: This format of CAPWAP messages assumes that
        DTLS traffic is sent to one well known UDP port
        on the AC, and CAPWAP messages not using
        DTLS encapsulation are sent to another well
        known UDP port.
        The formats support both data and control
        sent to the same UDP port or use of different
        UDP ports for data and control.

    CAPWAP Unprotected Data Packet:
    +---------------------[--------]----------+
    | IP  | UDP  | CAPWAP | CAPWAP | Wireless |
    | Hdr | Hdr  | Frag   | Data   | Payload  |
    |     |      | Ctrl   | Hdr    | Frag     |
    +---------------------[--------]----------+
                            only in
                            first fragment

    CAPWAP DTLS Protected Data Packet:
    +----------------------------[---------]--------------------+
    | IP  | UDP | DTLS  | CAPWAP | CAPWAP  | Wireless | DTLS    |
    | Hdr | Hdr | Hdr   | Frag   | Data    | Payload  | Trailer |
    |     |     |       | Ctrl   | Hdr     | Frag     |         |
    +----------------------------[---------]--------------------+
                                   only in
                                   first fragment
                 \--integrity checked----------------/
                         \--encrypted--------------------------/

    CAPWAP Unprotected Control Packet:
    +---------------------[---------]----------+
    | IP  | UDP  | CAPWAP | CAPWAP  | Message  |
    | Hdr | Hdr  | Frag   | Control | Elements |
    |     |      | Ctrl   | Hdr     | Frag     |
    +---------------------[---------]----------+
                            only in
                            first fragment

    CAPWAP DTLS Protected Control Packet:
    +---------------------------[---------]--------------------+
    | IP  | UDP | DTLS | CAPWAP | CAPWAP  | Message  | DTLS    |
    | Hdr | Hdr | Hdr  | Frag   | Control | Elements | Trailer |
    |     |     |      | Ctrl   | Hdr     | Frag     |         |
    +---------------------------[---------]--------------------+
                                 only in
                                 first fragment
                 \--integrity checked---------------/
                        \--encrypted--------------------------/

      UDP: All CAPWAP packets are encapsulated within UDP.

      CAPWAP PDU: CAPWAP consists of both control and data streams.
            A CAPWAP PDU is either a CAPWAP control PDU or
            a CAPWAP data PDU.

      CAPWAP Control PDU: A CAPWAP control PDU encapsulates a
            control message, which is a control header and its
            message elements.

      CAPWAP Data PDU: A CAPWAP data PDU encapsulates a data
            message, which is a data header and wireless
            payload.
              
      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. It also indicates if the CAPWAP
            PDU is control or data.

      CAPWAP Data Header: This header is used for CAPWAP data PDUs.
            If a CAPWAP data PDU is fragmented, then the CAPWAP
            Data Header is in only the first fragment in the
            group of fragments constructing the CAPWAP data PDU.

      Wireless Payload: The actual payload from or to wireless
            devices. The format may be 802.3 Ethernet II, or
            native wireless transport specific encoding.

      DTLS Header: Protected CAPWAP packets use the DTLS protocol to
            provide message integrity and encryption services.

      DTLS Trailer: A field used to provide protection service for
            security of CAPWAP messages.

      CAPWAP Control Header: The CAPWAP protocol includes a signalling
            component, known as the CAPWAP control protocol.  All CAPWAP
            control PDUs include a Control Header. If a CAPWAP control PDU
            is fragmented, then the CAPWAP Control Header is in only
            the first fragment in the group of fragments constructing
            the CAPWAP control PDU. 

      Message Elements: A CAPWAP Control PDU includes zero, one,
            or more message elements, which are found immediately
            following the control header.  These message elements
            are in a type, length, value format.

    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   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |ver|T|M|   CAPWAP PDU ID             |   Fragment Offset       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ver: a 2 bit field that contains the version of the CAPWAP
         protocol syntax used for the packet.  The value is
         zero for this draft.

      T: The PDU type. The value '1' indicates a control PDU and
         the value '0' indicates a data PDU. (Note: if the data
         and control streams are sent to different UDP ports,
         then PDUs sent to the inappropriate UDP port is dropped.)

      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.
      
      CAPWAP PDU ID: A 15-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.
        (All fragments of the same CAPWAP PDU have the same
        value for CAPWAP PDU ID.)
        The value wraps to zero after the maximum value has been
        used to identify a CAPWAP PDU. 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
        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.)
        (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.)

    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           |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                       
      RID: A 5 bit field which contains the Radio ID for this CAPWAP
        data PDU.  WTPs with multiple radios but a single MAC Address
        range (for BSSIDs) use this field to indicate which radio is
        associated with the packet.

      HLEN: A 5 bit field specifying the length of the CAPWAP data
        header header in 4 octet words (Similar to IP header length).
        This length includes the optional headers.

      WBID: A 5 bit field which is the wireless binding identifier.
        The identifier will indicate the type of wireless packet type
        associated with the radio.  The following values are defined:
          1 - IEEE 802.11

      T: The Type 'T' bit indicates the format of the frame being
        transported in the payload.  When this bit is set to one (1),
        the payload has the native frame format indicated by the
        WBID field.  When this bit is zero (0) the payload is an
        IEEE 802.3 frame.

      W: The 'W' bit is used to specify whether the optional
        "Wireless Specific Information" field is present in the header.
        A value of one (1) is used to represent the fact that the
        field is present.

      M: The 'M' bit is used to specify whether the optional
        "Radio MAC Address" field is present in the header.  
        A value of one (1) is used to represent the fact that the
        field is present.

      Res: The bits are reserved and must be zero.

      Radio MAC Address: This optional field contains the BSSID
        of the radio receiving the packet.  This is used in packets
        sent from the WTP to the AC, when the native wireless frame
        format is converted to 802.3 by the WTP.  This field is only
        present if the 'M' bit is set.  Given the HLEN field requires
        the header size to be a multiple of 4 octets, this field MUST
        be padded with zeroes (0x00) if it is not 4 octet aligned.

        The field has the format:

         0                   1                   2                  
         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |    Length     |                  MAC Address           ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

        Length: The number of octets in the MAC Address field.  The
            length field is present since new IEEE technologies
            (e.g., 802.16) are now using 64 bits (8 octet) MAC
            addresses.

        MAC Address: The BSSID of the receiving radio.

      Wireless Specific Information: This optional field contains
        technology specific information that may be used to carry per
        packet wireless information.  This field is only present if
        the 'W' bit is set.  Given the HLEN field assumes 4 octet
        alignment, this field MUST be padded with zeroes (0x00) if
        it is not 4 octet aligned.

        The field has the format:

         0                   1                   2                  
         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |  Wireless ID  |    Length     |             Data       ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

          Wireless ID: The wireless binding identifier.  The following
                values are defined:
                    1 - : IEEE 802.11

          Length: The length of the data field

          Data: Wireless specific information, whose details are 
                defined in the technology specific bindings sections.
                
                For 802.11, when sent from WTP to AC, the data
                has the following format:

                IEEE 802.11 Frame Info:
                 0                   1           
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     RSSI      |     SNR       |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |           Data Rate           |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  RSSI: RSSI is a signed, 8-bit value.  It is the
                        received signal strength indication, in dBm.

                  SNR: SNR is a signed, 8-bit value.  It is the signal
                        to noise ratio of the received IEEE 802.11 frame,
                        in dB.

                  Data Rate: The data rate field is a 16-bit unsigned
                        integer value.  The contents of the field is set
                        to 1/10th of the data rate of the packet received
                        by the WTP.  For instance, a packet received at
                        5.5Mbps would be set to 55, while 11Mbps would
                        be set to 110.

                For data sent from the AC to the WTP, the data
                has the following format:

                Destination WLANs:
                 0                   1           
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |              WLAN             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  WLAN: This bit vector indicates the WLAN ID(s) which
                        the WTP will transmit the associated frame on.
                        For instance, if a multicast packet is to be
                        transmitted on WLANs 1 and 3, bits 1 and 3 of
                        this field would be set to '1'.  Note this
                        field is to be set to zero for unicast
                        packets and is unused if the WTP is not
                        providing encryption services.

  Wireless Payload:
    The format of the wireless payload depends on the encapsulation
    mode. There are two formats defined, which are:

      802.3 Frame - this is the standard IEEE 802.3 Ethernet II frame
            (DISCUSS: this needs to be confirmed)
      802.11 native frame - DISCUSS: finish this

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

      Message Type: This field identifies the function of the CAPWAP
            control message.  The Message Type field is comprised of
            an IANA Enterprise Number and an enterprise specific message
            type number.  The first 20 bits is the enterprise number
            in network byte order, with zero being used for CAPWAP
            generic message types and the IEEE 802.11 IANA assigned
            enterprise number 13277 being used for IEEE 802.11 technology
            specific message types.  The last 12 bits is the enterprise
            specific message type number, which has a range from 0 to
            4095.

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

            Message type value = IANA Enterprise Number * 4096 +
                                  enterprise specific message type number

      Msg ID: The message ID field is used by the CAPWAP control
            application to match responses (or acknowledgements) with
            requests (or reports). The value must be monotonically
            incremented for each unique request (or report). After
            the maximum value is reached, the value wraps back to zero.
            The paired response (or acknowledgement) returns the value
            from the request (or report). 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 report). 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 report)
            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.)
        
      F: The 'F' bit field indicates if the message is the first
            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) a report and acknowledgement.
            Thus, the first is a request or report message
            (with the 'F' field set to "1"), and the second is
            a response or acknowledgement (with the 'F' field 
            set to "0"). Note, both a request and response
            (or report and acknowledgement) of a operation
            type use the same value for message type. The
            'F' bit is used to indicate which is which.
            This allows new message types to be added
            that can be processed without knowing the
            meaning of the message type. That is, when
            an unknown request message type is received,
            the response is the same message type with
            a message element indicating that the message
            type is not supported.

      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 PDU is
            64K, and thus the max length is 64K minus the size of
            the CAPWAP control header, or 64K - 8, or 65528.

  Message Elements:
    The "message elements" field contains, zero, one, or more message
    element field, which has the following format:

    Message Element:

       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 Element Type                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |  Value ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

        Message Element Type: This field identifies a message element
            of a CAPWAP control message.  The Message Element Type field
            is comprised of an IANA Enterprise Number and an enterprise
            specific message element type number.  The first 20 bits
            is the enterprise number in network byte order, with zero
            being used for CAPWAP generic message types and the
            IEEE 802.11 IANA assigned enterprise number 13277 being
            used for IEEE 802.11 technology specific message element
            types.  The 12 bits is the enterprise specific message
            element type number, which has a range from 0 to 4095.

            The value of the message element type field can be expressed
            as:

            Message element type value = IANA Enterprise Number * 4096 +
                          enterprise specific message element type number

------------------------------------------------
Use of the CAPWAP Fragmentation Control Header

Example of a Nonfragmented CAPWAP PDU

  For both data and control CAPWAP packets, CAPWAP Fragment Control
  Header has the following content:

    first, compute next CAPWAP_PDU_ID, which is
        CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x07fff;
     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   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |0 0|T|M|     CAPWAP_PDU_ID           |       0                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example of Fragmented CAPWAP PDUs

  1) Here is an example of a CAPWAP data PDU where the
     length of the CAPWAP data header and wireless payload
     will cause a single CAPWAP data packet to be greater than
     the max IP packet size for the path. Assume that
     the size of the CAPWAP data PDU is 1560 octets, which
     needs to be fragmented into a fragments of 1400 and
     160 octets.

     The first fragment would have the following CAPWAP
     fragment control header, and be followed by a
     CAPWAP data header and part of the wireless payload
     and would look like:

     first, compute next CAPWAP_PDU_ID, which is
        CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x07fff;

     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   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |0 0|0|1|     CAPWAP_PDU_ID           |       0                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    The second fragment would have the following CAPWAP
    fragment control header, and be followed by the remaining
    portion of the wireless payload and would look like:

     (Use the same value of CAPWAP_PDU_ID)
     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   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |0 0|0|0|    CAPWAP_PDU_ID            | (1400/8) = 175          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  2) Here is an example of a CAPWAP control PDU where the
     length of the CAPWAP control header and message elements
     will cause a single CAPWAP control packet to be greater
     than the max IP packet size for the path. Assume that
     the size of the CAPWAP control PDU is 1560 octets, which
     needs to be fragmented into a fragments of 1400 and
     160 octets.

     The first fragment would have the following CAPWAP
     fragment control header, and be followed by a
     CAPWAP control header and part of the message elements
     and would look like:

     first, compute next CAPWAP_PDU_ID, which is
        CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff;

     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   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |0 0|1|1|     CAPWAP_PDU_ID           |       0                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    The second fragment would have the following CAPWAP
    fragment control header, and be followed by the remaining
    portion of the wireless payload and would look like:

     (Use the same value of CAPWAP_PDU_ID)
     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   
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    |0 0|1|0|    CAPWAP_PDU_ID            | (1400/8) = 175          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  3) Example timing diagrams with fragmentation:
       Abbreviations:
         P_ID - PDU ID
         F_OFF - Fragment offset
         M - (0 - last, 1 - more packets in PDU) 

      (M=1,P_ID=56,F_OFF=0)     (M=1,P_ID=56,F_OFF=0)
   WTP----------------------->|----------------------->AC - saves frag
                              |
      (M=0,P_ID=56,F_OFF=175) | (M=0,P_ID=56,F_OFF=175)
      ----------------------->|----------------------->AC - combines
                              |                        |    and processes
                              |                        |
      (M=0,P_ID=75,F_OFF=0)   | (M=0,P_ID=75,F_OFF=0)  |
     <------------------------|<------------------------
                              |

------------------------------------------------
Use of the "Msg ID" and "Retry#" Fields for Retries

Only the control path has message retries. Since
control operations are not idempotent (that is,
are not guaranteed to return the same result
when redone), operation results (the response
or acknowledgement) to a request or report
must be cached and returned if a repeat of
the operation occurs. A repeat occurs when
1) the request (or report) is not received
(however, the receiver does not know that
the operation is being repeated)
2) the response (or acknowledgement) is
not received within the expected operation
round trip time.
3) the request (or report) is duplicated by
the network (this only occurs when the
control operation is not protected by DTLS)

NOTE: Retries cannot be done be resending saved
UDP packets, since DTLS discards duplicates.
Thus, when each retry requires generation of
a new DTLS message (which means that DLTS
must yet again perform the hash for the message
integrity check, and the encryption of the
CAPWAP PDU)!

Here are timing diagrams for 4 cases:

    Abbreviations:
      P_ID - PDU ID
      M_ID - MSG ID
      R - Retry number

  0) No timeout/replay/duplication:
      (P_ID=56, M_ID=23, R=0)   (M_ID=23, R=0)
   WTP----------------------->|----------------------->AC - process
                              |                        |    and cache
      (M_ID=23, R=0)          | (P_ID=75,M_ID=23,R=0)  |    for M_ID=23
     <------------------------|<------------------------    and R=0
                              |

    NOTEs: 1) AC and WTP have different spaces for P_ID. It
                is used only for CAPWAP PDU fragmentation reassembly.
           2) The P_ID is always incremented for each CAPWAP PDU,
                even for retries
           3) the M_ID from a request (or report) is
                echoed in a paired response (or acknowledgement)
           4) each originator of an operation has an independent
                M_ID number space

  1) message never received, so resent:
      (P_ID=56, M_ID=23, R=0)    
   WTP----------------------->|-->X                    AC
    |                         |
    |timeout                  |
    V (P_ID=57, M_ID=23, R=1) |
  retry---------------------->|----------------------->AC - process
                              |                        |    and cache
      (M_ID=23, R=1)          | (P_ID=75,M_ID=23, R=1) |    for M_ID=23
     <------------------------|<------------------------    and R=1

    NOTEs: 1) the M_ID is not incremented on retries
           2) the R always starts at zero for each M_ID and
                is incremented on retries

  2a) message response (or acknowledgement) never received,
        so message resent:
      (P_ID=56, M_ID=23, R=0)    (M_ID=23, R=0)            
   WTP----------------------->|----------------------->AC - process
    |                         |                        |    and cache
    |                         |  (P_ID=75,M_ID=23,R=0) |    for M_ID=23
    |                     X<--|<------------------------    and R=0
    |timeout                  |
    V (P_ID=57, M_ID=23, R=1) |  (M_ID=23, R=1)
  retry---------------------->|----------------------->AC - find in 
                              |                        |    cache for 
      (M_ID=23, R=1)          |  (P_ID=76,M_ID=23,R=1) |    M_ID=23,
     <------------------------|<------------------------    update R=1

    NOTEs: 1) only the M_ID is searched in the cache for a match
                (the R is saved, but not used in search)
           2) the R from the request message is returned
                in the response message
           3) the R is updated in the cache 

  2b) message response (or acknowledgement) not received within
        the current computed value for round trip operation
        time, so a message resent. However, original response
        received before response to retry.

      (P_ID=56, M_ID=23, R=0)    (M_ID=23, R=0)            
   WTP----------------------->|----------------------->AC - process
    |                         |                        |    and cache
    |                         |  (P_ID=75,M_ID=23,R=0) |    for M_ID=23
    |                         |/------------------------    and R=0
    |timeout                  ||
    V (P_ID=57, M_ID=23, R=1) ||  (M_ID=23, R=1)
  retry---------------------->|+---------------------->AC - find in 
                              ||                       |    cache for
      (M_ID=23, R=0)          ||                       |    M_ID=23,
     <------------------------|/                       |    update R=1
   update RTOT(drop)          |                        |
                              |                        |
      (M_ID=23, R=1)          |  (P_ID=76,M_ID=23,R=1) |
     <------------------------|<------------------------ 
   update RTOT(process)

    NOTEs: 1) without the R field, cannot determine if the
                first received response was from the first
                time the request was made, or from a 
                retry. Without knowing which, cannot
                accurately update the round trip
                operational time.
           2) it is possible to process the first response
                and not drop it, but if so, must remember
                the time when sent each retry. If max retries
                not too many, then not much of a cost. 
                a match (the R is not saved or searched)

  3) message request (or report) is duplicated by the
        network:
      (P_ID=56, M_ID=23, R=0)    (M_ID=23, R=0)            
   WTP----------------------->|----------------------->AC - process
                     \        |                        |    and cache
     (M_ID=23, R=0)   \       |  (P_ID=75,M_ID=23,R=0) |    for M_ID=23
    <------------------+------|<------------------------    and R=0
                        \     | 
                         \    |  (M_ID=23, R=0)
                      Dup \-->|+---------------->X
                              |          DTLS determines it
                              |          is a dup from DTLS
                              |          header and drops.
                              |          AC process doesn't
                              |          get "application data"

    NOTE: 1) The DTLS determines that message is
             a duplicate and drops it. For broken
             DTLS stacks that return the application
             data:
             a) the R field in the duplicated message can
                be used by the AC to determine if the request
                is a duplicate.
             b) if both a response drop (or delay) and
                a duplicate occurs the R may be less
                than the R in the cache. If so, the
                message is a very delayed duplicate
                and can be dropped.

----- the end

Enjoy,
/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