Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec

From: <[email-masked]>
Date: Fri, 8 Aug 2008 00:08:00 +0300

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 7 Aug 2008 16:23:35 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 07, 2008 2:08 PM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: Issue 171: Pasi nits on binding spec

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

Well... We are 2007, and I'm not sure how much we need to care about
hardware out there that is unable to support IEEE 802.11-2007. If there
is ever a new IEEE standard for securing, then the list of IEs would
have to change, but that would be post IEEE 802.11-2007 anyhow. The
CAPWAP specification could publish an updated set of rules of what IEs
need to be present.

<snip>

> I'm fine with either approach.

I've chosen the latter, so the text now reads:

<new text>
   Key Status:   A 1 byte value that specifies the state and usage of
      the key that has been included.  Note this field is ignored if the
      Key Length field is set to zero (0).  The following values
      describe the key usage and its status:
</new text>

<snip>

Oh, I see. Well, that makes sense. Here is the new text:

<new text>
6.20.  IEEE 802.11 Update Station QoS
[...]
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |   DSCP Tag    | Reserved|8021p|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Reserved:   All implementations complying with this protocol MUST set
      to zero any bits that are reserved in the version of the protocol
      supported by that implementation.  Receivers MUST ignore all bits
      not defined for the version of the protocol they support.

   8021p:   The three bit 802.1p priority value to use if packets are to
      be IEEE 802.1p tagged.
</new text>

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

Ditto

<snip>
> > > clarifying what packets are meant (I guess it means CAPWAP Data 
> > > packets sent from the WTP to the AC?).
> > 
> > New text:
> > <new text>

Hmmm... Should have read: "applied to packets received at the WTP from
the station."

> 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)
I am proposing adding the following sentence to both sections 6.20 and
6.22:

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

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

Understood, but IEEE 802.11-2007 still requires the AP support it.

PatC

---

From: <[email-masked]>
Date: Fri, 8 Aug 2008 14:17:26 +0300

Pat Calhoun wrote:

> > 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)?
> 
> hardware out there that is unable to support IEEE 802.11-2007. If
> there is ever a new IEEE standard for securing, then the list of IEs
> would have to change, but that would be post IEEE 802.11-2007
> anyhow. The CAPWAP specification could publish an updated set of
> rules of what IEs need to be present.

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?

BTW, how are you planning to update these rules without breaking
backwards compatibility?

<snip>
> 6.20.  IEEE 802.11 Update Station QoS

Here DSCP Tag should be 6 bits, not 8.

<snip>
> Hmmm... Should have read: "applied to packets received at the WTP from

In this case, it seems both "Update Station QoS" and "WTP Quality of
Service" message elements apply to same packets -- how do they
interact?

How does the tagging work (or not work) if the 'C' bit in IEEE 802.11
Station Session Key message element is set?

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.

>    station, as well as the CAPWAP tunnel, if the packets are 
>    tunneled to the AC.
> </new text>

The comment above about 'C' bit and DSCP Tag applies here as well...

<snip>
> Understood, but IEEE 802.11-2007 still requires the AP support it.

If I'm reading IEEE 802.11-2007, Section A.4.4.1 correctly, it
seems supporting WEP is optional...?

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 12:08:21 -0700

> > would have to change, but that would be post IEEE 802.11-2007
anyhow. 
> > The CAPWAP specification could publish an updated set of rules of
what 
> > IEs need to be present.
implements?

Yup - my bad. Now include a reference to the WMM web page on
www.wi-fi.org.

backwards compatibility?

There are a couple of ways, but the most obvious one would be to have
the next binding use a new Wireless Binding Identifier (WBID).

> Here DSCP Tag should be 6 bits, not 8.

OK, here is the packet format:

<new text>
</new text>

> > > > > 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>
> > > 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?)
> > 
Service" message elements apply to same packets -- how do they interact?

I have added addition verbage to make this clearer:

<new text>

   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.

[...]

   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>

Station Session Key message element is set?
Well.. If that's the case, the packets inside the tunnel cannot be
modified - that would be the responsibility of the AC. I can add:

<new text>
      C:   The one bit field is set by the AC to inform the WTP that
         encryption services will be provided by the AC.  When set, the
         WTP SHOULD police frames received from stations to ensure that
         are properly encrypted as specified in the RSN Information
         Element, but does not need to take specific cryptographic
         action on the frame.  Similarly, for transmitted frames, the
         WTP only needs to forward already encrypted frames.  Since
         packets received by the WTP will be encrypted, the WTP cannot
         modify the contents of the packets, including modifying the
         DSCP markings of the encapsulated packet.  In this case, this
         function would be the responsibility of the AC.
</new text>

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

