Hi Mark,
See below
On Mon, Feb 27, 2017 at 2:10 PM, Mark Hamilton <
mark.hamilton2152@xxxxxxxxx> wrote:
> 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
In 11ak Draft 3.0, the use of ToDS=1/FromDS=1 is extended to "... mesh BSS, by S1G relays
, as specified in 10.51 (S1G Rellay operation, or by a GLK STA." In Draft 3.1, the entry for ToDS=1/FromDS=0 is also modified to says "... the only valid combination or Data frames transmitted by a
non-GLK AP and ..."
> 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.
Are you saying we should do that even if the AP says GLK required, which currently implies there is no DS?
> 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.
Say you are a GLK non-AP STA and there is a management station on the network behind you. So you get this Data frame, which, say, is some management thingie to read or set something in the "higher layers" of the AP. How do you know this? It is obviously impractical to require a GLK non-AP STA to be able to recognize all existing and future to-be-invented management protocols. All you really have to go on are the source and destination MAC addresses. You certainly also know your own TA and the RA for the AP. You should always be able to send it as 4-address with ToDS=1/FromDS=1. But if you want to and SA=TA, you should be able to use the 3-address format with ToDS=1/FromDS=0. I don't see why the AP should handle these differently. At some point in the processing of a received frame, the AP will have normalized things down to just SA and DA and, if the non-AP STA is non-GLK always give it to the DS and if the non-AP STA is GLK always give it to the bridge port. Anything else seems pretty kludgy to me.
> 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?
See above.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@xxxxxxxxx> 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.