> > 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.)
Correct - made the change. Thanks!
<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).
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 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 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 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. 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
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.
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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap |