| 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 ---
Hi, Dick, First, thanks for actually scrolling down and reading those questions. We have not really gotten to those, and glad someone is starting… That said, those questions are also probably getting out-of-date, with respect to other recent discussions that we have had. And this one, in particular, needs clarification now. So, my thoughts/response on this one are that this SAP must now be carefully referenced as _a_ MAC SAP, not _the_ MAC SAP. In this terminology, I use _a_ MAC SAP to mean any SAP between
any entities within the data link layer, which: 1) offers a Service that is substantially the same as the defined MAC Service in 802.1AC, but may have additional features/behaviors; and 2) at least one of the entities is in the MAC sublayer. And, I use _the_
MAC SAP to specifically mean the example of _a_ MAC SAP which is provided by an entity (the “top-most” entity) in the MAC sublayer, to one or more entities in the LLC sublayer.
That is, there are lots of “sublayer” SAPs floating around within the MAC sublayer, some in MAC/PHY standards/stacks (like the one a couple layers down in that figure, not to mention, for example, the ones labelled
(C) and (U), which are also MAC SAPs) and some within 802.1 structures above the MAC/PHY standards (like 802.1AX, 802.1X, 802.1Q, etc). These are all MAC SAPs, technically. But, none of them are really what people mean (or think they mean) when they ask,
“Is that the MAC SAP?” What people mean when they ask that, is to be asking where is the special MAC SAP that is one that actually delivers the MAC Service to the LLC Sublayer. That is (now taking what they asked literally, even though
they didn’t realize they meant to be asking it that literally/carefully J), “Is that/where is, _the_ MAC SAP?” So, now, I can state that an AP has no _the_ MAC SAP. It does have multiple _a_ MAC SAPs. (Sorry about the grammar.)
Somewhere in some recent email (maybe not to the whole group), I mentioned that the legend that goes with Figure 5-1 needs to be clarified, and/or the drawing needs to be changed, to stop saying that the SAP
you referenced, which currently is shown as “(M)” and the legend says is “MAC SAP” (with no distinguishing article), might be _the_ MAC SAP. It is not. I think we need better terminology, so we can say all this with sensible words. That is all becoming clear as we try to push these concepts a bit further in 802.11ak (and hence this reflector thread has not
necessarily seen the discussion). That is a great topic for a next step discussion on this presentation/proposed text. Thanks! Mark From: Richard Roy [mailto:dickroy@xxxxxxxxxxxx] 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 |