Subject: Re: [Capwap] Update proposal for Packet formats

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 30 Jun 2006 15:55:22 -0700

David,

I'm not sure that I understand the justification for making all of these
rather dramatic changes to the protocol, so I'm not sure what
implementation and demonstration would buy us at the IETF. I think what
would be useful instead is to create issues that describe the actual
problem. We can change the protocol until the cows come home, but in
order to maintain some level of sanity, we need to start getting a
little more aggressive about rejecting feature requests.

One comment on the retry number, though. Both sides have to maintain
state anyways, so it's not clear to me that there is any use in this
bit. For instance what do you do if you receive a message with the
"Retry" bit set, but had never received the first one? The bit really
doesn't provide much use in this case. So in any case you need to
maintain a running counter of what's been received & processed, and we
do this through the sequence number field. The reliability part of the
CAPWAP protocol also ensures that packets are retransmitted if not
acknowledged (where your proposal would require that the packet be
re-encrypted because the Retry bit was changed).

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Sunday, June 25, 2006 10:07 PM
> To: [email-masked]
> Subject: [Capwap] Update proposal for Packet formats
> 
> HI,
> 
> In the last proposal, I remove a field used for retries. In 
> verifying whether it could be done, I found a problem. Below 
> is the updated proposal, which includes examples showing how 
> fragmentation works, and how retries work. Please let me know 
> if you have any problems. This is what I plan to have 
> implemented and demonstrate at IETF.
> 
> ---------------------------
> Proposal for CAPWAP Packet Format
> --------------------------------
> 
> 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:
> 
> 
>     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 DTLS Protected Data Packet:
>     
> +-------------------------------------[---------]--------------------+
>     | IP  | UDP | CAPWAP | DTLS  | CAPWAP | CAPWAP  | 
> Wireless | DTLS    |
>     | Hdr | Hdr | Pkt    | Hdr   | Frag   | Data    | Payload 
>  | Trailer |
>     |     |     | Hdr    |       | Ctrl   | Hdr     | Frag    
>  |         |
>     
> +-------------------------------------[---------]--------------------+
>                                            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     | Frag     |
>     +------------------------------[---------]----------+
>                                     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     | Frag     
> |         |
>     
> +------------------------------------[---------]--------------------+
>                                           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 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.
> 
>       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 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 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.)
> 
> 
>     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       | 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) & 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 0|       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) & 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   
>     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>     |1|0 0|       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|      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   
>     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>     |1|0 0|       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|      CAPWAP_PDU_ID            | (1400/8) = 175          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
> 
> ------------------------------------------------
> 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)
> 
> 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=75,M_ID=23,R=1) |    M_ID=23,
>      <------------------------|<------------------------    update R=1
> 
>     NOTEs: 1) only the M_ID is search 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=75,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 the
>                 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 \-->|+---------------------->AC - find in 
>                               |                             cache for
>                               |                             M_ID=23,
>                                                             R is the
>                                                             
> same so drop
> 
>     NOTEs: 1) the R field in the duplicated message is used
>                 by the AC to determine if the request is
>                 a duplicate.
>            2) 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.
> 
> 
> ---------------------------
> 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
> 
_________________________________________________________________
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: Fri, 30 Jun 2006 16:16:31 -0700 (PDT)

HI,

Pat, while I appreciate and share your concerns about changes,
I believe that there are serious problems in the fragmentation
and retry scheme in CAPWAP-01. (I haven't had the time to
check to see if this has changed in CAPWAP-02.) I've asked
repeatedly for some one to show a timing diagram of this and
other issues, but have not seen this. I've only seen
responses to the affect "I understand how it works and I
don't need a diagram." This type of comment does not verify
that all that have read the document have reached a common
understanding. Of course, you are well aware of IETF requiring
interoperable implementations to demonstrate common 
understanding for a standards track document to advance.

Basic issues, such as this should have been addressed and
resolved starting at the November IETF, and if needed an
interim meeting that the WG didn't have. I'm disappointed.
The problems still remain. Let's put a spotlight on the
issues and see if they are real, imaginary, or somewhere
inbetween. 

And on your specific question of a "retry bit", I quess I was
not clear, because there is NO retry bit in my packet format
proposal. 

Regards,
/david t. perkins