| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
David (& all), I think we need to start and end it the GLK link at the MAC_SAP interface and as we ideally want make it a pseudo end-to-end Ethernet wire. The biding between this MAC_SAP and the ISS is done by the .1AC convergence function and the 11ak spec must refers to.
Remember that in the first step we plan to have the 802.11GLK specific clause in the .11ak specs and reference to the generic PMPN convergence function before incorporating this caluse in a next rev of .1AC. So we have all the freedom
to describe there 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 be distributed to both wired and wireless speakers – something that currently requires 2 different stream declarations…). So in my opinion we need to find the wording to 1) keep the GLK link at 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]
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]
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. _______________________________________________________________________________
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.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ _______________________________________________________________________________
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.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
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. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |