[STDS-802-11-TGAK] Suggested text for 802.11/802.1AC compatibility over the portal interface
[Context ‹ reconciling remaining differences in the views of 802.1 IWK and
802.11 TGak with respect to the formalization of the
802.1D/802.1Q-to-802.11 interface that now resides in 802.1AC-REV Draft
2.0.]
In light of our discussion at the 802.11 TGak meeting, last night, I¹ll
offer two ways to solve the issue in the Subject line. The first choice
is in line with our tentative conclusion at the meeting. But, after
thinking about it overnight, I¹m leaning towards (my interpretation of)
Mark¹s sentiments, so I now prefer the second choice.
Choice 1: Add the following sentence to the end of the first paragraph in
802.11 Clause "4.5.2.2 Integration²:
For compatibility with IEEE Std 802.1AC, a portal can offer an instance of
the MAC data service primitives MA-UNITDATA.request (5.2.2) and
MA-UNITDATA.indication (5.2.3).
The word, ³can² is chosen so that this doesn¹t trigger a PICS entry.
There is no need to reference 802.1Q here; the interface is defined by
802.1AC. We don¹t need to state a year for 802.1AC, because all versions
(and 802.1D before it) say the same thing about the 802.11 interface used.
I selected just the request and indication primitives, because the
MA-UNITDATA-STATUS.indication primitive doesn¹t make sense in this context.
Choice 2: Add the following sentence to the end of the first paragraph in
802.11 Clause "4.5.2.2 Integration²:
A portal can offer an instance of the Internal Sublayer Service defined in
IEEE Std 802.1AC-2014 Clause 11.
Then, 802.1AC Clause 12.2.1 becomes one line long, stating that an 802.11
portal offers the ISS. The reason I like this one is that there is no
specification of exactly how a DS or integration function work. That
means there is no way to specify a mapping from the 802.11 MA-UNITDATA
primitives to whatever it is that they do, and hence, no point in
specifying a detailed service specification (5.2.2 + 5.2.3) and mapping
the ISS to it. If we simply say that the portal can offer the iSS, we
leave the mapping inside the undefined nebulosity. I think that this
addresses Mark Hamilton¹s unease about over-specifying the portal in
802.1AC.
I would much prefer changing ³can offer² to ³offers² in 4.5.2.2. It does
not constrains the implementer in any way, and closes the conformance gap
between 802.11 and IEEE 802. The problem lies with a number of obscure
parameters present in the ISS that don¹t apply to a portal. An actual
portal would ignore/set to 0 all but the essential ones. But, I fear
(perhaps needlessly) that the arguments with people who would be afraid
(naturally, but incorrectly) that this imposes new requirements on their
implementations would generate more mistrust than enlightenment. This is
something we can discuss on Thursday morning.
‹ Norm
P.S. On the other hand, we do need a firm interface between the bridge
and the generalized link, for the reasons discussed last night, so I think
we want to keep the infrastructure interface more-or-less as we have it,
so far.
_______________________________________________________________________________
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
_______________________________________________________________________________