> > > mean the tagging is applied to the headers received by the WTP, or

> > > to the headers added by WTP for CAPWAP data tunneling?

I think this comment is now handled above.

> If I'm reading IEEE 802.11-2007, Section A.4.4.1 correctly, it seems
supporting WEP is optional...?

Yes, I see PC2 as optional, but all of the sub-elements are being
mandatory. I suppose I should read this as those sub-elements are
required only if WEP was implemented. We could fix this problem by
allocated another bit in section 8.1, alongside TKIP and AES. Note that
this would reduce the total number of bits available for the whole
protocol, unless we do something to address issue 172.

PatC

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 14 Aug 2008 10:38:31 -0700

Just realized I forgot to include the text for the DSCP issue being 6,
not 8 bits:

<new text>
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |RSV| DSCP Tag  | Reserved|8021p|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]

   RSV:   All implementations complying with this protocol MUST set to
      zero any bits that are reserved in the version of the protocol
      supported by that implementation.  Receivers MUST ignore all bits
      not defined for the version of the protocol they support.

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Wednesday, August 13, 2008 12:08 PM
To: [email-masked]; [email-masked]
Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec

anyhow. 
what 
implements?

backwards compatibility?

> > 6.20.  IEEE 802.11 Update Station QoS [...]
> >       0                   1                   2                   3

<new text>
</new text>

<new text>

[...]

<new text>

PatC

---

From: <[email-masked]>
Date: Mon, 18 Aug 2008 23:09:34 +0300

> Yup - my bad. Now include a reference to the WMM web page on

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

> the next binding use a new Wireless Binding Identifier (WBID).

With a 5-bit WBID field, and lots of activity in the 802.11xy/16xy
space, this could mean running out of WBIDs...
<snip>

<snip>
>    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?)

>    well as the CAPWAP tunnel, if the packets are tunneled to the AC.

Same ambiguity here; perhaps instead of repeating the detail,
a pointer to 6.20 woul be sufficient.

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

Best regards,
Pasi

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 08:52:30 -0700

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>

something like this?
> 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>

> > sent
> >    MUST be directly applied to the packets receive from the station,

> > as
> 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
> 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

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 22:55:07 +0300

>    of these two specifications.

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

>    by sending the IEEE 802.11 Update Station QoS message element (see

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

>    whether Split or Local MAC is used, the 802.1Q header processing is

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 16:53:31 -0700

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

Correct - made the change. Thanks!

<snip>
> > > 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).
> > > 
was
> > OK - clearly we need to provide more clarity, so I have created a
new 

> > rules properly, and I have tried to be explict below about the 
can 
> > be blind about this, and simply leave out the text and allow 
if 
> > you believe this would be more acceptable to the IESG. But like it
or 
> > not, we can't change reality.
> 
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?)
> 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.)
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?
> 802.11 Station Session Key message element is set).

OK, so you have raised many very valid points, and instead of addressing
them one by one, I will simply include the updated text. I believe that
there are now changes to section 2.6 that will address your specific
concerns, and it also includes clarity across the use of WMM. I am also
going better judgement here and breaking backward interoperability
because you raised a valid point that having a single tag for the
station is not sufficient given that the WTP policy has one per QoS
class. So I have modified the per station policy message element to
include all four. Finally, I have introduced a new bit in the WTP policy
which simply states that the station's marking is to be trusted, which
means that the WTP is not to remark any packets received.

The new text reads:

<whole bunch 'o new text>
2.6.  Quality of Service

   The IEEE 802.11 WTP Quality of Service message element's Tag Packet
   field indicates how the packets are to be tagged; either via 802.1Q
   or DSCP.  When an IEEE 802.11 Update Station QoS message element is
   received, while the specific "802.1p Tag" or DSCP values may change
   for a given station, the original policy of whether 802.1p or DSCP is
   to be used continues to be enforced by the WTP.

   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.  Note this
   tagging is only valid for interface that support 802.1p.  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, if the 'T' bit in the IEEE 802.11 WTP
   Quality of Service message element's Tag Packet field is not set, the
   WTP MUST re-mark the DSCP field of any IPv4 or IPv6 packets based
   either on the default policy, known through the IEEE 802.11 WTP
   Quality of Service message element, or a station specific policy,
   known through the IEEE 802.11 Update Station QoS message element.  If
   the 'T' bit in the IEEE 802.11 WTP Quality of Service message
   element's Tag Packet field is set, the WTP MUST trust the marking
   sent by the station.  Note that in Split MAC mode, the WTP cannot re-
   mark the DSCP field of the station's IPv4 or IPv6 packets if
   encryption is performed at the AC (see Section 6.15).

   Note additional per flow QoS policies MAY exist if the station had
   requested special QoS treatment through the TSPEC information element
   found in the IEEE 802.11-2007's QoS Action Frame.  Note that stations
   MAY also use the WiFi Alliance's WMM specification instead to request
   QoS treatment for a flow (see [WMM]).  This requires the WTP to
   observe the Status Code in the IEEE 802.11-2007 and WMM QoS Action
   ADDTS responses from the AC, and provide the services requested in
   the TSPEC information element.  Similarly, the WTP MUST observe the
   Reason Code information element in the IEEE 802.11-2007 and WMM QoS
   Action DELTS responses from the AC by removing the policy associated
   with the TSPEC.
