[STDS-802-11-TGAK] Follow-up to today's discussion

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

All,

In follow-up (but not completed – sorry!) to today’s discussion about “GLK transmissions” from a non-AP STA to the AP. Some points:

- In 802.11-2016, Table 9-3, it says that for a frame with ToDS=0 and FromDS=1, “This is the only valid combination for Data frames transmitted by an AP …”

- There is not an equivalent statement quite so strongly worded for the non-AP STA to the AP, although there is this for ToDS=1 and FromDS=0, “A Data frame destined for the DS or being sent by a STA associated with an AP to the Port Access Entity in that AP.” That’s almost the same thing, but doesn’t have the ‘only’ word. But, this statement, combined with the rest of the statements (that also don’t have ‘only’ in them), would lead the reader to believe that no other combination is legal/reasonable, I claim.

- The above notwithstanding, to Dick’s point about ToDS=1 and FromDS=1, it does say, “This standard defines procedures for using this combination of field values only in a mesh BSS.” By implication, that is leaving the door open for other uses, that just aren’t defined within the Standard, I guess. So, we have our usual grey area, if you’re willing to squint at all this just right. L

But, despite the confusion about whether a non-AP STA can send a four-address frame to the AP or not, I believe the first bullet above is quite explicit. This leads to two points:

- We have a “bug” in 11ak, in that we don’t adjust this sentence to allow an exception for a GLK AP to send a four-address frame. I think we have to fix that.

- I think the text in 11ak section 10.62, second paragraph, is okay (despite Dick’s concern raised on the call). That text is saying that an AP (as one example) can send either a three-address or four-address formatted frame, for a GLK transmission with an individual address to a non-AP STA in the same BSS. This is not a tautology with Table 9-26 (which says there only are these two types of frames), because it is the normative text that supports the change we need to make to Table 9-3, which would otherwise restrict an AP to only ever using three-address frames. Thus, the sentence in 10.62 (combined with the fix we need to make to Table 9-3) becomes permissive for the AP to use either frame format. Arguably, we could/should change the “shall” to a “may” though, I suppose. I don’t have a lot of concern about that one way or the other.

So, if the above deals with the AP transmitting to a non-AP STA in the BSS, we’re left only with the problem of a non-AP STA transmitting to the AP.

These transmissions could be: 1) “through” the AP to the DS to some other device, 2) “through” the AP to the attached bridge port in the GLK case, or 3) destined to the local upper-layers collocated with an AP (as described in the NOTE on pg. 253 of 802.11-2016).

Case (1) is the “legacy” behavior, generally will use a three-address format (the ‘grey area’ above ignored for now), and is currently described in the 11ak draft as only allowed if the non-AP STA associates without specifying GLK Capabilities in the Association request. Currently, that allows the GLK-DSAF at a mixed mode AP to know that all MSDUs from that non-AP STA are to be routed to the DS. (More on this in a bit.)

Case (2) is the General Link establishment. If the non-AP STA says it is GLK Capable in the Association request (and the AP is also GLK Capable), then the AP treats this association as a General Link, creates the virtual bridge port and mapping, and the GLK-DSAF will route all MSDUs from this non-AP STA to the bridge port.

Case (3) is addressed by the NOTE on pg. 253 of 802.11-2016 for a non-GLK non-AP STA. But, this is a problem that we have not adequately described, in my opinion, for a non-AP STA that has associated with GLK Capability indicated.

We could solve the case (3) problem, and not break the case (1) and (2) behavior, by slightly modifying the GLK-DSAF to not blindly route MSDUs from associated non-AP STAs based on the nature of the association, but to instead look at the frame format (at least for frames that come over a General Link association). If the frame format is three-address, the MSDU gets routed to the DS, otherwise, a four-address format frame (over a GLK capable association) gets routed to the bridge port. I think this fixes the problem.

The question is whether this creates problems. A couple considerations:

- This potentially means that a GLK non-AP STA could send any MSDUs using legacy style, whether they are being sent to the AP’s local upper-layer, or elsewhere. Do we want to prohibit such use (say this three-address trick can only be used for sending to the AP’s upper-layers)? Do we think such use is actually a good thing, and want to allow it? Does it cause any problems? I’m not sure.

- I think this probably all started with our mental model of “replacing the wire in a wired bridged network with a wireless link.” That is, we thought a non-AP STA would either be attached (the logical ‘wire’) to a bridge port or a legacy infrastructure (call it a switch/hub/etc, or whatever), but never to both. If we want to keep that mental model, this idea that a non-AP STA can send a three-address frame any time (and get “legacy DS” behavior) breaks things. Perhaps, if we limit the three-address trick to only being for MSDUs going to the AP’s local upper-layers, it isn’t so bad – that doesn’t really break the mental model very much.

I’m sure there’s more I’m missing. But that’s as far as I’ve gotten in my attempt to sort this out logically.

Comments?

Mark

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.