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 ---
Mark, Sorry I won't be there ... this is getting
really interesting. In your list of questions, you asked: ·
" Note the location of
the MAC SAP (designed with “(M)” in the figure). It is well
below the “top of the 802.11 stack.” But, also note that
above it is only “switching/filtering” type operations, that don’t
change the service provided. Is this acceptable/agreed?" I'm confused. Much of the text and several
of the figures go to great lengths to point out that APs do NOT have a MAC SAP,
and I believe we are all in agreement on that point. However, the first two
figures apparently apply to APs as well as non-AP STAs by inserting the approprait
"role specific behavior" in the box labeled as such. This implies
that APs have a MAC SAP. Also, text on page 6 reads " Consider the upper layers that are resident on the device we
colloquially call an “AP” (the management interface, for
example). " Is the management entity
really an "upper layer". I think not. It is "off to
the side". In particular, one would not issue an MA-UNITDATA.indication
to the LLC sublayer on receipt of a management or control frame ... because it's
not a data frame. The MAC sublayer is part of the data plane, and above it is
the LLC sublayer, not a management entity/service. Shouldn't we be careful
about this distinction? RR From: *** 802.11 Architecture
Standing Committee *** [mailto:STDS-802-11-ARC@xxxxxxxx] On Behalf Of Mark Hamilton All, I
have uploaded an update to document 11-15/540, here: https://mentor.ieee.org/802.11/dcn/15/11-15-0540-02-0arc-updates-to-revmc-5-1-5.docx. This
version adds new material in the section discussing how an AP’s
architecture should be shown and described in subclause 5.1.5. I plan to
have discussion on this during the ARC session in Wednesday AM1. FYI,
I’ve also requested time in TGmc to discuss this, Thursday afternoon. Thanks.
Mark |