[...]
6.20.  IEEE 802.11 Update Station QoS

   the CAPWAP tunnel, if the packets are tunneled to the AC.  See
   Section 2.6 for more information.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |       QoS Sub-Element...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1043 for IEEE 802.11 Update Station QoS

   Length:   8

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP

   MAC Address:   The station's MAC Address.

   QoS Sub-Element:   The IEEE 802.11 WTP Quality of Service message
      element contains four QoS sub-elements, one for every QoS profile.
      The order of the QoS profiles are Voice, Video, Best Effort and
      Background.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Reserved|8021p|RSV| DSCP Tag  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved:   All implementations complying with this protocol MUST
         set to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      8021p:   The three bit 802.1p priority value to use if packets are
         to be IEEE 802.1p tagged.

      RSV:   All implementations complying with this protocol MUST set
         to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      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]).
[...]
6.22.  IEEE 802.11 WTP Quality of Service

   See Section 2.6 for more information.

        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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |   Tag Packets |       QoS Sub-Element ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1045 for IEEE 802.11 WTP Quality of Service

   Length:   34

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP

   Tag Packet:   A bit field indicating whether CAPWAP packets should be
      tagged for QoS purposes.  The field has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reservd|T|D|P|U|
        +-+-+-+-+-+-+-+-+

      Reserved:  A set of reserved bits for future use.  All
         implementations complying with this protocol MUST set to zero
         any bits that are reserved in the version of the protocol
         supported by that implementation.  Receivers MUST ignore all
         bits not defined for the version of the protocol they support.

      T:   When set, this indicates that any QoS markings on packets
         received from stations are to be trusted and honored.

      D:   When set, this indicates that the CAPWAP packets should be
         tagged for QoS purposes using DSCP.

      P:   When set, this indicates that the CAPWAP packets should be
         tagged for QoS purposes using 802.1p.

      U:   When set, this indicates that the CAPWAP packets should be
         untagged.  When set, both the D and P bits MUST NOT be set.

   QoS Sub-Element:   The IEEE 802.11 WTP Quality of Service message
      element contains four QoS sub-elements, one for every QoS profile.
      The order of the QoS profiles are Voice, Video, Best Effort and
      Background.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Queue Depth  |             CWMin             |     CWMax     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     CWMax     |     AIFS      | Reserved|8021p|RSV| DSCP Tag  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Queue Depth:   The number of packets that can be on the specific
         QoS transmit queue at any given time.

      CWMin:   The Contention Window minimum (CWmin) value for the QoS
         transmit queue.  The value of this field comes from the IEEE
         802.11 dot11EDCATableCWMin MIB element (see
         [IEEE.802-11.2007]).

      CWMax:   The Contention Window maximum (CWmax) value for the QoS
         transmit queue.  The value of this field comes from the IEEE
         802.11 dot11EDCATableCWMax MIB element (see
         [IEEE.802-11.2007]).

      AIFS:   The Arbitration Inter Frame Spacing (AIFS) to use for the
         QoS transmit queue.  The value of this field comes from the
         IEEE 802.11 dot11EDCATableAIFSN MIB element (see
         [IEEE.802-11.2007]).

      Reserved:   All implementations complying with this protocol MUST
         set to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      8021p:   The three bit 802.1p priority value to use if packets are
         to be IEEE 802.1p tagged.

      RSV:   All implementations complying with this protocol MUST set
         to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      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]).
</whole bunch 'o new text>

My apologies for the multiple round trips, but I have to admit
understanding your issues is really helping improve the quality of the
specification, so I appreciate the time you are putting into this.

Does the above address your comments?

PatC

---

From: <[email-masked]>
Date: Mon, 25 Aug 2008 13:16:15 +0300

Pat Calhoun wrote:

