Capwap Mailing List: Re: comments on -08 base draft and .11binding-05 draft

[Pat Calhoun (pacalhou) (pcalhoun]

Here is the proposed text for issues 1 and 2 below. We agreed that issue
3 is already covered in the spec.

<base text>
4.3.  CAPWAP Header
[...]
   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.  The WBID field in the CAPWAP header is used to
      identify the format of the wireless specific information optional
      field.  The HLEN field assumes 4 byte alignment, and this field
      MUST be padded with zeroes (0x00) if it is not 4 byte aligned.

      The Wireless Specific Information field uses the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Length     |                Data...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length:  The length of the data field

      Data:  Wireless specific information, defined by the wireless
         specific binding specified in the CAPWAP Header's WBID field.
</base text>

<dot11 binding text>
4.  CAPWAP Data Message Bindings
[...]
   Optional Wireless Specific Information:  The optional CAPWAP header
      field (see Section 4.3 in [3]) is only used with CAPWAP data
      messages, and it serves two purposes, depending upon the direction
      of the message.  For messages from the WTP to the AC, the field
      uses the format described in the "IEEE 802.11 Frame Info" field
      (see below).  However, for messages sent by the AC to the WTP, the
      format used is described in the "Destination WLANs" field (also
      defined below).

      Note that in both cases, the two optional headers fit in the
      "Data" field of the Wireless Specific Information header.
</dot11 binding text> 

PatC
-----Original Message-----
From: Puneet Agarwal [mailto:pagarwal [at] broadcom.com] 
Sent: Tuesday, December 18, 2007 5:45 PM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: RE: [Capwap] comments on -08 base draft and .11binding-05 draft

Hi Pat,

Regarding # 3: I am OK with your resolution though it would not hurt to
state the padding requirements as an FYI in the -05 .11 spec.

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
Sent: Tuesday, December 18, 2007 4:44 PM
To: Puneet Agarwal
Cc: capwap
Subject: RE: [Capwap] comments on -08 base draft and .11binding-05 draft

> 1) In section 4.3 of -08 draft, the "Wireless Specific Information"
optional field has an 8-bit "Wireless ID" field. 
> There is a similar 5 bit WBID field in the main capwap header (in the
first 32 bits). Are the two same? If the two are > the same, then we
should delete the "Wireless ID" in the "Wireless Specific Information"
optional header.
Yes, I agree with this change.
 
> 2) The "Wireless Specific Information" field for .11 is described in
section 4 of the -05 .11 binding spec. Does the 
> text in section 4 "IEEE 802.11 Frame Info" describe the "data" part of
the "Wireless Specific Information" in the base 
> spec? If so, then we should clarify this in the -05 .11 spec.
Yes, I agree with this change.
 
> 3) The base spec requires that the optional elements be 4 byte
aligned. The "Wireless Specific Information" field has 2 
> bytes of "Wireless ID" + "Length which means that the "Data" part
should be 2, 6, 10 etc in length. However the .11 
> spec only defines a 4 byte "Data" part (see 2 above) which does not
meet the alignment requirements. We should change 
> the .11 binding spec and make the "Data" 6 bytes in length with the
last 2 bytes being reserved.
The CAPWAP spec already makes this very clear. Specifically, section 4.3
states:

"  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.  The HLEN field assumes 4 byte alignment, and this
      field MUST be padded with zeroes (0x00) if it is not 4 byte
      aligned."

So I do not believe any additional changes are needed to address this.

Anyone disagree with the above?

PatC