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:
>
> <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).
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.
>
> [...]
> 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.
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."?
> 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]).
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."?
> [...]
> 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.
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).
> 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.
Perhaps add "This field is used only if the 'P' bit is set; otherwise,
its contents MUST be ignored"?
>
> 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]).
Perhaps add "This field is used only if the 'D' bit is set; otherwise,
its contents MUST be ignored"?
> </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?
Almost there:) |