Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go?

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

David/Phillipe,

Thanks for the review and comments.

Most of your comments are on the base figure (the first one) it seems. That’s being discussed in REVmc (well, been discussed, but fresh eyes always notice new things!). I’d like to discuss further with you, but suggest we take it off the TGak reflector, as it really isn’t in TGak scope.

The comment/question about SYNRA is obviously in our scope, though. So, my thought on that is that SYNRA handling on receive is part of the Address 1 filtering. For transmit, it is part of the MPDU header creation. I’m open to discussion/debate, though!

Philippe, the figure labelled “GLK STA” is meant to be a generic step, from the original figure (which is completely general for all STAs, in theory) toward the actual GLK figures. That is, I added the notion that when GLK is in use, the vector comes into play, and the .1AC convergence function applies. But, beyond that I was not specific enough to say what type of GLK STA this is (yet). It was probably just a bad idea and confusing to show that step, in hindsight. The following two figures are really the ones that matter, and should get fixed up and then go into our draft.

The other comment that I need to address here is the “DA address filtering”:

First, I should state that I glued that into the figure, because it is in the figure for a non-AP STA in the baseline text. On further review, I think it is incorrect in the GLK case – I’ll get back to that in a second. The idea of that filter, in the baseline text, is that some frames could potentially get through the Address 1 filter, but not actually be appropriately destined for this device. Note that this filter only applies if this is an end station, and as an end station (“leaf node”) in the network, frames should only be delivered up to the higher layers if the DA matches (individually, or group) this device.

But, as we extend this to include GLK non-AP STAs, now we back in the realm where these are not “leaf nodes” in the network. It is quite possibly (even probable) that the DA is not this device, but something beyond an attached bridge. So, the DA check is probably incorrect here, just as it is not applicable at an AP.

Thanks (both) for asking about it, and making me think a bit more!

Mark

From: David Kloper (dakloper) [mailto:dakloper@xxxxxxxxx]
Sent: Wednesday, September 09, 2015 9:14 PM
To: Philippe Klein <philippe@xxxxxxxxxxxx>; Mark Hamilton <mark.hamilton2152@xxxxxxxxx>; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

Agree, this was very helpful.

I’d basically agree w/ Mark’s analysis, but might quibble some on the figure:

* Not sure where / how we show Group addressed SYNRA handling;

* Tx PS deferral might be lower, after SeqNr assignment, as could PS between send and retry, etc;

- Similar for Packet Number.

* Rx PS U-APSD handling matching Tx deferral;

* Not sure what MSDU integrity & protection is vs under Decrypt?

- Michael MIC for TKIP?

- Since its before AMSDU de-agg, is it MSDU or MPDU operation?

* I too was confused by DA filtering.

- Is that SYNRA (RA) or Group address filter (DA)?

* Should BA score boarding be shown w/ Duplicate detection?

* MAC header creation might not be correct that low, as covered by AAD of CCMP, etc.

Thanks,

David

From: Philippe Klein [mailto:philippe@xxxxxxxxxxxx]
Sent: Thursday, September 10, 2015 2:06 AM
To: Mark Hamilton; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx; David Kloper (dakloper)
Subject: RE: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

Mark,

Kudos. Excellent feedback and excellent “homework”. I agree with your analysis and feedback.

One clarification though about the 2^nd and 3^rd figure : what is the difference between the “GLK STA” and the “non-AP endpoint” ?

- is this endpoint a non-GLK STA ? (does not seem as it is connected to the .1AC CF)

- what is the DA filtering about ?

Thank you /Ph

From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Sent: Wednesday, September 09, 2015 06:43 PM
To: Philippe Klein; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx; 'David Kloper (dakloper)'
Subject: RE: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

All,

I think we’re all saying the same things:

1) Yes, a GLK link is an 802.11 association (with GLK capabilities enabled), and thus it terminates at the SAP at the “top of the 802.11 STA”.

2) Note that I am being very careful not to call this _the_ MAC SAP. As 802.1Q and 802.1AC have been carefully updated to make it clear, the MAC Service is provided by many entities within the MAC layer, including shims, aggregators, convergence functions, etc. Each of these provides a SAP, that could be considered _a_ MAC SAP (since it provides, effectively, the MAC Service, perhaps with some extensions or other behaviors). I believe it will go a long way in our discussions if we start calling these SAPs different things, to distinguish what we mean in each usage.

