Created on 2008-07-30.23:30:58 by pcalhoun, last changed 2008-09-10.22:01:10 by pcalhoun.
|
| msg534 (view) |
Author: pcalhoun |
Date: 2008-09-10.22:01:10 |
|
Fixed in draft-ietf-capwap-protocol-specification-12.txt
|
| msg521 (view) |
Author: pcalhoun |
Date: 2008-08-25.21:57:29 |
|
I forgot to addess one more of your comments:
> (BTW -- this discussion about DSCP reminded me that the spec doesn't
> say anything about the ECN bits...)
That was in fact intentional. The LWAPP and CAPWAP specs never got into
specifying how the ECN bits are to be used. I would recommend that we leave
the use of ECN for a subsequent version of the protocol. At this point we can
either continue to be silent about it, or simply add a statement at the end of
section 2.6.1.2 to the effect of:
<possible text>
The CAPWAP protocol does not make use of ECN [RFC3168], therefore the ECN bits
in the DSCP field MUST be set to zero (Not-ECT).
</possible text>
|
| msg520 (view) |
Author: pcalhoun |
Date: 2008-08-25.21:57:22 |
|
Hi Pasi,
You had the following comment:
> 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?
and
> > 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).
OK, this is a valid comment, so I have accepted all of your proposed text
changes and modified the following text to address the issues you have raised
<modified text>
2.6. CAPWAP Data Channel QoS Behavior
The CAPWAP IEEE 802.11 binding specification provides procedures to
allow for the WTP to enforce Quality of Service on IEEE 802.11 Data
Frames and MAC Management messages.
2.6.1. IEEE 802.11 Data Frames
When the WLAN is created on the WTP, a default Quality of Service
policy is established 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), known as a station specific QoS policy.
Beyond the default, and per station QoS policy, the IEEE 802.11
protocol also allows a station to request special QoS treatment for a
specific flow through the TSPEC information elements found in the
IEEE 802.11-2007's QoS Action Frame. Alternatively, 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.
The IEEE 802.11 WTP Quality of Service message element's Tagging
Policy field indicates how the packets are to be tagged, via the 'P'
bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not tag). The
Tagging Policy also includes the 'T' bit, which is used to inform the
WTP to not modify any markings set by the station. The expected
behavior of these bits is specified below. 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 Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits)
remains the same.
2.6.1.1. 802.1p Support
The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
QoS 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 interfaces that support 802.1p. The actual
treatment is identical in both Split and Local MAC mode, except that
the former requires the 802.1Q header to be added to the station's
packet vs. the outer packet header. The following options are
possible:
P=1, T=0: The WTP marks the priority field in the 802.1Q header,
which is added to the station's packet or outer packet header, to
either the default, or the station specific DSCP policy.
P=1, T=1: The WTP marks the priority field in the 802.1Q header,
which is added to the station's packet or outer packet header, to
the value found in User Priority field of the QoS Control field of
the IEEE 802.11 header. If the QoS Control field is not present
in the IEEE 802.11 header, then the packet is handled as defined
in the above option.
P=0, T=0: The WTP sets the priority field in the 802.1Q header to
zero (0), if present. This bit combination MUST NOT be set if the
'U' bit is not set.
P=0, T=1: This is an invalid bit combination.
Note that if the 'U' bit was set, then the WTP MUST NOT set the
802.1Q header's priority field. Note that in this case, the 'P', 'D'
and 'T' bits MUST NOT be set.
2.6.1.2. DSCP Support
The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
QoS message elements also provide a "DSCP Tag", which is used by the
WTP when the 'D' bit is set to mark the DSCP field of both the IPv4
and IPv6 headers (see [RFC2474]). Unlike 802.1p, the WTP can mark
either the inner packet (the original packet received by the
station), or the outer packet's IP header. If the 'D' bit is not
set, the WTP MUST NOT mark either the inner or outer packet's IP
header's DSCP field.
Assuming the 'D' bit is set, the treatment of the packet differs
based on whether the WTP is operating in a Split or Local MAC mode.
For Local MAC mode, the WTP does not tunnel packets to the AC, and
there is therefore no outer packet to mark. In this case, there are
three possible mode of operations:
D=1, T=0: The WTP re-marks the DSCP field in the station's packet
to either the default, or the station specific DSCP policy.
D=1, T=1: The WTP does not modify the DSCP field in the station's
packets.
D=0, T=0: The WTP sets the DSCP field in the station's packet to
zero (0). This bit combination MUST NOT be set if the 'U' bit is
not set.
D=0, T=1: This is an invalid bit combination.
For Split MAC mode, the WTP needs to contend with both the inner
packet (the station's original packet), as well as the tunnel header
(added by the WTP). In this mode of operation, there are two
options:
D=1, T=0: The WTP marks the outer header's DSCP field based on
either the default or the station specific DSCP policy.
Similarly, the WTP also re-marks the inner packet header's DSCP
field to the same DSCP value. If encryption services are provided
by the AC (see Section 6.15), the WTP does not modify the inner
packet.
D=1, T=1: The WTP marks the outer header's DSCP field based on the
value set in the inner packet header's DSCP field. Further the
WTP does not modify the inner packet header's DSCP field. This
option is invalid if the AC is providing encryption services,
since the inner packet would be encrypted, and therefore not
modifyable by the WTP. If this option is set while the AC is
providing encryption services, the WTP must provide the services
defined in the "D=1, T=0" option.
D=0, T=0: The WTP sets the DSCP field of the inner and outer packet
header to zero (0). If encryption services are provided by the
AC, the WTP MUST NOT modify the inner packet header's DSCP field.
This bit combination MUST NOT be set if the 'U' bit is not set.
D=0, T=1: This is an invalid bit combination.
Note that if the 'U' bit was set, then the WTP MUST ensure that
neither the outer or inner packet header's DSCP field is set. Note
that in this case, the 'P', 'D' and 'T' bits MUST NOT be set.
2.6.2. IEEE 802.11 MAC Management Messages
It is recommended that IEEE 802.11 MAC Management frames be sent by
both the AC and the WTP with appropriate Quality of Service values,
listed below, to ensure that congestion in the network minimizes
occurrences of packet loss. Note that the Tagging Policy used is
specified by the AC in the IEEE 802.11 WTP Quality of Service message
element (see Section 6.22), except that in this case the 'T' bit is
not observed.
[...]
6.22. IEEE 802.11 WTP Quality of Service
[...]
Tagging Policy: A bit field indicating how the WTP is to mark
packets for QoS purposes. The required WTP behavior is defined in
Section 2.6.1. 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 the WTP MUST NOT modify any QoS
markings on packets received from stations.
D: When set, this indicates that the WTP is to use DSCP to
provide Quality of Service.
P: When set, this indicates that the WTP is to use 802.1p to
provide Quality of Service.
U: When set, this indicates that the CAPWAP packets should be
untagged. When set, the 'T', 'D' and 'P' bits MUST NOT be set.
If any other bits are set, the WTP will follow the behavior
specified by the 'U' bit.
</modified text>
Let me know if this addresses all of your concerns
|
| msg519 (view) |
Author: pcalhoun |
Date: 2008-08-25.21:57:04 |
|
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:)
|
| msg518 (view) |
Author: pcalhoun |
Date: 2008-08-20.13:37:21 |
|
> > 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
|
| msg517 (view) |
Author: pcalhoun |
Date: 2008-08-20.13:37:15 |
|
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
|
| msg516 (view) |
Author: pcalhoun |
Date: 2008-08-20.13:37:08 |
|
> > > 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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap
|
| msg515 (view) |
Author: pcalhoun |
Date: 2008-08-20.13:36:55 |
|
Pat Calhoun wrote:
> > 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.)
> > BTW, how are you planning to update these rules without breaking
> > 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).
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>
> > 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?)
>
> [...]
>
> 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'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
Best regards,
Pasi
|
| msg489 (view) |
Author: pcalhoun |
Date: 2008-08-13.21:38:13 |
|
> > > I was under the impression that 802 (or at least 802.11) required
> > > (or assumed) strict in-order delivery -- but perhaps I remember
this
> > > wrong? (Obvious, tunneling over arbitrary IP hops doesn't
guarantee
> > > in-order delivery, and it seems the data channel doesn't have
> > > mechanisms to reorder or drop out-of-order packets.)
>
> > The MAC layer will provide guaranteed delivery at the AP, but
remember
> > that the air isn't exactly a reliable medium. The AP is then
> > responsible for tunneling the packets. For open or when crypto is
> > provided at the WTP, there are no issues with re-ordering. When
crypto
> > is provided at the AC, both TKIP and AES have no ordering
> > requirements, so that is also not an issue.
>
> IEEE 802.11 spec talks about the possibility that the higher layer
protocol (run on top of 802?) would require in-order delivery (IP doesn't, of
course), and seems to be able to provide strict in-order delivery.
>
> It might be at least good to discuss this topic in the spec
(describing that CAPWAP might not be able to provide fully faithful
> 802.11 implementation in Split MAC mode, but that this doesn't matter
for most practical purposes when you're running TCP/IP).
Fair enough, I am proposing adding the following paragraph to section
2.2.1:
<new text>
Note that when the WTP tunnels data packets to the AC (and vice
versa), the CAPWAP protocol does not guarantee in-order delivery.
When the protocol being transported over IEEE 802.11 is IP, out of
order delivery is not an issue as IP has no such requirements.
However, implementors need to be aware of this protocol
characteristic before deciding to use CAPWAP.
</new text>
> > > 802.11 header has 4 different addresses, all of which can be
> > > different. When doing split MAC with 802.3 frames, the 802.3
frame
> > > contains only two of the addresses; the "Radio MAC Address"
> > > field in CAPWAP header contains the third -- but what about the
> > > fourth one?
>
> > The CAPWAP WG only supports 802.11-2007, and does not support ad-hoc
> > mode (client-client). The very fact that we are providing an
> > alternative way to deploy 802.11 infrastructure means that do not
need
> > to support ad hoc mode ;-)
>
> I wasn't thinking about ad-hoc mode, but rather a STA sending a packet
to an AP where the 802.3 source address would be different from the
transmitting STA address. Is this possible? (Perhaps a "wireless Ethernet
bridge", which connects to PC via wired Ethernet, but looks like STA to the
AP? Although I'm not quite sure how the address fields really look in this
situation...)
Yes, you are correct that bridges work this way, but this is not a use case we
are trying to address in this working group. An access point uses the IEEE
802.11 primitives for populating its learning table (e.g., association
request), while a bridge needs to use other means (e.g., spanning tree).
Trying to add wireless bridges to this specification would not only expand the
scope of the WG and protocol, but would require lots more work.
> > > The document should have some more text about how the WTP
processes
> > > IEEE 802.11 IEs it receives from the AC. Section 6.6 talks about
> > > copying them to Beacon/Probe Response messages, but it seems that
in
> > > some cases, the WTP also does some local processing. (I was sort
of
> > > expecting a list of all IEs, and description of expected WTP
> > > processing (possibly none) for them.)
>
> > There are two mode of operation:
> > 1. Split MAC. In this case, the WTP needs to make sure that the
> > beacons have the proper information. Other than that,the AC handles
> > all of the IEs in the manner described in the 802.11-2007 standard.
>
> This is contradicted by text in e.g. Section 6.15, which requires the
WTP to process (beyond copying to beacons) the IE received from AC even in
Split MAC mode.
OK, fair enough. That is one exception, but that one is described in the spec.
The spec even includes:
<current text>
2.2.1. Split MAC
[...]
o The WTP generates the IEEE 802.11 Beacon frames, using information
provided to it through the IEEE 802.11 Add WLAN (see Section 6.1)
message element, including the RSNIE, which indicates support of
802.1X and AES-CCMP.
</current text>
>
> Also, it seems that some of the IEs sent are not even included in
beacons; e.g. Section 6.1 says the AC MUST send the Power Capability IE to the
WTP -- but reading 802.11, I can't seem to find any place the AP would
actually send this IE (it's sent by the STA). So what does the WTP do with it?
OK, that should have been Power Constraint, not Power Capability. Thanks for
finding that one.
>
> > 2. Local MAC. In this case, the 802.11 management packets are
> > processed in the WTP, as described 2.2.2. In this case, the WTP
> > handles the IEs in the manner described in the 802.11-2007 standard.
>
> Right, 802.11-2007 specifies how the WTP processes IEs received from
the STA. But it doesn't specify how to process IEs received from AC
(obviously, since the concept of AC doesn't exist).
Actually, re-reading the spec, I don't see where it dictates that the WTP
needs to process IEs. It does mention that the WTP needs to look at the Result-
Code in the (re-)Association Response. It also does mention that the AC MAY
send a Disassocation Request to the station, through the WTP, and that the WTP
should take the Disassocation Request as an indication that service for the
station is to be terminated.
Otherwise, there are no IE processing requirements.
> > > Section 6.15: Is this really the PTK (which also includes KCK and
> > > KEK, which aren't needed by the WTP since the AC is handling the
> > > EAPOL-Key messages -- so probably shouldn't be sent to PTK), or
only
> > > the TK used for encrypting traffic?
> >
> > We send the whole PTK. The WTP simply extracts what it needs and
uses
> > it.
>
> In that case, the "key the WTP is to use when encrypting traffic
to/from the station" is a bit confusing -- that would only the TK.
Well, you are ignoring the next sentence here. However, I can add a little
clarification to the next sentence. The thing is, when WEP is used, then the
contents are the actual WEP key, so we can't get into PTK discussions in that
sentence. So I am proposing the following:
<new text>
Key: The key the WTP is to use when encrypting traffic to/from the
station. For dynamically created keys, such as those used with
WPA and RSN, this is commonly known as a Pairwise Transient Key
(PTK). For static keys, such as those used in WEP, the Key field
contains the actual encryption key.
</new text>
> > > Is the binding specified here sufficient for 802.11r as well, or
> > > would something more be needed? (I don't know the answer -- but
> > > probably the document should tell what it is)
>
> > Given we only support 802.11-2007, we do not worry about 802.11r at
> > this point (or 802.11n), so the answer is yes, more is needed.
>
> The document certainly gives the impression of supporting 802.11n,
since it's e.g. listed in WTP Radio Information message element.
> If that's not the case, it'd be useful to say explicitly that more is
needed for 11r and 11n.
Fair point, so I will add the following paragraph to the end of the
introduction section:
<new text>
Note that this binding only supports the IEEE 802.11-2007
specification. New protocol specifications published outside of this
document (e.g., IEEE 802.11n, IEEE 802.11r) are therefore not
supported through this binding, and must be addressed either through
a separate CAPWAP binding, or an update to this binding.
</new text>
|
| msg488 (view) |
Author: pcalhoun |
Date: 2008-08-13.21:37:30 |
|
> > > 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.
>
> 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.
>
> BTW, how are you planning to update these rules without breaking
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).
> <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>
>
> Here DSCP Tag should be 6 bits, not 8.
OK, here is the packet format:
<new text>
</new text>
> <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?)
> >
> > Hmmm... Should have read: "applied to packets received at the WTP
from
> > the station."
>
> 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.
[...]
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>
>
> How does the tagging work (or not work) if the 'C' bit in IEEE 802.11
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>
>
> 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>
> > > > [...]
> > > > 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)
> > >
> > 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>
>
> The comment above about 'C' bit and DSCP Tag applies here as well...
I think this comment is now handled above.
>
> <snip>
> > > 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.
>
> 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
|
| msg487 (view) |
Author: pcalhoun |
Date: 2008-08-07.23:23:44 |
|
> > > 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)?
>
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>
> > > 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.
>
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>
> > > 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...
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).
> >
> > See above. I think showing fragments of a byte is even harder to
> > understand. I have never seen RFCs to that.
>
> See above.
Ditto
<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?)
Hmmm... Should have read: "applied to packets received at the WTP from the
station."
> > [...]
> > 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)
>
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>
> > > 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)
Understood, but IEEE 802.11-2007 still requires the AP support it.
|
| msg457 (view) |
Author: pcalhoun |
Date: 2008-07-31.17:16:11 |
|
> Section 3: CAPWAP base protocol requires that all Request messages are
odd
> numbers, and Responses even; these aren't.
Yes, this was raised already and will be addressed in the next rev.
> Section 3.1, "sent after the CAPWAP Configuration Update Request
message
> (..) has been received by the WTP" probably means "sent after the
> CAPWAP Configuration Update Response message has
been
> received by the AC"?
Oh - right.
>
> Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS
> Profile"
Right.
>
> 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>
>
> 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?
>
> Section 6.21: to avoid repetition of text, I'd suggest simply pointing
to
> existing text in Section 6.1 for field descriptions.
Tried that before - had a bug asking for specific text :(
>
> Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key
> Length" field, right?
Ack!
>
> Section 6.2/10.6: is the "Combiner" a bit field or enumerated field?
> (And in the former case, an explicit bit diagram would be very useful
to
> avoid confusion about bit numbering)
Enumerated - fixed it. Thanks.
>
> 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?
>
> Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would
> benefit for some clarification -- does 802.11 really drop all
> unencrypted EAPOL-Key frames if you have an encryption
key?
> (it seems that would cause difficulties when e.g. client reboots --
> but I'm not sure what 802.11 does here)
When the client reboots, it will re-associate and that will cause the state to
change anyhow. If 802.1X is enabled, then the station will need to re-
authenticate in order to get to the point where it can transmit data frames.
This is normal IEEE 802.11-2007/802.1X behavior - and is very well defined in
the existing standards.
>
> Section 6.15: "MUST NOT be sent if the WTP had not specifically
advertised
> support for the requested encryption
> scheme": would be easier to understand if it said how the WTP
advertises
> this (presumably, the Encryption Capabilities field in the WTP
> Descriptor Message Element?)
Got it. Added text at the end of the paragraph:
<new text>
6.15. IEEE 802.11 Station Session Key
The IEEE 802.11 Station Session Key message element is sent when the
AC determines that encryption of a station must be performed in the
WTP. This message element MUST NOT be present without the IEEE
802.11 Station (see Section 6.13) message element, and MUST NOT be
sent if the WTP had not specifically advertised support for the
requested encryption scheme, through the WTP Descriptor Message
Element's Encryption Capabilities Field (see Section 8.1).
</new text>
>
> 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.
> Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so
> probably should be 4294967295?
Oh - you want to use *that* decimal system ;-)
>
> 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.
[...]
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>
>
> Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated
field?
> (In the former case, an explicit bit diagram would be very useful to
avoid
> confusion about bit numbering.)
Agreed - and I've fixed this to be:
<new text>
6.22. IEEE 802.11 WTP Quality of Service [...]
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Tag Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
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
+-+-+-+-+-+-+-+-+
|Reserved |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.
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.
</new text>
>
> Section 6.23: "Country Code" field probably should be called "Country
> String" (since it contains other things than the country code, and
> it's called "country string" in 802.11), and it
should be
> 3 octets instead of 4.
OK, again one key goal through this process is to minimize any
interoperability issues with existing implementations, so instead of changing
the length of the field, I propose adding the following sentence to the end of
the Country String field description:
<new text>
Note that the last byte of the Country String MUST be set to NULL.
</new text>
>
> Section 6.23: The description of third octet of Country field doesn't
quite
> match IEEE 802.11 (e.g. 'X' character is missing, and the '255'
> entry is confusing).
Yup - you are absolutely correct. I have fixed it to be:
<new text>
1. an ASCII space character, if the regulations under which the
station is operating encompass all environments in the country,
2. an ASCII 'O' character, if the regulations under which the
station is operating are for an outdoor environment only, or
3. an ASCII 'I' character, if the regulations under which the
station is operating are for an indoor environment only.
4. an ASCII 'X' character, if the station is operating under a
non-country entity. The first two octets of the non-country
entity shall be two ASCII 'XX' characters.
</new text>
I do want to note that this breaks backward interoperability, however I'm not
sure I've ever seen an AP that advertises the last option.
>
> Section 6.23: reference [ISO.3166.1984] should be to the latest
edition, not
> 1984 version:
>
> [ISO.3166-1] International Organization for Standardization, "Codes
> for the representation of names of countries and their
> subdivisions - Part 1: Country codes", ISO Standard
> 3166-1:1997
Got it - thanks!
>
> Section 6.25: an explicit bit diagram would be useful for the "Radio
Type"
> field, since it's not clear whether e.g.
> "2" really means bit number 2, or perhaps bit number 6 (rest of the
text
> suggests it's the latter).
I agree, and I have fixed it to be:
<new text>
6.25. IEEE 802.11 WTP Radio 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 | Radio Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio Type |
+-+-+-+-+-+-+-+-+
[...]
Radio Type: The type of radio present. Note this is a bit field
which is used to specify support for more than a single type of
PHY/MAC. The field has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reservd|N|G|A|B|
+-+-+-+-+-+-+-+-+
Reservd: 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.
N: An IEEE 802.11n radioP.
G: An IEEE 802.11g radio.
A: An IEEE 802.11a radio.
B: An IEEE 802.11b radio.
</new text>
Note this makes certain assumptions about the position of the first bit, and I
think most people in the past would have assumed what I've done here. However,
this was a potential cause of interoperability issue, and therefore could
require an implementation to change.
>
> Section 8.1: an explicit bit diagram would be useful (since bit
numbering
> has been somewhat inconsistent in various parts of the spec).
Yes, you have a great point. Here is the new text:
<text>
8.1. WTP Descriptor Message Element, Encryption Capabilities Field:
This specification defines two new bits for the WTP Descriptor's
Encryption Capabilities field, as defined in
[I-D.ietf-capwap-protocol-specification]. Note that only the bits
defined in this specification are described below. The format of the
Encryption Capabilities Field is:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |A|T| |
+-+-+-+-+-+-+-+-+
A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].
T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
and [WPA], respectively.
</new text>
Again, this MAY have create an interoperability issue since the old text was
so vague. It is difficult to determine how people interpreted the old text.
>
> 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.
>
> Section 8.1: there probably should be IANA considerations text about
how the
> remaining bits are allocated.
I'm have opened issue 172 to track this issue.
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue172
>
> Section 10.2, "defines 27 new Message Types" -> "defines 25 new
Message
> Element Types"?
This was fixed when I cleaned up IANA considerations, given the issue you
raised on the base spec.
<new IANA text>
10. IANA Considerations
This section details the actions to be taken by IANA during the
publication of the specification. There are numerous registries that
need to be created, and the contents, document action (see [RFC5226],
and registry format are all included below. Note that in cases where
bit fields are referred to, the bit numbering is left to right, where
the leftmost bit is labelled as bit zero (0).
10.1. CAPWAP Wireless Binding Identifier
This specification requires a value assigned from the Wireless
Binding Identifier namespace, defined in
[I-D.ietf-capwap-protocol-specification]. The value assigned is to
be added to Section 2.1. The value of one (1)is highly recommended,
as it is used in implementations.
10.2. CAPWAP IEEE 802.11 Message Types
This document creates a new sub-registry to the existing CAPWAP
Message Type registry, which is defined in
[I-D.ietf-capwap-protocol-specification].
IANA will create and maintain the CAPWAP IEEE 802.11 Message Types
sub-registry for all message types whose Enterprise Number is set to
13277. The namespace is 32 bits (0-4294967295), where the values
3398911 and 3398912 are reserved and must not be assigned. The
values 3398913 and 3398914 are allocated in this specification, and
can be found in Section 3. Any new assignments of a CAPWAP IEEE
802.11 Message Type, whose Enterprise Number is set to 13277)
requires a Standards Action. The format of the registry to be
maintained by IANA has the following format:
CAPWAP IEEE 802.11 Message Type Reference
Control Message Value
10.3. CAPWAP Control Message Type
This specification defines new values to be registered to the
existing CAPWAP Control Message Type registry, defined in
[I-D.ietf-capwap-protocol-specification]. The values used in this
document, 1024 through 1048, as listed in Figure 8 are recommended as
implementations already exist that make use of these values.
10.4. IEEE 802.11 Key Status
The Key Status field in the IEEE 802.11 Add WLAN message element (see
Section 6.1) and IEEE 802.11 Update WLAN message element (see
Calhoun, Editor, et al. Expires February 1, 2009 [Page 64]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 July 2008
Section 6.21) is used to provide information about the status of the
keying exchange. This document defines four values, and the
remaining values are controlled and maintained by IANA and requires a
Standards Action.
10.5. IEEE 802.11 QoS
The QoS field in the IEEE 802.11 Add WLAN message element (see
Section 6.1) is used to configure a QoS policy for the WLAN. The
namespace is 8 bits (0-255), where the values zero (0) through four
(4) are allocated in this specification, and can be found in
Section 6.1. This namespace is managed by IANA and assignments
require a Standards Action. IANA will create the IEEE 802.11 QoS
registry, whose format is:
IEEE 802.11 QoS Type Value Reference
10.6. IEEE 802.11 Auth Type
The Auth Type field in the IEEE 802.11 Add WLAN message element (see
Section 6.1) is 8 bits and is used to configure the IEEE 802.11
authentication policy for the WLAN. The namespace is 8 bits (0-255),
where the values zero (0) and one (1) are allocated in this
specification, and can be found in Section 6.1. This namespace is
managed by IANA and assignments require a Standards Action. IANA
will create the IEEE 802.11 Auth Type registry, whose format is:
IEEE 802.11 Auth Type Type Value Reference
10.7. IEEE 802.11 Antenna Combiner
The Combiner field in the IEEE 802.11 Antenna message element (see
Section 6.2) is used to provide information about the WTP's antennas.
The namespace is 8 bits (0-255), where the values zero (0) and one
(1) are allocated in this specification, and can be found in
Section 6.2. This namespace is managed by IANA and assignments
require a Standards Action. IANA will create the IEEE 802.11 Antenna
Combiner registry, whose format is:
IEEE 802.11 Antenna Combiner Type Value Reference
10.8. IEEE 802.11 Antenna Selection
The Antenna Selection field in the IEEE 802.11 Antenna message
element (see Section 6.2) is used to provide information about the
WTP's antennas. The namespace is 8 bits (0-255), where the values
zero (0) is reserved and used and the values one (1) through four (4)
are allocated in this specification, and can be found in Section 6.2.
Calhoun, Editor, et al. Expires February 1, 2009 [Page 65]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 July 2008
This namespace is managed by IANA and assignments require a Standards
Action. IANA will create the IEEE 802.11 Antenna Selection registry,
whose format is:
IEEE 802.11 Antenna Selection Type Value Reference
10.9. IEEE 802.11 Session Key Flags
The Flags field in the IEEE 802.11 Station Session Key message
element (see Section 6.15) is 16 bits and is used to configure the
session key association with the mobile device. This specification
defines bits zero (0) and one (1), while bits two (2) through sixteen
are reserved. The reserved bits are managed by IANA and whose
assignment requires a Standard Action. IANA will create the IEEE
802.11 Session Key Flags registry, whose format is:
IEEE 802.11 Station Session Key Bit Position Reference
10.10. IEEE 802.11 Tag Packets
The Tag Packets field in the IEEE 802.11 WTP Quality of Service
message element (see Section 6.22) is 8 bits and is used to specify
how the CAPWAP Data Channel packets are to be tagged. This
specification defines bits five (5) through seven (7). The remaining
bits are managed by IANA and whose assignment requires a Standard
Action. IANA will create the IEEE 802.11 Tag Packets registry, whose
format is:
IEEE 802.11 Tag Packets Bit Position Reference
10.11. IEEE 802.11 WTP Radio Fail
The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication
message element (see Section 6.24) is used to provide information on
why a WTP's radio has failed. The namespace is 8 bits (0-255), where
the values zero (0) is reserved and unused, while the values one (1)
and two (2) are allocated in this specification, and can be found in
Section 6.24. This namespace is managed by IANA and assignments
require a Standards Action. IANA will create the IEEE 802.11 WTP
Radio Fail registry, whose format is:
IEEE 802.11 WTP Radio Fail Type Value Reference
10.12. IEEE 802.11 WTP Radio Type
The Radio Type field in the IEEE 802.11 WTP Radio Information message
element (see Section 6.25) is 8 bits and is used to provide
information about the WTP's radio type. This specification defines
Calhoun, Editor, et al. Expires February 1, 2009 [Page 66]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 July 2008
bits five (5) through seven (7). The remaining bits are managed by
IANA and whose assignment requires a Standard Action. IANA will
create the IEEE 802.11 WTP Radio Type registry, whose format is:
IEEE 802.11 WTP Radio Type Bit Position Reference
</new IANA text>
|
| msg453 (view) |
Author: pcalhoun |
Date: 2008-07-30.23:30:58 |
|
> Section 3: CAPWAP base protocol requires that all Request messages are odd
numbers, and Responses even; these aren't.
Yes, this was raised already and will be addressed in the next rev.
> Section 3.1, "sent after the CAPWAP Configuration Update Request message
(..) has been received by the WTP" probably
> means "sent after the CAPWAP Configuration Update Response message has been
received by the AC"?
>
> Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS
Profile"
>
> Section 6.1 and 6.21: are some of these 802.11 information elements
optional, or are all of them always included?
>
> Section 6.1 and 6.21: what do you put in "Key Status" if you're not using
encryption at all?
>
> Section 6.21: to avoid repetition of text, I'd suggest simply pointing to
existing text in Section 6.1 for field
> descriptions.
>
> Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key
Length" field, right?
>
> Section 6.2/10.6: is the "Combiner" a bit field or enumerated field?
> (And in the former case, an explicit bit diagram would be very useful to
avoid confusion about bit numbering)
>
> 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.
>
> Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would
benefit for some clarification -- does 802.11
> really drop all unencrypted EAPOL-Key frames if you have an encryption key?
(it seems that would cause difficulties
> when e.g. client reboots -- but I'm not sure what 802.11 does here)
>
> Section 6.15: "MUST NOT be sent if the WTP had not specifically advertised
support for the requested encryption
> scheme": would be easier to understand if it said how the WTP advertises
this (presumably, the Encryption Capabilities
> field in the WTP Descriptor Message Element?)
>
> 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).
> Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so
probably should be 4294967295?
>
> 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?).
>
> Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field?
> (In the former case, an explicit bit diagram would be very useful to avoid
confusion about bit numbering.)
>
> Section 6.23: "Country Code" field probably should be called "Country
String" (since it contains other things than the
> country code, and it's called "country string" in 802.11), and it should be
3 octets instead of 4.
>
> Section 6.23: The description of third octet of Country field doesn't quite
match IEEE 802.11 (e.g. 'X' character is
> missing, and the '255'
> entry is confusing).
>
> Section 6.23: reference [ISO.3166.1984] should be to the latest edition, not
1984 version:
>
> [ISO.3166-1] International Organization for Standardization, "Codes
> for the representation of names of countries and their
> subdivisions - Part 1: Country codes", ISO Standard
> 3166-1:1997
>
> Section 6.25: an explicit bit diagram would be useful for the "Radio Type"
field, since it's not clear whether e.g.
> "2" really means bit number 2, or perhaps bit number 6 (rest of the text
suggests it's the latter).
>
> Section 8.1: an explicit bit diagram would be useful (since bit numbering
has been somewhat inconsistent in various
> parts of the spec).
>
> Section 8.1: WEP is missing from the list?
>
> Section 8.1: there probably should be IANA considerations text about how the
remaining bits are allocated.
>
> Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message
Element Types"?
|
|
| Date |
User |
Action |
Args |
| 2008-09-10 22:01:10 | pcalhoun | set | status: chatting -> resolved
messages:
+ msg534 |
| 2008-08-25 21:57:29 | pcalhoun | set | messages:
+ msg521 |
| 2008-08-25 21:57:22 | pcalhoun | set | messages:
+ msg520 |
| 2008-08-25 21:57:04 | pcalhoun | set | messages:
+ msg519 |
| 2008-08-20 13:37:22 | pcalhoun | set | messages:
+ msg518 |
| 2008-08-20 13:37:15 | pcalhoun | set | messages:
+ msg517 |
| 2008-08-20 13:37:09 | pcalhoun | set | messages:
+ msg516 |
| 2008-08-20 13:36:55 | pcalhoun | set | messages:
+ msg515 |
| 2008-08-13 21:38:13 | pcalhoun | set | messages:
+ msg489 |
| 2008-08-13 21:37:30 | pcalhoun | set | messages:
+ msg488 |
| 2008-08-07 23:23:44 | pcalhoun | set | messages:
+ msg487 |
| 2008-07-31 17:16:11 | pcalhoun | set | status: unread -> chatting
messages:
+ msg457 |
| 2008-07-30 23:30:58 | pcalhoun | create | |
|