|
NOW I see where you’re going with this, Richard!
Some 802.1 diagrams use a diagonal line to place the bridge relay function adjacent to the MAC layer, hence the “baggy pants” moniker for the diagrams. I’m guessing that’s where you’re going with this. Without it, there is a bit of confusion about whether
the bridge (or DS) relay function is a peer of, or below, the users of the stations’ MAC services.
I was tempted before the last meeting to do that, myself, but didn’t think it was worth the effort. If you want to give it a try, go ahead. But, because you only get two legs on the “baggy pants”, I found it difficult to be 1) clear, 2) accurate, and
3) hold the diagram down to 2 dimensions.
Another possibility is to have a slide that shows this idea, and explains why it’s there, but we use another convention in the rest of the diagrams. For instance, you could put the relays right where they are now, and put a “T” with a dotted vertical
on the stations to elevate them above the relay functions, while keeping the tops of the MACs all on one level.
Just a thought. Good luck!
— Norm
Thanks for taking the time to look over the slide and comment ... I value and appreciate your input highly!
RR
I don’t know whether I’ll be able to make the dial-in, but let me comment on the 11-16-0457 presentation.
The problem with the picture on the last slide is not that it is wrong. It’s that it says absolutely nothing, and therefore does
not serve a purpose.
[RR>] Yes, you are right. What I posted was a "work in progress" done "on the fly". The figure
was a last minute addition and not even close to being "complete", however it was somewhat useful for the discussions at the time.
If that seems harsh,
[RR>] It's not harsh; it's CORRECT! :^)))
let me explain what the purpose of the “complex” diagrams.
ISO defines a layering model in which entities at one layer provide services to higher layers and make use of services at lower
layers. This enables one to model functions in a way that makes it clear what happens when you connect them in various ways. It is essential to understand that there are no “side doors”. You connect with your peer by making use of a joint service (e.g. Two
MACs talking down to two PHYs linked by a wire). The ISO model is a consistent language. You can feel free to draw boxes just anywhere, if you want to (e.g. off the side of a MAC), but now you lose all meaning, because you’re operating outside the language.
A box on the side of a MAC has no semantics that can be related to the other functions.
What the complex diagrams show is exactly what connectivity you get in exactly what situations. It points out why DSs that employ
802.1Q bridges (and many do!) work. It points out exactly why the “one connection point to the bridged LAN” rule is essential. It shows exactly where you have to put “magic” to avoid silly packet flows caused by that rule. It does so in a language, like
mathematics, that is clear, precise, but not always trivial or obvious. That is the price of accuracy. The “complex” diagrams show you exactly where the issues are and are not, if you are worried about the question, “Do these diagrams make my DS implementation
non-conformant?” (The answer is “NO!!”)
The suggested diagram has the problem that, if I place a bridge on top,
[RR>] I would like to suggest that a bridge doesn't "go on top", and I have new diagrams to
show/explain why. Furthermore, it is the placing of the bridge "on top" that in some sense creates the problem. It doesn't belong there. To expand a bit, bridges do NOT use services provided by the MAC, they are a service INSIDE THE MAC sublayer. Putting
a bridge on top of the MAC violates the ISO 7-layer model. More to come ...
I have no idea whether the packets will loop or not, or whether I will have connectivity or not, because I don’t know what a side
door on a MAC means.
[RR>] It's not really a "side-door"; its a service in the MAC sublayer. The (.1Q) bridge functions
will prevent loops, provide connectivity, etc., because that's what they are designed to do. THat's what I meant by "do the right thing".
(“It does the right thing” is meaningless.) The “complex” diagrams tell me exactly what I need to know. Replacing precision with
ambiguity is not helpful.
[RR>] While that is certainly true, I hope that when I finish the presentation, all ambiguity
has disappeared and simple precision is all that's left :^)))
Cheers,
RR
All,
This is notice that the ARC SC will hold a teleconference on March 30, at 12pm (noon) ET, for 1 hour, to continue review
of a presentation on an alternate way to diagram 802.11 architectural concepts, especially APs, and by extension how TGak might be viewed as fitting into the overall architecture.
The draft agenda and join.me meeting information are below.
Mark
Draft agenda:
1.
Call to order, patent policy, attendance
2.
Review presentation on architectural descriptions – Dick Roy (SRA):
11-16-0457-00-0arc-802-11ak-802-1ac-stas-aps-dses-and-convergence-functions.pptx
3.
AOB
4.
Adjourn
Note that teleconferences are subject to IEEE policies and procedures, see:
–
IEEE Patent Policy
–
Patent FAQ
–
Letter of Assurance Form
–
Affiliation FAQ
–
Anti-Trust FAQ
–
Ethics
–
802 LMSC P&P
–
802LMSC OM
–
802 WG P&P
–
IEEE802.11 WG OM
==================
You have been invited to a
join.me online meeting
Join the meeting:
https://join.me/IEEE802.11
On a computer, use any browser with Flash. Nothing to download.
On a phone or tablet, launch the
join.me app
and enter meeting code: IEEE802.11
Join the audio conference:
Dial a phone number and enter access code, or connect via internet.
By phone:
United States -
Camden,
DE +1.302.202.5900
United States
- Detroit,
MI +1.734.746.0035
United States
- Hartford,
CT +1.860.970.0010
United States
- Los Angeles,
CA +1.213.226.1066
United States
- New York,
NY +1.646.307.1990
United States
- San Francisco,
CA +1.415.655.0381
United States
- Saugus,
MA +1.781.666.2350
United States
- Tampa,
FL +1.813.769.0500
Access Code 808-571-868#
Other international numbers available
==================
_______________________________________________________________________________
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 _______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________
|