Pat Calhoun wrote:

> > So the current binding isn't just IEEE Std 802.11-2007, but
> > 802.11-2007 plus some Wi-Fi Alliance spec?  (That OK with me, but
> really needs to be said in the introduction section.)
> 
> OK, then I have added the following paragraph to the introduction:
> 
> <new text>
> 1.  Introduction
> [...]
>    In order to address immediate market needs for standards 
>    still being
>    developed by the IEEE 802.11 standards body, the WiFi Alliance
>    created interim pseudo-standards specifications.  Two such
>    specifications are widely used in the industry, namely the WiFi
>    Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications.
>    Given their widespread adoption, this CAPWAP binding 
>    supports the use
>    of these two specifications.
> </new text>

"Requires" instead of "supports", right? (Since it's mandatory to include the 
WPA and WMM information elements in the IEEE 802.11 Add WLAN message element.)

<snip>
> > I think the tagging text still needs some details. Is the intent 
> > something like this?
> > 
> > 1. If doing split MAC with native frame tunnel mode (instead of
> >    802.3): 
> >    replace the TID subfield of the packet with the "802.1p 
> >    Tag" value 
> >    (except if 'C' bit in IEEE 802.11 Station Session Key message
> >    element is set)
> > 2. If doing local MAC: if the WTP adds an 802.1Q header for VLAN use
> >    (based on VLAN Name in the Add Station message element), place 
> >    the "802.1p Tag" value in the 802.1Q header.
> > 3. If doing split MAC: if the WTP adds an 802.1Q header for VLAN  
> >    use (based on e.g. some local configuration), place the 
> >    "802.1p Tag" value in the 802.1Q header.
> > 4. If the packet received from the STA is an IPv4 or IPv6 packet, 
> >    replace the DSCP field in the IP header with the "DSCP Tag" 
> >    value (except if 'C' bit is set)
> > 5. For split MAC, place the "DSCP Tag" value in the IP header 
> >    added by the WTP for CAPWAP Data message.
> > 
> > Note that here step 1 seems unnecessary -- replacing the TID before 
> > the AC sees it doesn't seem to add value -- and step 4 is very 
> > likely to raise questions in IESG review (as it overwrites the DSCP 
> > tagging done by the STA).
> > 
> > (But perhaps I understood this wrong, and some other processing was
> > intended?)
> 
> OK - clearly we need to provide more clarity, so I have created a new 
> section 2.6, which I include below. I believe that you have read the 
> rules properly, and I have tried to be explict below about the 
> treatment of QoS at the WTP. I am unsure why the IESG would have 
> issues with option 4, because whether we like it or not, enterprise 
> networks do not necessarily trust DSCP markings from endpoints. We can 
> be blind about this, and simply leave out the text and allow 
> manufacturers do what they do today (which is allow for remarking), if 
> you believe this would be more acceptable to the IESG. But like it or 
> not, we can't change reality.

I'm not disagreeing that replacing the DSCP tag can be useful in some 
circumstances -- but it might be useful to allow *not* replacing it, while 
still tagging the IP header added by the WTP.

> <new text>
> 2.6.  Quality of Service
> 
>    The CAPWAP IEEE 802.11 binding specification provides procedures to
>    allow for the WTP to enforce Quality of Service.  This section will
>    detail the actual procedures for both Split and Local MAC.
> 
>    When the WLAN is created on the WTP, a default Quality of Service
>    policy through the IEEE 802.11 WTP Quality of Service 
>    message element
>    (see Section 6.22).  This default policy will cause the WTP to use
>    the default QoS values for any station associated with the WLAN in
>    question.  The AC MAY also override the policy for a given station,
>    by sending the IEEE 802.11 Update Station QoS message element (see
>    Section 6.20).

The "WTP QoS" message element allows different 802.1p Tags and DSCP Tags for 
e.g. Voice and Background traffic; the "Update Station QoS"
element doesn't. Is this mismatch intentional? Does the latter override all 
the QoS profiles?

The "WTP QoS" message element also has a bit field saying whether to do 802.1p 
tagging, DSCP tagging, or both (or neither).  The "Update Station QoS" element 
doesn't have such bit field -- how does this work? (Is e.g. the bit field 
for "WTP QoS" message element used -- meaning that the DSCP field in "Update 
Station QoS" is ignored if the DSCP bit wasn't set in "WTP QoS", or something 
else?)

>    Both message elements provide an "802.1p Tag", which is used by the
>    WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the
>    priority field set according to the policy provided.  Regardless of
>    whether Split or Local MAC is used, the 802.1Q header processing is
>    identical.

Does the WTP always add the 802.1Q header when doing Local MAC?
(Even when bridging traffic to an untagged port?)

For Split MAC, it obviously does not always add an 802.1Q header (the IP 
packets to the AC could be sent over any interface, not just those in 802.* 
family), so the processing needs some clarification.
But if it's e.g. wired Ethernet, is the WTP *required* to add an 802.1Q header 
with this value? (the WTP is working as an ordinary host, not bridge, on this 
interface...)

(My lack of knowledge about 802.1Q is probably showing -- but I think the spec 
needs to be clear here what's the required behavior, and what's just advice.)

>    Both message elements also provide a "DSCP Tag", which is used by
>    the WTP to use in the DSCP field of bot the IPv4 and IPv6 headers
>    (see [RFC2474]).  When the WTP operates in a Split MAC mode, the
>    DSCP markings are used in the CAPWAP data plane tunnel's IP
>    header.  For both Split and Local MAC, the DSCP value SHOULD be
>    used as a default policy by the WTP to override any markings
>    received by the station in its IPv4 or IPv6 packets.  Note that
>    the use of WMM (see [WMM]) allows the station to request special
>    QoS treatment for a given flow.

I don't know much about WMM, but "SHOULD" sounds a bit problematic here -- 
probably the AC should tell the WTP what to do? (In some deployments, DSCP 
Tags set by the hosts might be meaningful and sufficiently trustworthy, so the 
AC administrator should be able to decide whether they're overwritten or not, 
right?)

Also, I'm not sure I understand the "be used as a default policy... to 
override". Something like "is used to override" would be clear, but "default 
policy" is probably referring to some WMM feature related to DSCP tagging?

(Also, the text should say this doesn't apply when the 'C' bit in IEEE
802.11 Station Session Key message element is set).

Best regards,
Pasi