3) Within 802.11, we can (and should) describe that when a GLK link is established in an infrastructure network (when a non-AP STA associates to an AP, and GLK is negotiated for the association), then _each end_ of the GLK link creates or enables a higher level SAP instance (generally, an ISS SAP instance) and creates a binding/mapping for this SAP instance to the GLK link. This binding/mapping is done cooperatively by entities within each 802.11 endpoint and their local 802.1AC convergence function (in particular, an IEEE 802.11 General Link convergence function). And, per your other thread comments Philippe (and I believe your comments below, David), I agree that we should discuss that this binding/mapping is local to the endpoint, and is a mapping between the GLK link, an element within the 802.11 MAC SAP vector, and the ISS SAP instance.

4) This same thing happens on both APs, and non-AP STAs. I agree, Philippe, we want to support a (non-bridge) end station with a GLK link. However, I’m going to claim that such a STA is still using all the same architectural concepts, it just happens to have only one link, one ISS SAP instance, etc., and those singular concepts stack up to ultimately deliver a standard (non-bridged) MAC Service to the upper layers. One reason it is important that such an architecture is still present in the non-AP STA, is that such a STA can have GLK links that are not 802.11 infrastructure associations (not to an AP, but direct links to another non-AP STA), as David points out. In this case, the non-AP STA has a plurality of ISS SAP instances, each mapping to an element in the 802.11 MAC SAP vector, and thus to a specific GLK link. Whether these ISS SAP instances are then connected to an 802.1Q bridge, or some other higher layer structure that knows what to do with them, is outside our scope.

5) I thought, at one time at least, the wording in 802.1Q/802.1AC was such that it made it clear that an ISS SAP could be useful in a non-bridge scenario. I can’t seem to find that now. Am I missing it, or did it go away?

6) I also agree that while we are transitioning the documents, we probably put more of this in 11ak for now, and it moves to .1AC over time.

I think this is the right way to expand on and clarify your concern, David.

FYI, I am working on some pictures like these, for this point-of-view:

By way of background, the figures that follow this all are the GLK extensions to this figure, currently in 802.11 D4.0, and the basis for our architecture discussion in 802.11:

… and, per my comment at the start, I think the “(M) – MAC SAP” in the above picture needs to be modified, so we stop arguing about whether that is _the_ MAC SAP (in the middle of the stack).

Now, from the above, a simple model of a GLK STA (that is, its “Role specific behavior” box completed) is:

Then, for a non-AP endpoint, that becomes:

And, for a mixed mode GLK-AP, it becomes:

Comments and flames welcome!

Mark

From: Philippe Klein [mailto:philippe@xxxxxxxxxxxx]
Sent: Wednesday, September 09, 2015 4:17 AM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

Resent after typo and syntax fixes. Sorry

David (& all),

I think we need to start and end the GLK link at the MAC_SAP interface as we ideally want to logically make it a end-to-end Ethernet pseudo-wire.

The biding between the MAC_SAP and the ISS is done by the .1AC convergence function and the 11ak spec must refers to it (remember that in the first step, we plan to have the 802.11GLK specific clause in the .11ak specs and reference the generic PMPN convergence function before in a seconf step, incorporate this clause in a next rev of .1AC. Therefore we have there all the freedom to describe the binding between the “GLK MAC_SAP” and the ISS SAP…

To complicate a bit the issue (sorry…L) defining the GLK link as a bridge-to bridge only connection (i.e. ISS to ISS SAP) could be too restricting : a GLK link could well be terminated at the MAC_SAP in a device without be connected to a bridge (for example wireless speakers could well be connected thru a GLK link, allowing the same SRP stream to be distributed to both wired and wireless speakers – something that currently requires 2 different stream declarations…).

So in my humble opinion we need to find the wording to separately:

1) define the GLK link within the MAC_SAP boundaries while explaining the P2P MAC_SAP only nature of this link

2) describe the binding between this MAC_SAP and the ISS_SAP in a .1AC specific clause that will in the future be “mirrored” to become a .11GLK specific clause in the .1AC specs

Cordially /Philippe

