IEEE P802.11 Wireless LANs Addressing Comment Resolutions Date: Author(s): Name Affiliation Address Phone email David Kloper Cisco Systems, Inc. 170 W Tasman Dr San Jose, CA 95134 408-526-5041 dakloper@cisco.com CID Page Clause Comment Proposed Change Ad-hoc Notes 149 5.39 4.3.23.1 If TA=SA on a frame from an AP (a BPDU, for example), is it okay for the AP to set ToDS=1 and FromDS=0? Technically, that seems okay, but do non-AP STA implementations have "hard wired" rejection of "To DS" frames? Similarly, a frame that passed through (but didn't orignate in) a non-AP STA, and is destined for the AP, would end up with ToDS=0 and FromDS=1. Will that confuse any AP implementations? (Re)Consider this implication. Change/limit support for three address frame format if this is a real concern. Revise: “The three address frame format may be used if SA equals TA and/or RA equals DA as described in 8.3.2.1 (Format of Data frames).” -> “The three address frame format may be used, as defined by table 8-3, provided the addresses are consistanet with table 8-26.” 233 It is sloppy design to allow different combinations of Data frame ToDS/FromDS in order to save 6 bytes in some cases. This makes more sense in the context of a set of low bit rate WG options, and not GLK. Many other more efficient solutions are also possible under such cases, such as Van Jacobson header compression. Recommend strongly that selection of ToDS/FromDS be based on the role of the peer, and so usage of 4Addr format be mandated when recipient(s) are GLK peers. Revise: Changes as provided by CID149.
239 6.33 4.3.23.3 "Reasons for such selective reception include the MAC service requirement that, when an MSDU is sent, it is not returned to and processed by the transmitting station." It is not clear to me in what situation is assumed here. In the IEEE 802.11-2012 clause 9.3.6, the transmission procedure of group address frames is specified which is not consistent with the above text. Please clarify what situation is assumed here. Revise: “Reasons for such selective reception include the MAC service requirement that, when an MSDU is sent, it is not returned to and processed by the transmitting station” -> “The reason for such selective reception is to support requirements of 802.1Q bridges, and can include the MAC service requirement that, when an MSDU is sent, it is not subsequently received and processed by the transmitting station”. Commentor can review 11-12/1441r1 for discussions. 258 6.33 4.3.23.3 "Reasons for such selective reception include the MAC service requirement that, when an MSDU is sent, it is not returned to and processed by the transmitting station." Its situation should be clarified. It is not clear if the transmission procedure of group address frames specified in the IEEE clause 9.3.6 is included in the above explanation. Please explain clearly what situation is assumed here. Reject: Dup CID239 295 8.19 4.3.23.4.3 The subset of STAs to received a group addressed is not arbitrary, it's a specifc subset as defined in the SYNRA. Change "an arbitrary" to "a specific". Revise: “the GLK AP be able to transmit them so that they are accepted by an arbitrary subset of the associated GLK STAs” -> “the GLK AP must be willing to transmit MSDUs so that they are accepted by an arbitrary subset of the associated GLK STAs, as provided by the 802.1Q bridge”.
401 54.17 9.24.10.3 with RA field set to the SYNRA": the RA field doesn't exist in the A-MSDUs. Replace "A-MSDUs with RA field set to the SYNRA" with "A-MSDUs whose MPDU RA field values are the SYNRA". 223 54.23 9.42 Support for these 3 modes are overly complicated, and will tend to be a barrier to adoption. Especially when AMSDU deaggregation is handled in HW. Recommend making these optional, or only mandatory fitting in base 48 bit SYNRA w/o extension. If support is not indicated by Clients at association, then AP can reject Clients without required support options or replicate as unicast. Instead call out that unsupported SYNRA types must be dropped by receiver. Revise: Section rewritten in D1.3 with only 1 type that fits in 48 bits. 254 54.34 9.42 Sentence doesn't belong here. Delete "The structure of the SYNRA address, which includes a 2-bit SYNRA Type field and a 22-bit SYNRA Control field, is shown in Figure 8-52a (SYNRA structure)." Revise: Sections rewritten in D1.3. 426 54.34 9.42 The structure of SYNRA related fields shall be specified in clause 8, not in clause 9. Create a new subclause 8.3.2.1.3´╝êSYNRA field) by moving corresponding contents from 8.3.2.1.2 and 9.42. Revise: Sections rewritten in D1.3. 87 54.37 "the SYNRA Control field consists of an E/I subfield, an AID offset subfield, and an AD bitmap subfield." -- figures are definitive. There is nothing to be gained from attempting to describe the format also in words. Replace by "defined in figure 9-91". Move the figure to occur before the field descriptions. Make similar changes to the other SNRA Types. Revise: Also change “The E/I subfield is a single bit indicating” -> “The E/I subfield indicates”. Editor to make consistant changes throught section.