Re: [STDS-802-11-TGAK] Suggested text for 802.11/802.1AC compatibility over the portal interface
Also, I think I've referenced this document before, to the TGak interested people, but just to be sure. You may be interested in this document, and similar architecture discussions contained therein: https://mentor.ieee.org/802.11/dcn/13/11-13-0115-10-0arc-considerations-on-ap-architectural-models.doc
Mark
-----Original Message-----
From: Hamilton, Mark
Sent: Tuesday, March 18, 2014 8:02 PM
To: 'Norman Finn (nfinn)'
Cc: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAK] Suggested text for 802.11/802.1AC compatibility over the portal interface
I'm still digesting this, but I think I'm aligned in concept.
That said, please look at https://mentor.ieee.org/802.11/dcn/14/11-14-0429-00-00ak-802-11-infrastructure-architecture-thoughts.docx which is short, and raw, but captures some random thoughts I had last night to try to clarify my comments about "a Portal is simpler than a Bridge" etc.
Mark
-----Original Message-----
From: Norman Finn (nfinn) [mailto:nfinn@xxxxxxxxx]
Sent: Tuesday, March 18, 2014 5:23 PM
To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: [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
_______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________