Capwap Mailing List: Re: Issue 171: Pasi nits on binding spec

[Pasi.Eronen (Pasi.Eronen]

Pat Calhoun wrote:

> > Section 6.1 and 6.21: are some of these 802.11 information elements 
> > optional, or are all of them always included?
> Always, since the text states:
> 
> <current text>
>    The inclusion of this message
>    element MUST also include the IEEE 802.11 Information 
>    Element message
>    element, containing the following 802.11 IEs:
> </current text>

Does this mean that e.g. all WTPs MUST support WMM? (since the AC MUST
always send the WMM information element) And MUST support WPA forever
(in addition to RSN)?

<snip>
> > Section 6.1 and 6.21: what do you put in "Key Status" if you're not
> > using  encryption at all?
>
> Well... Good question. The way it works is that the absence of a key
> means that the key status field is irrelevant, but perhaps it would be
> good to define a new "unused" value. However, this *could* create a
> backward compatibility problem. Alternatively, we could add text that
> simply states that this field is ignored if the key field has a zero
> length, and then it really doesn't matter what value was used.
> 
> OK?

I'm fine with either approach.

<snip>
> > Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably
> > be shown as 3 bits in the diagram, to make it unambiguous about
> > which bits are not used.

> Well... That would truncate a packet on a non-byte boundary. Do you
> really believe that would help clear things up?

No need to truncate the packet on a non-byte boundary; just show where
the unused padding bits are. Something like this ("Z" is unused):

    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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MAC Address          |Z|Z| DSCP Tag  |Z|Z|Z|Z|Z|8021p|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or this:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MAC Address          | DSCP Tag  |Z|Z|Z|Z|Z|Z|Z|8021p|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


or this:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MAC Address          | DSCP Tag  |Z|Z|8021p|Z|Z|Z|Z|Z|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

depending on which you meant...

<snip>
> > Sections 6.20 and 6.22: the DSCP Tag field should probably be
> > shown as 6 bits in the diagram, to make it unambiguous how it's
> > sent in IPv4/IPv6 header (and which bits are unused).
> 
> See above. I think showing fragments of a byte is even harder to
> understand. I have never seen RFCs to that.

See above.

<snip>
> > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would
> benefit of 
> > clarifying what packets are meant (I guess 
> > it means CAPWAP Data packets sent from the WTP to the AC?).
> 
> New text:
> <new text>
> 6.20.  IEEE 802.11 Update Station QoS
> 
>    The IEEE 802.11 Update Station QoS message element is used 
>    to change
>    the Quality of Service policy on the WTP for a given station.  The
>    QoS tags included in this message element are to be applied to
>    packets received by the station.

By "packets received by the station", do you mean "packets sent by the
WTP to the station"? (In this case, including DSCP here is slightly
unexpected -- those packets aren't necessarily even IP?)

> [...]
> 6.22.  IEEE 802.11 WTP Quality of Service
> 
>    The IEEE 802.11 WTP Quality of Service message element value is
>    sent by the AC to the WTP to communicate quality of service
>    configuration information.  The QoS tag included in this message
>    element are to be applied to packets received by the WTP from
>    station on a particular radio.
> </new text>

By "applied to packets received by the WTP from the station",
do you mean the tagging is applied to the headers received by the 
WTP, or to the headers added by WTP for CAPWAP data tunneling?
(If it's the former, the comment above about DSCP applies)

<snip>
> > Section 8.1: WEP is missing from the list?
> 
> Given that WEP was introduced so long ago, it was just assumed that
> WTPs support it. However, with TKIP and AES possibly requiring
> changes to the ASIC, we wanted to allow WTPs to advertise these
> capabilities.

Well, some new WTPs might decide *not* to support WEP anymore -- 
perhaps not yet, but five year from now..? (But if support of WEP
is required, the document should say so)

Best regards,
Pasi