Re: [STDS-802-11-TGAK] [802.1 - 9678] Picture of Portal and DS that uses bridged network
Mark,
Thank you very much with your answer. I agree and fully understand your arguments and rationales. My struggle is as follows:
When it comes to bridges and especially connecting now DS to bridged LAN in the P2P model, the portal "mapping" operation is a key point.
In a bridge the "mapping" operation is well "self-bounded to the bridge" and the model of "distributed bridge" except for very specific cases was always seen a problematic approach. In my view the challenge is properly architect the interface between these two "concept" i.e. bridges with port "locality" on one side and DS on the other.
Again I apologize if I am not that clear. I could prepare a few slides for the next call to try to clarify my words.
Sincerely
/Philippe
-----Original Message-----
From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxxxxxx]
Sent: 09 May, 2013 17:31
To: Philippe Klein; STDS-802-1-L@xxxxxxxxxxxxxxxxx; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: RE: [802.1 - 9678] Picture of Portal and DS that uses bridged network
Hi, Philippe,
I believe my response would be that, from time to time, I struggle with each of the "boxes" or "blobs" in the 802.11 Figures. It seems that each of them has come up in some discussion as giving someone the impression that the function represented by the box/blob in the picture is mapped to a physical object. It comes up now in our discussion mostly for DS and Portal, because those are the concepts we happen to be wrestling with. But, I've said the same about AP (a LOT - there any MANY physical implementations of AP which are distributed through multiple physical objects), and even with non-AP STA (consider an older laptop with a Wi-Fi dongle plugged in via a USB cable as a trivial example). So, in general, I am often taking the stance of reminding everyone who asks questions like "where does such and such happen?" that they are asking a conceptual question, which might map to reality many different ways.
This extends to considering efficiency of implementation. Yes, it is quite easy to create a poor implementation of the 802.11 concepts. "Enough rope to hang yourself," I think is the common phrase. But, by being very flexible, 802.11 also has led to some very good implementations, and some innovative ways of bringing the concepts to reality which have changed the shape of the products and industry. I think the flexibility is very powerful and don't want to lose it, for sake of helping someone in particular avoid doing a bad implementation.
Now, two specific points:
"Portal" is a mapping operation. Less so than any other entity in the 802.11 architecture (except the DS), it's physical location and manifestation is very hard to specify or even identify in a real system. The good news is nobody tries to draw the DS in Figures as a "box". But, the Portal would be high on my list for things that aren't a "box", also. Maybe just a "fat arrow" between the DS "blob" and a non-802.11-network "blob"...? Anyway, as you say, it is a SAP (actually probably two SAPs and a mapping between them - but I have to think about that one), and we don't generally draw a SAP as a box. We draw a box (in this type of Figure - as opposed to a box _within_ a stack or _within_ an entity) when there is a reasonable chance of that being a physical thing or it probably has some form of physical manifestation because there is a HW component to it, etc. Since the Portal is little more than just a SAP, I don't see the value in the box, and do see the confusion it !
can cause.
You also mentioned interoperability. This is a key concern. Note that, for better or worse, 802.11 has explicitly _not_ tried to make the concepts of DS or Portal be interoperable. As we mentioned on a call recently, there was actually an attempt (a couple times, in different groups) to specify structure and protocol sufficiently to allow interoperability of these components, and those attempts all failed. We are left with a Standard which has intentionally left this unspecified and therefore very flexible but also leaves interoperability out of scope. It is an interesting and deep philosophical discussion - but one which 802.11 has decided at this point.
Lastly, let me leave you with a physical implementation model of 802.11 which is relatively common (although certainly not the only way, or only good way, to do it - each approach has pros and cons). Consider a very "lightweight AP" which is really little more than a radio (almost no MAC function, even). Connect a bunch of these to what otherwise looks like a set of Ethernet switches. Note that this connection between radio and the switch _might_ be 802.3, but could be anything. Now, those switches are, by definition, embodying the DS, as well as most of the MAC of the APs. Further, these switches do have standard 802.3 ports as well, and are connected together and to other switches, etc. to form the backbone of a wired 802 network. So, somewhere within the switches, and distributed between them, is the Portal. This is a nice and neat, and pretty efficient implementation, in general. I can't imagine how to draw the 802.11 concepts to overlay a figure of the physical!
boxes in this model. Does that help demonstrate the challenge?
Mark
-----Original Message-----
From: Philippe Klein [mailto:philippe@xxxxxxxxxxxx]
Sent: Thursday, May 09, 2013 7:58 AM
To: Hamilton, Mark; STDS-802-1-L@xxxxxxxxxxxxxxxxx
Subject: RE: [802.1 - 9678] Picture of Portal and DS that uses bridged network
Mark,
I apologize for mentioning the "Fig4-6 argument" as you answered it in a previous mail.
I still believe however the other remarks of my mail are relevant regardless of the representation of Fig4-6 argument.
/Philippe
-----Original Message-----
From: Philippe Klein
Sent: 09 May, 2013 11:45
To: 'Hamilton, Mark'; STDS-802-1-L@xxxxxxxxxxxxxxxxx
Subject: RE: [802.1 - 9678] Picture of Portal and DS that uses bridged network
Mark,
>> The Portal in Figure 4-6, IMHO, is unfortunate to be shown as a "box", because that leads to all sorts of confused thinking.
- in the 802.11 specs Fig 4-6 -802.11 Components" include a box called Portal....
- in 802.1Q Clause 6.7.2 Support by IEEE Std 802.11, the Portal presents a SAP so while I understand your notion of "concept" I do not understand while any other entity with a SAP you have issue with representing the DS as a box (or a "blob")...
Additionally the DS support services and these services are not just "conceptual" but which functionality could be described (if not specified)
I 100% understand why the DS was roughly defined but should we be "concerned" that keeping the lack of specification as is) could in our case lead to very inefficient implementation or very limited interoperability which both will undermine the effectiveness of the standard ?
/Ph
-----Original Message-----
From: IEEE 802.1 list HELP only [mailto:hdk-veuuft@xxxxxxxxxx] On Behalf Of Hamilton, Mark
Sent: 07 May, 2013 05:48
To: STDS-802-1-L@xxxxxxxxxxxxxxxxx
Subject: Re: [802.1 - 9678] Picture of Portal and DS that uses bridged network
Ballots due May 8: P802.1Q-REV/D1.0, P802.1AX-REV/D2.0 For particulars see
www.ieee802.org/1/email-pages/ballots.html
802.1 list help: www.ieee802.org/1/email-pages/zuwz1011.html
List administrator: hdk-veuuft@xxxxxxxxxx
-----
Norm,
I'm not sure what part doesn't square, so he's a few comments and hopefully something will help.
Figure 4-6 shows a DS, without any discussion of how it is formed. 802.11 never says anything about how a DS is formed. So, Figure 4-6's DS could well have bridges in it. Or, routers, or application relays, or a Tardis. Whatever. As long as it gets MSDUs to/from the right AP or Portal, it could comprise anything.
The Portal in Figure 4-6, IMHO, is unfortunate to be shown as a "box", because that leads to all sorts of confused thinking. That was part of why I drew the picture I did this afternoon - to highlight that a Portal is just a logical concept (as we said on the call). Somewhat like the DS, it could be instantiated any number of ways, as long as it fulfills the requirements of a Portal (the integration service).
So, if you picture Figure 4-6 with two bridges as forming the DS, and you accept that those same two bridges also form part of the non-802.11 LAN, and you let your mind consider the Portal the logical point at which these two facilities "touch" each other without concern for what "box" it is in, you end up with my picture.
Did that help?
Mark
-----Original Message-----
From: Norman Finn (nfinn) [mailto:nfinn@xxxxxxxxx]
Sent: Monday, May 06, 2013 6:40 PM
To: Hamilton, Mark; STDS-802-1-L@xxxxxxxxxxxxxxxxx
Subject: Re: [802.1 - 9675] Picture of Portal and DS that uses bridged network
That picture really confuses me, Mark. How does that picture square with, for example, Fig 4-6 of 802.11-2012? That picture doesn't show bridges, at all. Are you trying to show the new world and the Portal, both?
-- Norm
-----Original Message-----
From: <Hamilton>, Mark <Mark.Hamilton@xxxxxxxxxxxxxxx>
Reply-To: "Hamilton, Mark" <Mark.Hamilton@xxxxxxxxxxxxxxx>
Date: Monday, May 6, 2013 15:11 PM
To: "STDS-802-1-L@xxxxxxxxxxxxxxxxx" <STDS-802-1-L@xxxxxxxxxxxxxxxxx>
Subject: [802.1 - 9675] Picture of Portal and DS that uses bridged network
>Ballots due May 8: P802.1Q-REV/D1.0, P802.1AX-REV/D2.0 For particulars
>see
> www.ieee802.org/1/email-pages/ballots.html
>802.1 list help: www.ieee802.org/1/email-pages/zuwz1011.html
>List administrator: hdk-veuuft@xxxxxxxxxx
>-----
>
>Per the discussion on the Qbz/TGak teleconference today:
>https://mentor.ieee.org/802.11/dcn/13/11-13-0479-00-00ak-portal-diagram
>-wi
>th-ds-using-bridged-network.docx
>
>Mark
>
>
>===
>Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
>IEEE. Fostering technological innovation and excellence for the benefit
>of humanity.
===
Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@xxxxxxxxxxxxxxxxx
IEEE. Fostering technological innovation and excellence for the benefit of humanity.
_______________________________________________________________________________
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
_______________________________________________________________________________