> OK, so you have raised many very valid points, and instead of
> addressing them one by one, I will simply include the updated
> text. I believe that there are now changes to section 2.6 that will
> address your specific concerns, and it also includes clarity across
> the use of WMM.  I am also going better judgement here and breaking
> backward interoperability because you raised a valid point that
> having a single tag for the station is not sufficient given that the
> WTP policy has one per QoS class. So I have modified the per station
> policy message element to include all four. Finally, I have
> introduced a new bit in the WTP policy which simply states that the
> station's marking is to be trusted, which means that the WTP is not
> to remark any packets received.
> 
> The new text reads:
> 
>    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 IEEE 802.11 WTP Quality of Service message element's Tag
>    Packet field indicates how the packets are to be tagged; either
>    via 802.1Q or DSCP.  When an IEEE 802.11 Update Station QoS
>    message element is received, while the specific "802.1p Tag" or
>    DSCP values may change for a given station, the original policy
>    of whether 802.1p or DSCP is to be used continues to be enforced
>    by the WTP.
> 
>    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.  Note
>    this tagging is only valid for interface that support 802.1p.
>    Regardless of whether Split or Local MAC is used, the 802.1Q
>    header processing is identical.
>
>    header.  For both Split and Local MAC, if the 'T' bit in the IEEE
>    802.11 WTP Quality of Service message element's Tag Packet field
>    is not set, the WTP MUST re-mark the DSCP field of any IPv4 or
>    IPv6 packets based either on the default policy, known through
>    the IEEE 802.11 WTP Quality of Service message element, or a
>    station specific policy, known through the IEEE 802.11 Update
>    Station QoS message element.  If the 'T' bit in the IEEE 802.11
>    WTP Quality of Service message element's Tag Packet field is set,
>    the WTP MUST trust the marking sent by the station.  Note that in
>    Split MAC mode, the WTP cannot re-mark the DSCP field of the
>    station's IPv4 or IPv6 packets if encryption is performed at the
>    AC (see Section 6.15).

I'm not sure "WTP MUST trust" is best possible phrasing; in this case,
the WTP doesn't use the value for anything, so it doesn't really
"trust" it (any more than it "trusts", say, the destination IP address
field).

If it would copy the inner DSCP Tag to CAPWAP data plane tunnel's IP
header, then "trust" might be appropriate... but I case this wasn't
intended? So the intended logic would be:

D=1 and T=1: mark data plane tunnel's IP header (with DSCP value
  from this message element, not from inner IP header); don't change
  the inner IP header sent by STA.
D=1 and T=0: mark data plane tunnel's IP header (with DSCP value
  from this message element, not from inner IP header); also replace
  the DSCP field in the inner IP header with this value (if it's
  IPv4/IPv6, and encryption isn't done in WTP)
D=0 and T=0: use default DSCP value for data plane tunnel's IP
  header; don't touch the inner IP header.
D=0 and T=1: use default DSCP value for data plane tunnel's IP 
 header; don't touch the inner IP header

Or are the D/T bits supposed to be orthogonal, so the last
case would replace the DSCP field in the inner header?

(BTW -- this discussion about DSCP reminded me that the spec doesn't
say anything about the ECN bits...)

>    Note additional per flow QoS policies MAY exist if the station
>    had requested special QoS treatment through the TSPEC information
>    element found in the IEEE 802.11-2007's QoS Action Frame.  

This "MAY" seems to describe a logical possibility, not an optional
feature, so it probably should be lowercase "may" (or perhaps "can").

>    Note that stations MAY also use the WiFi Alliance's WMM
>    specification instead to request QoS treatment for a flow (see
>    [WMM]).  This requires the WTP to observe the Status Code in the
>    IEEE 802.11-2007 and WMM QoS Action ADDTS responses from the AC,
>    and provide the services requested in the TSPEC information
>    element.  Similarly, the WTP MUST observe the Reason Code
>    information element in the IEEE 802.11-2007 and WMM QoS Action
>    DELTS responses from the AC by removing the policy associated
>    with the TSPEC.
>
> [...]

Perhaps add "This field is used only if the 'P' bit in the WTP Quality
of Service message element was set; otherwise, its contents MUST be
ignored."?

>         eligible to

Perhaps add "This field is used only if the 'D' bit in the
WTP Quality of Service message element was set; otherwise,
its contents MUST be ignored."?

>    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.  See Section 2.6 for more
>    information.
> 
>         0                   1                   2                   3

As I commented above, "trusted and honored" describes perhaps the
intent, but I'm not sure what, exactly, an implementation would do
here. IMHO this would be best phrased as talking about processing
specific header fields (adding header with value X; copying value
from one place to another; replacing an existing value).

>       The order of the QoS profiles are Voice, Video, Best Effort and

Perhaps add "This field is used only if the 'P' bit is set; otherwise,
its contents MUST be ignored"?

>          eligible to

Perhaps add "This field is used only if the 'D' bit is set; otherwise,
its contents MUST be ignored"?

> Does the above address your comments?

Almost there:)

Best regards,
Pasi