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

[Pat Calhoun (pacalhou) (pcalhoun]

> > > I can't find any mention of "WMM Information Element" in IEEE
> > > 802.11-2007 -- I assumed it's some extension that not everyone
> > implements?
> > 
> > Yup - my bad. Now include a reference to the WMM web page on 
> > www.wi-fi.org.
> 
> 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>

> > > In this case, it seems both "Update Station QoS" and "WTP Quality
of 
> > > Service" message elements apply to same packets -- how do they 
> > > interact?
> > 
> > I have added addition verbage to make this clearer:
> > 
> > <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 at the WTP from the station indicated
> >    through the MAC Address field.  This message element overrides
> >    the default values provided through the IEEE 802.11 WTP Quality
> >    of Service message element (see Section 6.22.  Any tagging
> >    performed by the WTP MUST be directly applied to the packets
> >    receive from the station, as well as the CAPWAP tunnel, if the
> >    packets are tunneled to the AC.
> 
> 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.

<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).

   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.

   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.
</new text>

> > 
> > [...]
> > 
> > 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
the
> >    default QoS values to be applied to packets received by the WTP 
> > from
> >    stations on a particular radio.  Any tagging performed by the WTP
> >    MUST be directly applied to the packets receive from the station,

> > as
> >    well as the CAPWAP tunnel, if the packets are tunneled to the AC.
> > </new text>
> 
> Same ambiguity here; perhaps instead of repeating the detail, a
pointer to 6.20 woul be sufficient.

I prefer to include a reference to the new section 2.6 in both 6.20 and
6.22.


> > > I'm also slightly surprised to see the WTP modifying the contents
of 
> > > IP packets here -- I thought it was acting as Layer 2 device for 
> > > user plane traffic (not making any assumptions about the Layer
> > > 3 protocol carried in 802.3 frames). At the very least, the text 
> > > should probably say the DSCP Tag applies only to packets with 
> > > certain values in the 802.3 Type field.
> > 
> > OK, I can modify the text to specifically read:
> > <new text>
> >    DSCP Tag:   The 6 bit DSCP label to use if packets are 
> >                eligible to be DSCP tagged (see [RFC2474]).
> > </new text>
> 
> IMHO it would be clearer to say "if the packet received from the STA
is an IPv4 or IPv6 packet" (if that's what's meant by "eligible to be
DSCP

OK, so I have modified the text to:

<modified text>
   DSCP Tag:   The 6 bit DSCP label to use if packets are eligible to be
      DSCP tagged, specifically an IPv4 or IPv6 packet (see [RFC2474]).
</modified text>

PatC