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,

My commenting relative to the A1 filter was, consider a non-AP STA.

It might have been configured by its stack to select a subset of Multicast addresses, which an A1 filter could be construed to drop DA (A1 under this case) not of interest to that non-AP STA.

If GCR runs above that, then it would fail to acknowledge a multicast frame, not because of a CRC error, but because the receiving STA doesn’t care about it, and I don’t believe the AP would know which was the reason.

Or is the A1 filter to just detect Unicast to that STA, and all Multicast from its AP, and an unshown DA filter is in the stack above an unshown BA scoreboarding?

As always, what is not shown can be more confusing than what is J

As far as the sapping discussion goes, I must have misread/interpreted a statement, and I think you cleared things up for me.

My resorting back to ISS SAP at the end was more a slip up of the SAP to be named later.

Apologies if it caused excess confusion.

Thanks again,

David

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

Hi, David,

Sorry, I’m not understanding your first item. First, I’m not sure why GCR BA scoreboard needs to be any different from the normal BA mechanisms. I would think they are effectively the same, and in the same place in the stack up. Which is to say, after A1 filtering, and integrity checks. I agree with you that doing it before A1 filtering is a problem. I don’t see why doing it after A1 is a problem. You seem to be implying some “local STA filter rules (not known to AP)” that I can’t get a grip on. Can you expand on what those are/could be?

On point two, which “MAC SAP to be named later” are you referencing? (See, Philippe – we need names!) If it’s the “top of the STA stack” SAP, then, no, that SAP is the same (I hope) for _all_ 802.11 STAs. If it is the SAP at the top of the (GLK-)DSAF, and at the bottom of the .1AC convergence function, then my intention was for this to be the same SAP for both GLK AP and GLK non-AP STAs. If you are spotting a difference in my description, then either I described it poorly (quite likely) or I have a mistake (which is impossible J ). So, in short, I agree with you that this SAP should have only one definition that .1AC needs to worry about.

Do note, however, that the DSAF itself is different for an AP versus non-AP, but only in that the AP has the capability of connecting to the DS, and providing legacy (non-GLK) service to a mixed-mode BSS. I hadn’t really thought through what a mixed-mode non-AP STA would look like, or even if we think such a thing should be allowed. I think there is room for discussion on that topic.

Lastly, you ended with a comment (your last sentence) about ISS SAP, which I think confuses me. I am still trying to decide if the nature of 802.1Q now, or even 802.1 O&A or some such, effectively has settled on all stations having an ISS SAP somewhere in the stack up, dividing the media-specific stuff from the media-independent stuff. I don’t think we are quite there, though. So, I think there are still some variations of use of 802.11 that have no ISS SAP at all anywhere in their stack-up architecture. But, was you last sentence saying/implying that all 802.11 uses _did_ have ISS SAP? Or were you saying something else, that I’ve missed, sorry.

Mark

From: David Kloper (dakloper) [mailto:dakloper@xxxxxxxxx]
Sent: Thursday, September 10, 2015 7:02 PM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] 1AC/11ak: where does discussion about ISS SAP go? [2]

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.

_______________________________________________________________________________