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

Mark,

Just throwing in a couple more monkey wrenches.

1) As far as treating SYNRA filtering as A1, I guess my concern is where does the GCR BA scoreboard get updated?

Its not explicitly shown in the figure.

If below A1 filtering, then we update for frames to others, and if above, the local STA filter rules (not known to AP) will inform the unsuspecting AP the frame needs to be retried.

I think there are problems to be worked out here.

2) We seem to be saying this MAC SAP to be named later is a different beast for GLK AP STA and GLK non-AP STA.

I think maybe we should look to how we could normalize this to a single beast.

Does 802.1AC need to have different sections treating the same 802.11 link different, based on an internal role?

I’d think they would want to have general text of hookup, and not care which of the many possible roles we have.

Then 802.11 can include all the variants it wants, and they all look like another ISS SAP.

Thanks,

David

From: Richard Roy [mailto:dickroy@xxxxxxxxxxxx]
Sent: Friday, September 11, 2015 5:14 AM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

Mark,

We are in complete agreement! (as usual ... ;^)))

Cheers,

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

(Thanks for the catch on sub-layer. That’s quite correct, of course!)

As for making this clear… I’d like to start by ensuring those of us on this thread believe it is correct. And, I’d like to make sure we’re in alignment with 802.1 as well. Lack of alignment with 802.1 is a big part of what leads to this confusion in the first place. But, yes, I think as the discussion of “an AP has no MAC SAP?” happens in REVmc, that REVmc should try to clarify all this.

That said, REVmc can only lay the foundation that there are multiple places where a SAP delivers (effectively) the MAC Service, but that each of these provides that service with other features/behaviors tailored for specific purposes. From there, 11ak will have to be the place where we clarify what those SAPs are to us (that is, the SAP with the vector of identifiers that map to GLK links, and (for now, until .1AC does it for us) the ISS SAP concept in the context of the GLK convergence function and their many-to-one mapping to the vectorized SAP).

My $.02

Mark

From: Richard Roy [mailto:dickroy@xxxxxxxxxxxx]
Sent: Thursday, September 10, 2015 11:03 AM
To: '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]

From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Sent: Thursday, September 10, 2015 7:52 AM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

GLK links are between “802.11 MAC SAP”s, which is a vague term we’ve been using to mean (I believe) the “top of the STA stack” SAP. Note that this is not _the_ MAC SAP that everyone seems to assume is meant by (unqualified) “MAC SAP”.

APs don’t have _the_ MAC SAP. That is, they don’t deliver frames to a [RR>] [sub-] layer above the MAC. But, they have lots of internal (need to be qualified with adjectives) MAC SAPs.

[RR>] As I suspected. Will REVmc make this clear? I suspect this might be a source of ongoing confusion if not. Is it perhaps an 11ak task????

Mark

From: Richard Roy [mailto:dickroy@xxxxxxxxxxxx]
Sent: Thursday, September 10, 2015 8:41 AM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

One simple question came to mind as I glanced at the thread:

How can GLK links always be between MAC-SAPs if APs don't have one? I assume this implies that GLK APs differ from non-GLK APs in that they have one. I must have missed that point earlier.

Cheers,

From: David Kloper (dakloper) [mailto:dakloper@xxxxxxxxx]
Sent: Wednesday, September 09, 2015 8:14 PM
To: 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.

_______________________________________________________________________________