Subject: [Capwap] 802.11 binding doc. issues

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 10:03:34 -0700

1. 6.1
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 10:04:38 -0700

1.    6.1

The len should be >=52?

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 10:30:45 -0700

6.1

 The len should be >=52?

 4 + 4 + 32 + 4 + 4 + 4 = 52 (assume SSID to be at least 1 byte)

We have a  key length field, however,

"Key:   A 32 byte Session Key to use to provide data privacy. "

6.2

len = 5

6.3

len = 8

6.6

This is used to include only one IE? If it is, should we remove the
"..." in the figure?

Also the len is bigger than 4. The minimal len of IE is 1 ?

6.13

len >= 14

I am not sure the minimal size of supported rates. Here assume it is one.

6.14

Here the 802.1p tag is defined with 2 bytes, but other places only use
1 byte. Only the 3 least
significant bits are used.

6.15.

I am not familiar with the keys. How do you get the length value? The
minimal length of Key is 5 bytes?

6.16

len is 80

6.21

len is 40

same issue on Key as 6.1

6.22

"tag packets" is bit value? Can I set the tag the packet with both 1p
and DSCP? If I can, we need to add a
value 3.

      Immediately following the above header is the following data
      structure.  This data structure will be repeated five times; once
      for every QoS profile.  The order of the QoS profiles are Voice,
      Video, Best Effort and Background.

Here should be "four times".

Are the above mandatory? If they are, the ME len is ( 2 + 8 * 4) = 34.

7.4.  IEEE80211OFDMControl

   The WTP per radio MAC Operation configuration, defined in
   Section 6.10.

OFDM

8. Technology Specific Message Element Values

I do not know which capwap ME is talking about at here. How to use the
defined value here?

Yong

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 10:46:32 -0700

3.2.  IEEE 802.11 WLAN Configuration Response

Can we put MUST ME earlier than MAY ME for this message in the message
definition?

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 15:28:43 -0700

Created issue 145 to track this one. Responses below.

PatC

definition?

Done. We now have consistency in ordering across both docs.

> "Key:   A 32 byte Session Key to use to provide data privacy. "

Yes, that is correct and I have fixed this.

> len = 5
No, this is not correct. The Antenna Selection field will be of length
'Antenna Count'.

> len = 8

Correct.

> Also the len is bigger than 4. The minimal len of IE is 1 ?

No, the ... Implies the length of the field is variable and may be
greater than 1. I think the length is fine.

> I am not sure the minimal size of supported rates. Here assume it is
one.
Correct.

> significant bits are used.
We had agreed to leave this as is to minimize backward compatibility
issues, as per Margaret's request.

> minimal length of Key is 5 bytes?
Depends on the crypto used. The 802.11 spec is clear about this.

> len is 80
Yes

> same issue on Key as 6.1
Correct

> and DSCP? If I can, we need to add a value 3.
>
Correct - and no, only one or the other is possible at this point.

>   The WTP per radio MAC Operation configuration, defined in

Not sure what your comment is.

> defined value here?

Interesting. This was an xml bug in my source code. I have fixed it and
the new text is:
<text>
8.1.  WTP Descriptor Message Element, Encryption Capabilities Field:

   IEEE 802.11 uses the following values:

   4 - Encrypt AES-CCMP 128:   WTP supports AES-CCMP, as defined in
      [IEEE.802-11.2007].

   5 - Encrypt TKIP-MIC:   WTP supports TKIP and Michael, as defined in
      [IEEE.802-11.2007] and [WPA], respectively.
</text>

PatC

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 18:53:45 -0700

Can you tell me what prevent the taging of both 1p and dscp?

The title is OFDM, and the content is for MAC oper.

Yong

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 8 Jul 2008 05:55:51 -0700

Nothing preventing, except that we agreed a long time ago to only fix
bugs, not add new features. All of the issues we've been discussing have
been fixes - this is clearly not a fix. However, since it is a small
change from a value to a bit field, let's see what others think. This
change would allow the WTP to use both L2 and L3 QoS marking.

Just to be clear:
<old text>
6.22.  IEEE 802.11 WTP Quality of Service
[...]
   Tag Packets:   A value indicating whether CAPWAP packets should be
      tagged for QoS purposes.  The following values are currently
      supported:

      0 -  Untagged

      1 -  802.1p

      2 -  DSCP
</old text>

<new text>
6.22.  IEEE 802.11 WTP Quality of Service
[...]
   Tag Packets:   A bit field indicating whether CAPWAP packets should
be
      tagged for QoS purposes.  The following values are currently
      supported:

      0 -  Untagged

      1 -  802.1p

      2 -  DSCP
</new text>

Any disagreement on moving forward with this change?

PatC 

-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 6:54 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] 802.11 binding doc. issues

Yong

> Interesting. This was an xml bug in my source code. I have fixed it 
> and the new text is:
> <text>

---

From: "Yong Zhang" <[email-masked]>
Date: Tue, 8 Jul 2008 08:17:46 -0700

Qos Old and New are same.

Did you get the one for 7.4 IEEE80211OFDMControl?

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 8 Jul 2008 08:21:57 -0700

> Qos Old and New are same.
No, the new text states it is a bit field, which means that both 1 and 2
can be set at the same time.

> > The title is OFDM, and the content is for MAC oper.
Right, the text should have been
<text>
      The WTP per radio OFDM MAC Operation configuration, 
	defined in Section 6.10
</text>

PatC

On Tue, Jul 8, 2008 at 5:55 AM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> bugs, not add new features. All of the issues we've been discussing 
> have been fixes - this is clearly not a fix. However, since it is a 
> small change from a value to a bit field, let's see what others think.

> This change would allow the WTP to use both L2 and L3 QoS marking.
>
> Just to be clear:
> <old text>
> 6.22.  IEEE 802.11 WTP Quality of Service [...]
> 6.22.  IEEE 802.11 WTP Quality of Service [...]