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

[Pasi.Eronen (Pasi.Eronen]

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