From: David Kloper (dakloper) [mailto:dakloper@xxxxxxxxx]
Sent: Wednesday, September 09, 2015 09:16 AM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go?

Mark,

I guess my question / concern had to do with this Association on the GLK AP making a logical connection between the ISS SAP on AP to another ISS SAP presumable on the non-AP GLK STA.

I forget the exact wording, but although we probably understood the connect in the call, it may not be readily understood by others reading the spec.

Within the AP MAC we are creating a binding between a specific ISS SAP and a related GLK non-AP STA, which is the only path the AP has to that ISS SAP, which isn’t directly addressable.

We do have a logic connection between the 2 peer ISS SAP, but if we are talking at that level, then don’t both sides create/bind/associate/term-of-merit the 2 peer ISS SAP?

And don’t we need similar descriptions for all such connections between GLK STA, independent of whether one happens to be an AP?

Thanks,

David

From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Sent: Saturday, September 05, 2015 12:18 AM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go?

All,

On yesterday’s joint call for 1AC and 11ak, we started to get into a discussion about where to put language that describes the creation/enablement of the ISS SAP, when a .11 GLK link is established. I dug a bit into our current text, and have a proposal:

Currently, 802.1AC, in the context of 802.11 and 802.11ak in particular (so, in Annex B awaiting 11ak), has only a very brief discussion of the ISS SAP enablement and logical fit with .11’s association:

B.2.4: IEEE 802.11 non-AP stations can be associated and disassociated with IEEE 802.11 access points, and direct links among non-AP stations can be created or destroyed. An implementation can choose, as these events occur, to create and destroy virtual point-to-point LANs and ports, or it can manipulate the MAC_Operational parameters of the SAPs to make them available for use or not.

Currently, 802.11ak’s discussion of “management plane” actions with the ISS SAP are also pretty brief (there is more about the data plane, but that’s off topic here):

4.5.3.3: The act of becoming associated invokes the association service, which provides the STA to AP mapping to the DS in the non-GLK case or enables and, if necessary, creates a corresponding ISS SAP on the GLK AP in the GLK case.

5.2.1a: A GLK STA coordinates with the 802.1AC IEEE 802.11 General Link convergence function to create a virtual point-to-point LAN for each GLK link to an associated or peered GLK STA. This point-to-point LAN is presented by the convergence function as a unique ISS SAP, which is ultimately mapped to an 802.1Q bridge port. Each such SAP is identified by a locally unique service_access_point_identifier, generated by the STA and the convergence function.

(Plus, in 802.11ak, a few equivalent statements for Reassociation, Disassociation, and Mesh cases.)

In my opinion, the text in 11ak 5.2.1a is probably the best description we have of how these management operations are connected, and I think it is pretty good, actually.

But, we probably want something just a little more “normative” (and less declarative) somewhere. Such text would draw on the new (11ak) parameter to .11’s MLME-ASSOCIATE service (and REASSOCIATE, DISASSOCIATE, DLS, MESHPEERING friends), which communicates if an established/deleted link is GLK or not.

One question raised specifically, yesterday, was whether such text should be in 11ak, or 1AC. The point was made that to be really “clean” from an architectural layering point-of-view, it would be best if 11ak only described what happens below the 802.11 MAC SAP service interface – that is, do not describe things that the 802.1AC convergence function(s) does. While I agree with this argument, it doesn’t sway me (enough).

I suggest that text to the effect of “In a GLK AP, upon receiving an MLME-ASSOCIATE.indication primitive, the SME determines if the link is GLK or not, by examining the GLK Capabilities parameter. If the requested link is GLK, the SME coordinates with the 802.1AC IEEE 802.11 General Link convergence function to …” (completed with stuff like the wording in 5.2.1a. And, similarly, text like this for tearing down links, and disabling/deleting ISS SAP instances, etc.

I think such text makes a lot more sense in 802.11ak, somewhere in clause 10, then it does to put this sort of gory detail and tight coupling to MLME service primitive details, into 802.1AC.

Comments?

Mark

P.S., 802-1-L listserve folks: I’ve been copying this listserv as I think it is where 802.1AC technical discussion needs to go. But, if I’m spamming you all, and there is a better way to have this discussion, please let me know.

_______________________________________________________________________________