Subject: [Capwap] Proposed text for issue resolution

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 21 Jun 2006 23:28:43 -0700

All,

Draft -02 of the CAPWAP protocol specification will be published shortly,
and we are looking forward to resolving as many issues as possible in the
next revision, -03, tentatively targeted for late August.

With this  mail, we'd like to

(1) Thank all those who have contributed proposed text for issue resolution
to date.
We'll be sending out a list of the issues that have been resolved in -02,
and
your contributions enabled forward progress on the draft.

(2) Ask for volunteers to develop and post text reflecting
the changes that would need to be made to draft-02 to incorporate
the proposed single port and dual port alternative solutions
 (see issue 115,  "To MUX or not to MUX" and
issue 82, "UDP port assignment(s) for control and data traffic").

To date we have not seen proposed draft text
for either alternative, and would like to avoid a situation where
say at the end of July the WG has not seen and been able to review a
reasonably
 solid draft of text that would need to be incorporated. Available text
would
 also help quantify/define the work involved.

Thank you,

The editors -Pat Calhoun, Mike Montemurro, Dorothy Stanley
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 22 Jun 2006 23:34:02 -0700 (PDT)

HI,

Below is an update my earlier proposal to resolve this
problem. I believe it also cleans up fragmentation
in CAPWAP-01/02, and provides more efficient
use of CAPWAP packets. 

---------------
Proposal for CAPWAP Packet Format

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

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

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

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

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

      UDP: All CAPWAP packets are encapsulated within UDP.

      CAPWAP Pkt Header: All CAPWAP protocol packets use a short header
            that specifies the version of CAPWAP and the type of the 
            CAPWAP packet.

      CAPWAP Fragmentation Control: 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 Data Header: This header is used for CAPWAP data PDUs
            that encapsulate user data. 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 for 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 Pkt Header:
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version               | Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version - the version of the CAPWAP protocol (the first is 1)
                DISCUSS: should this be split into major and minor,
                         and if so, what are the implications of
                         an increment of the major or minor part? 

      Type - packet type, values are:
                1 - CAPWAP Unprotected Data Packet
                2 - CAPWAP DTLS Protected Data Packet
                3 - CAPWAP Unprotected Control Packet
                4 - CAPWAP DTLS Protected Control Packet
               0,5-15 - reserved

    CAPWAP Fragmentation 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.

      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.

    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.

      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       |     Length of Msg Elements    |F| Res         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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

      Message ID: This 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.
        
      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

---------------
Regards,
/david t. perkins