Re: [STDS-802-11-TGAK] Suggested text for 802.11/802.1AC compatibility over the portal interface
"the portal provides the connection to a bridge"... Can that connection be because it is the "other end" (the end station at the end of) of an 802.3 link connected to a bridge? I think you have some more intimate "connection" to the bridge in mind, but I'm unclear what it is.
You also lost me completely with the comment about two or more MSAPs per medium instance. Do you mean the controlled port and uncontrolled port "MSAPs", or something else?
As to what 802.11 people generally think - I'd be willing to bet most 802.11 people have never thought about the problem. :) That said, If you asked a bunch of random 802.11 people if a Portal required a bridge (or something like it??) to be "above" it in order to make it functional, I suspect you'd get some strong negative response. Again, not they had ever thought about it before, but they'd be pretty sure that was not how it worked anyway...
Mark
-----Original Message-----
From: Norman Finn (nfinn) [mailto:nfinn@xxxxxxxxx]
Sent: Wednesday, March 19, 2014 3:12 AM
To: Hamilton, Mark; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] Suggested text for 802.11/802.1AC compatibility over the portal interface
As usual, you ask a good question. We actually could define the portal the other way around.
The reason I think it’s easier for the portal to offer, rather than use, the service interface, is that, among its purposes, the portal provides the connection to a bridge. A bridge, by the ISO 7-layer model, is a user of the MAC service, not a provider of the MAC service. If the definition of a portal is that it is also a user of a service, then we have to postulate an instance of a virtual MAC service with two MSAPs to connect the portal to the bridge. If you insist on saying that the portal is a user of the service, we can handle it. It simply means that 802.1AC has to define a virtual LAN that offers a point-to-point service to connect the portal to the bridge. We can go there, if you think that corresponds more closely to how a portal is perceived by 802.11.
Every other dot group in IEEE 802.1 provides two or more MSAPs per medium instance. That’s what 802.11ak provides (one two-MSAP service per non-AP station). 802.11 can certainly choose to provide some number of MSAPs (STAs and GLK SAPs), and to also be the user of one MSAP (portal).
802.1AC can deal with that, although it’s kind of ugly. But, if most
802.11 people see the portal as looking down, not up, that might be the least obnoxious solution.
Which do you prefer?
I agree with your last point, also.
― Norm
-----Original Message-----
From: <Hamilton>, Mark <Mark.Hamilton@xxxxxxxxxxxxxxx>
Date: Wednesday, March 19, 2014 at 16:13 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
>Let's discuss face-to-face if we can.
>
>I'm missing why the Portal can't be a service user, of a MAC Service
>offered by the non-802.11 network at the point it touches the
>Portal/Integration function.
>
>Also, remember that a Portal can connect to a non-802 network, too. I
>know we're only suggesting putting in "can" language, but if we're not
>careful it leads people to a (false) assumption that we always mean to
>connect to 802 networks only.
>
>Mark
>
>-----Original Message-----
>From: Norman Finn (nfinn) [mailto:nfinn@xxxxxxxxx]
>Sent: Wednesday, March 19, 2014 1:33 AM
>To: Hamilton, Mark; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
>Subject: 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-infras
>>t ruc 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
_______________________________________________________________________________