Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 ARC Reflector ---
All, Mark thank you for pulling this information together. One editorial comment regarding your text from clause 4.3.5.1 – REVmd D5.0 has the reference pointing to 4.3.28, not 4.3.27 as show below.
I agree that there is no such thing as a GLK DSS and that GLK does not use the DS concept for mobility. As you know, GLK operation provides a means of establishing an 801.11 link from one
IEEE 802.1Q bridge port to another IEEE 802.1Q bridge port by mapping the 802.11 MAC SAPs via GLK convergence functions (shim layers) to the ISS SAPs of the bridge (I’ve used plurals here because
there two of each entity, one on each end of the link), defining a point to point link. Mobility for devices operating with GLK links is not within the scope of the 802.11 specification, as mobility of GLK links are managed (if supported at all) by the ability
of the associated IEEE 802.1Q bridged network and the associated GLK convergence function (shim layer) to support port mobility (mobility being the process of allowing a link to be moved (re-mapped) from one IEEE 802.1 bridge port to another bridge port with
in the same bridge or bridged LAN and changing the bridge routing to support the continuous delivery of packets to the new (re-mapped) location “transparently”). This said – here are some initial thoughts (additional discussion and review are required before any action should be taken):
Regards, Joseph Levy From: *** 802.11 Architecture Standing Committee *** <STDS-802-11-ARC@xxxxxxxxxxxxxxxxx>
On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 ARC Reflector ---
All, I wasn’t sure if we really got to the bottom of Jouni’s questions about how our proposed changes to ESS and HESS definitions/description (in 11-20/0177, to be liaised to REVme) relate to GLK operation. I found the following in 802.11ak,
that I thought solved the problem for us (4.3.5.1): The architectural component used to interconnect infrastructure BSSs is the DS for non-general link (non-GLK) operation. The DS and extended service set (ESS) are mechanisms for expanding connectivity for non-GLK operation. For GLK operation, an IEEE 802.1Q bridge might be used to form an extended network (see 4.3.27). Hopefully, that’s helpful, as I believe it means we don’t have to worry about GLK in our changes. If anybody think we should still add a NOTE (or something similar) near the ESS definition, please respond to this reflector. (Personally, I think that is beyond our intent of “fixing” the ESS definition, but it could be argued we’re clarifying
things, “while we’re at it”.) That said, I agree with Jouni that there is an occurrence of “ESS with a DS” in 802.11ak (and now in REVmd), in 4.5.3.4: The reassociation service is invoked to “move” a current association of a non-AP STA from one AP to another. In an ESS with a DS, the reassociation service informs the DS of the current mapping between AP and STA as the STA moves from BSS to BSS within the ESS. I agree that this is redundant, and should just be “In an ESS, the reassociation service…” Do we want to suggest fixing that in our liaison (“while we’re at it”), or leave that for a REVme comment? Mark To unsubscribe from the STDS-802-11-ARC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-ARC&A=1 To unsubscribe from the STDS-802-11-ARC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-ARC&A=1 |