Re: [STDS-802-11-TGAK] Suggested text for 802.11/802.1AC compatibility over the portal interface
I’ll read the suggested document.
In the meantime, the only way you can connect a portal to a bridge is
through an instance of the MAC service. There are no other possibilities.
So, either we throw out any specification of the portal/bridge interface,
or 802.11 provides an instance of the MAC service. I think you’re getting
wrapped around the axle of wires vs. bridges vs. up vs. down, and there is
no need to. There is no magic in IEEE 802; however loose the definition
of the portal, it requires an instance of the MAC service, at or near its
edge, or it makes no sense in the 802 context. 802’s job is to connect
instances of the MAC service. Period. The old agreement (802.1D to
today) was that the portal offers the 802.11 clause 5 service. We can go
with that, we can go with the ISS service definition, we can define some
new MAC service, or we can say in 802.1AC that the connection between a
bridge and a portal is unspecified. (That option is definitely
available.) I’m trying hard to be flexible, but the MAC service is a sine
qua non for 802. Perhaps “at or near” is the key?
― Norm
-----Original Message-----
From: <Hamilton>, Mark <Mark.Hamilton@xxxxxxxxxxxxxxx>
Date: Wednesday, March 19, 2014 at 14:27 PM
To: Norman Finn <nfinn@xxxxxxxxx>, "STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx"
<STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGAK] Suggested text for 802.11/802.1AC
compatibility over the portal interface
>So, on further reflection, I'm not so comfortable with this. We can
>discuss further, of course.
>
>My thoughts/comments are:
>
>First, we need to be clear what side of the Portal we are talking about,
>when we say "a portal offers/can offer". Note that the side that
>attaches to the DS is already defined to use the DSS. So, we're clearly
>talking about the side that attaches to the non-802.11 network, but it
>would be best to say so explicitly.
>
>Second, though, do we have reason to think that this side of the Portal
>is offering a service ("upwards"), or is it a service user of some access
>service of the non-802.11 network (its MAC-SAP or ISS, perhaps, for
>example)? I'm stewing on this point, but would welcome thoughts
>comments. I note in particular that if the non-802.11 network is
>offering something like a MAC-SAP, and the portal is also offering a
>MAC-SAP/ISS type thing, then we need to introduce yet another forwarding
>function of some sort (and I'm suspicious this might have to be a
>bridge). This all seems to be complicating the portal a fair bit, which
>is the concern I was trying (unsuccessfully) to communicate last night.
>(As per my musings in
>https://mentor.ieee.org/802.11/dcn/14/11-14-0429-00-00ak-802-11-infrastruc
>ture-architecture-thoughts.docx, I think the portal is (or can be) a
>pretty simple animal.)
>
>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
_______________________________________________________________________________