Conference 7.286::fddi

I have had the same request from two customers, but it is my understanding 
that FDDI would only offer a LAVC type cross connection not an alternative to 
the SC connection.  

Don't hold your breath for an SC/FDDI interface.

The copper based current solution also precludes multibuilding clusters and
raises some concern where redundant computer rooms with separated power 
distribution is used.

Kevin H.

ok, I see a couple:
	-multiple buildings
	-power isolation
	-longer distances

But I sense that you're asking for more than that.  Please be explicit.
Please explain what is wrong with FDDI as an additional alternative to Ethernet.

I'll take a guess; you are concerned that using FDDI like Ethernet won't
have the performance that using FDDI like CI does.  If this is your concern,
can you be more explicit about what you mean by `performance'.

    
    Performance comes into it when we get down to the "nitty-gritty" of
    moving data - however it's the functionality I'm more concerned with.
    Namely, the ability to employ full blown clusters - HSC's etc. - with  
    all the capabilities of shadowing, failover and so on, rather than the
    more limited (?) LAVC capabilities.
    
    Reading .1  I agree with the idea of "shadow" computer rooms and
    campus-wide clustering techniques. Not everyone wants such
    functionality but looking at some applications areas like TP or
    customers with mission-critical usage, such features could be a real
    boon.
    
    As an aside/example, I work in Basingstoke where one of Digital's
    buildings recently burned down. The backup mechanisms in place proved
    to be very good but imagine what could be done if we we're able to
    employ multi-site clusters and disk shadowing - immediate off-site
    backup capabilities. Wouldn't the banking community etc. be interested 
    in that ?
    
    I've heard a little about HPPI as being a potential future CI mechanism
    - but won't this too be limited to small distances ?
    
    Rog

    Just to add to what Rog is saying. I am currently talking to a Bank
   , who wants to do just that. They have a large cluster of 9 nodes.
    In the next few months they will split it and have two clusters
    of 6 nodes each in two separate locations.
    
    They want to plan for two years out and would like to utilise each
    site as a total backup for the other. They ask about FDDI equivalent
    functionality as part of "an extended cluster - their wording".
    Could someone point me towards whomever could share our longterm
    thinking with me. This customer wants to plan with us, and therefore
    buy from us over the forthcoming years. For us to help them I need
    to find out what is really happening in this area.
    
    Many Thanks in advance,
    
    Shea.

    Shadowing over Ethernet is available in VMS V5.4.  This feature was
    demonstrated at DECUS last week - and not as a "technology
    demostration".  It was stated that this feature is in VMS V5.4.
    
    Since FDDI will be (to most Ethernet applications) just like Ethernet;
    this feature will work over FDDI.
    
    My understanding is that the host based shadowing out-performs the
    CI based shadowing in most respects.  So it's possible that this
    feature will give you what you want.
    
    If you want a real HSC-like disk farm sitting on the FDDI, I think
    you will have to wait a while until some figures out how to do it.
    It is very difficult to place read/write disks on the FDDI like we have
    on the CI.  The CI is a private communication medium for the cluster.
    This gives you security and management.  If you try to place a
    read/write disk on the FDDI, you have to add security and a new form
    of management.  This is not impossible, but it is different from CI.
    By making FDDI a non-cluster-only communication medium, it has been
    opened up for other protocols; like LAT, MOP, DECnet, TCP/IP, etc.

    Re: .2 & .5
    
    I'll have to take your word for it that "Host-based Shadowing" out
    performs HSC Shadowing.  However, in the more general "logical record
    servicing" case, I know that it take almost twice the CPU to service a
    LAVC I/O request as it would to service the same I/O request locally. 
    Additionally, these service request can only be supported on the
    "primary" processor in a multi-processor set, so scaling is an issue.
    
    I too have had numerous large customers inquire about extending
    Clusters beyond the boundaries of normal computer rooms.  When we were
    looking at an "active" star coupler there was hope that the next step
    might be a fiber extender for such a coupler.  It would not appear that
    we will have an "active" coupler now; where are we on product planning
    for extending clusters?

    The Cluster Program Office should know what's in store for the
    extensions to clusters.  I don't deal with the people in the Cluster
    Program Office so I don't know anyone in that group.  There may be
    more information in the CLUSTERS note conference.

	In the VAXclusters Futures session at DECUS two weeks ago,
	mention was made that `longer distances, potentially over
	media such as fiber' was being planned. (actually FDDI clusters
	announcement wasn't authorized for DECUS but is scheduled
	for concurrent announcement with the FDDI products)
    
    RE: .0
    
>    Are we still restricted to 45m cables to the S/C - hence 90m diameter ?
>    Are there any plans to expand on this length ?
    
	We are still restricted to 45m for CI cables but there are
	A/D efforts to investigate longer lengths.

>    Would FDDI lend itself to being used as a cluster connect ?
    
	Plan on it.  Announcement and sales update articles are
	being reviewed at the Pricing and Announcement Committee
	this month.

	On 5/29, PAC approved the annouuncement of FDDI VAXclusters.

The following is the PAC proposal that was approved at PAC. It is included
here by permission of the author.
+---------------------------+ TM
|   |   |   |   |   |   |   |
| d | i | g | i | t | a | l | Interoffice Memorandum
|   |   |   |   |   |   |   |
+---------------------------+


To:  PAC                          Date:  4 May 1990
                                  From:  Gailyn D. Casaday
                                  Dept:  VAXcluster Product Management
                                  Ext.:  297-6520
                                  Loc/Mail:  MRO1-2/S10
                                  Network Node: MVPS::CASADAY


Subject:  Program Announcement--VAXclusters on FDDI


1.1 DECISION REQUESTED

Approval of program announcement of addition of FDDI to list of
cluster interconnects supported by VAXcluster systems

1.2 PROPOSAL SPONSOR

      o  Bob Glorioso, VP, ISBS

      o  VAXcluster Systems Business Unit

1.3 PRODUCT DESCRIPTION (BRIEF)

VAXcluster Systems, introduced in 1983, combine up to 96 VAX systems
into one VAXcluster system, a single management and security domain.
The VAXcluster architecture is, of course, independent of the cluster
interconnect.  This announcement adds FDDI to the VAXcluster
interconnects currently supported:  the Computer Interconnect (CI),
Ethernet, and DSSI.  The addition of FDDI as a cluster interconnect
will allow a single VAXcluster system to be spread over a greater
distance than CI, while having higher bandwidth than Ethernet.

FDDI (Fiber Distributed Data Interface) is an ANSI standard employing
optical media.  At 100 Mbits per second, it is an order of magnitude
faster than Ethernet.  A single FDDI ring can be up to 100 kilometers
in extent, with 2 kilometers between stations on the ring.  Longer
interstation distances (up to 40 km) will be provided with single mode
fiber.

1.4 BUSINESS OBJECTIVE

This announcement will inform our customers that VAXcluster systems
(as well as VAX/VMS) are continuing to evolve and grow to meet
customer needs to connect multiple CPU's into a single system with
data sharing, incremental growth potential, investment protection, and
simplified system management.  We will ensure that our customers know


Subject: Futures Announcement for VAXcluster Systems            Page 2


that VAXcluster systems will continue to be a key to Digital's
high-end strategy.  This is important to keeping the VAXcluster system
add-on business (approximately $750M per quarter, with over 15,000
VAXclusters installed now) and to continuing the growth of the number
of VAXcluster systems.

1.5 WHAT IS TO BE DISCUSSED

      o  FDDI will be supported as a VAXcluster interconnect (in
         addition to the three supported now:  CI, Ethernet, and
         DSSI).  FDDI supplements CI, by providing a longer distance
         interconnect between CI configurations in a single VAXcluster
         system.  FDDI also augments Ethernet, by providing a high
         bandwidth interconnect for multiple Ethernet segments in a
         single VAXcluster system.

      o  High bandwidth moves out of the computer room--allowing
         support of several configurations important to our customers:

          -  A VAXcluster system, with a high-bandwidth interconnect,
             spread further than the current 90-meter diameter limit
             of CI.  For example, a VAXcluster system can be located
             on several floors in a building.  Thus, VAXcluster
             customers can take advantage of the surge in optical
             fiber wiring of customer premises with Digital's
             DECconnect Fiber Optic Network and AT&T's Premise
             Distribution system.

          -  A VAXcluster system spanning multiple locations to
             increase availability in the event of a disaster at one
             location.  For example, similar sets of equipment can be
             placed in two or three locations; should a fire or power
             failure put one location out of action, the other
             locations can pick up the work, with current data
             provided by VMS Volume Shadowing.

          -  A VAXcluster system with desktop devices increased both
             in quantity and power, linked to services.  For example,
             workstations and DECwindows terminals on Ethernet
             segments may use FDDI-connected file, application, and
             boot servers, with the simplicity of management that
             comes with a VAXcluster system.


      o  FDDI is more than a backbone--it's also a VAXcluster
         interconnect.

1.6 REASONS FOR NON-SENSITIVE STATUS

      o  Even with the recent activity in fiber wiring, many customers
         have not yet begun to implement optical fiber.  Careful
         planning is essential and a relatively long lead time is
         needed to plan these installations and configurations.  We
         need to notify our customers and sales force now that this
         option will be available to them.

Subject: Futures Announcement for VAXcluster Systems            Page 3


      o  Many customers, in the US and in Europe, have pressed us for
         CI-level bandwidth at NI-type distance.  Two projects,
         cancelled in the last few years, would have increased the CI
         distance.  We need to let our customers know that we will
         deliver a high bandwidth, long(er) distance cluster
         interconnect with FDDI.

      o  The components for a VAXcluster system with FDDI are being
         announced.  This announcement puts the components in one
         context (a VAXcluster system) and will make clear our
         intentions to support FDDI as a VAXcluster interconnect.

1.7 WHAT IS NOT TO BE DISCUSSED

      o  Availability or pricing of any of the components

      o  Specific configuration rules

1.8 SCHEDULE

      o  Sales Update, June 25, 1990

      o  DECworld, Boston, July--inclusion in FDDI announcements

1.9 TRAINING PROGRAM

The field will be informed through the Sales Update article.  A PID,
with script, will be available to provide further details and PID
training will be provided to the field.

Subject: Futures Announcement for VAXcluster Systems            Page 4



PROGRAM ANNOUNCING FDDI AS VAXCLUSTER SYSTEM INTERCONNECT

                              Gailyn D. Casaday     Laura Gawronski
                              DTN: 297-6520         DTN: 297-2044
                              MRO1-2/S10            MRO1-2/S10
                              HYEND::CASADAY        HYEND::GAWRONSKI

+-------------------------------------------------------------------+
|  o  VAXcluster systems expand their interconnect support to FDDI. |
|                                                                   |
|  o  VAXcluster systems, with a high bandwidth interconnect, can   | 
|     extend over multiple floors in a building, multiple buildings,|
|     and multiple Ethernet segments.                               |
|                                                                   |
|  o  FDDI is more than a backbone--it's a VAXcluster interconnect! | 
+-------------------------------------------------------------------+

VAXcluster Systems continue to evolve and grow, as the list of supported
cluster interconnects grows.  The VAXcluster architecture is, of course, 
independent of the cluster interconnect.  This architecture has allowed
us to expand interconnect support from the initial Computer Interconnect
(CI) in 1983, to Ethernet in 1986, then to DSSI in 1989, and now to FDDI.
                                                                       
Fiber Distributed Data Interface (FDDI) is an ANSI standard employing
optical media.   At 100 Mbits per second, it is an order of magnitude
faster than Ethernet.  The FDDI standard corresponds to the first two 
layers, physical and data link, in the ISO model.  VAXcluster customers 
can take advantage of the recent surge in optical fiber wiring of customer 
premises, using Digital's DECconnect Fiber Optic Network.

The addition of FDDI as a VAXcluster interconnect will allow a single 
VAXcluster system to be spread over a greater distance than CI, while 
having higher bandwidth than Ethernet.  FDDI supplements CI, by providing
a longer distance interconnect between CI configurations in a single 
VAXcluster system.  FDDI also augments Ethernet, by providing a high
bandwidth interconnect for multiple Ethernet segments in single 
VAXcluster system.

FDDI in a VAXcluster system makes possible several benefits that are 
important to Digital's customers:

o  Extensibility--A VAXcluster system, with a high-bandwidth interconnect, 
   can be spread further than the current 90-meter diameter limit of CI.  
   For example, a VAXcluster system can be located on several floors 
   in a building.  

o  Availability--A VAXcluster system can span multiple locations to 
   increase availability in the event of a disaster at one location.  
   For example, similar sets of CI-connected equipment can be placed 
   in two or three locations and the locations connected with FDDI; 
   should a fire or power failure put one location out of action, the
   other locations can pick up the work, with current data provided by
   VMS Volume Shadowing.  


Subject: Futures Announcement for VAXcluster Systems            Page 5


            [INSERT PICTURE OF FDDI LINKING 3 LOCATIONS HERE]


o  Desktop integration--A VAXcluster system integrated with Digital's
   powerful desktop devices provides increases in speed, capacity and
   power for desktop users using facilities provided by our servers.
   For example, workstations and DECwindows terminals on Ethernet 
   segments will be able to use FDDI-connected file, application, and 
   boot servers, with the simplicity of management that comes with 
   a VAXcluster system.

          [INSERT PICTURE OF ETHERNET SEGMENTS BRIDGED TO FDDI]


Start working with your customers now to plan VAXcluster systems with
FDDI!

Contact the authors regarding the proprietary information disclosure 
(PID) on this topic.

    This is great except there is IMHO a serious flaw in either the
    startegy or execution of this announcement. 
    
    The purported reason we are announcing this now is so that customers
    can plan for the FDDI as a cluster interceonnect. The protection
    of VMS, clusters, and cluster add-on business is the motivation.
    All well and good. However, the section 1.7 "things not to be
    discussed" says that we can not discuss specific configuration
    guidelines.
    
    Am I the only one awake here, or is it possible to plan for FDDI
    without specific configuration guidelines? Or is that part of the
    "Propreitary Information Disclosuer"?
    
    I assume that we will be able to start discussing specific
    configuration guidelines sometime soon...
    
    							/Bill
    

	RE: .11

	There is configuration information and then there is configuration
	information.  The customer being able to decide that they can use
	their planned FDDI backbone as a cluster interconnect is about as
	far as we can go right now... what the heck, WE don't even know how
	many nodes will work where on a FDDI network.  Would you rather we
	said "anything goes" and then let customers find out what combinations
	work?

	So, all that can be said is "install it according to current rules
	and things should work".

I think the major issue that most VAXcluster customers have is `When is DEC
going to replace CI?'  I hope that people in DEC recognize what a lot of
customers recognize: CI is obsolete.  We can no longer justify `VAXcluster
interconnect is limited to 50 meters because you can't get enough performance
at higher distances' when the see FDDI, 100 megabits, and 100 km on one page.

I feel that FDDI is too little, too late, when it comes to VAXclusters, but
at least we're now saying something about our direction, as late as it is.

    .13 states that people in DEC and customers recognize that CI is
    obsolete.  But...
    
    CI also gets you a disk farm that is independent of the timeshared
    CPUs.  I would assume that unless you can put a disk farm  (or
    functional equivalent) on the FDDI, you cannot assume that CI is
    obsolete (and should not imply that it is to our customers).
    
    And to put a disk farm on the FDDI, you must add management and
    security.  CI has implied security because it's a medium that is
    private to your cluster.  FDDI should not be sold as a cluster-private
    communication medium, so the security is not implied and must
    be designed into the disk farm and the cluster software.
    
    To me, this is the area where DEC has yet to spend some time if DEC
    wishes to make CI obsolete.  Is there anything being done for FDDI
    based disk farms?

I agree on the disk farm comment.

On the security comment: if you deploy FDDI in the same manner as CI,
then it will be equally secure.  In both cases you would be relying on
physical security.  Often that is the best way...

	paul

    Re: last two
    
    In storage, we are currently not planning FDDI-based disk farms.  As
    implied in other replies, it's not simply a matter of the physical
    connection, but the management of the information.  Today's clusters
    handle both the file management (HSC's know nothing about files) and
    lock management.  Those functions still need to be managed somewhere.
    
    But we're willing to listen to suggestions...
    
    -  David

    There are a number of things that make CI stand out over other
    current VAXcluster interconnects besides HSC disks (and BTW next
    generation CI disks).
    
    We now support multiple CI VAXclusters (i.e., for the VAX9000) so
    the IO bottleneck is becoming less of a problem (and we're working
    on other things to help this). You can't beat the security of a CI
    VAXcluster (there's no security like physical security)! CI has no
    routing header in the SCS so it has less bits to send between nodes
    than the NI or FDDI VAXclusters. With the right applications, even
    the existing CI systems could run faster than FDDI (140 megabits/sec
    vs 100 megabits/sec). You don't need CIXCD to achieve 140 Mb/s!
    And the list goes on but I think you get the point.
    
    CI is NOT obsolete!
    
    About the only things you could complain about is the diameter and
    therefore the handling ease of the CI cable and the 90 meter limit.
    
    When it becomes cost effective to replace the CI cable with some other
    cable then we'll probably do that. Thinner coax isn't that cable.
    Fiber isn't that cable. And TWP isn't that cable. Bottom line - CI's
    very inexpensive!
    
    Now, about the 90 meter limit. You can connect a whole lot of computers
    together within a 90 meter radius, so connectivity isn't the issue.
    We can connect systems around the world with common carrier lines so
    interconnectivity isn't the issue. So somebody must be worried about
    the VAXcluster computer room being burned down and losing the entire
    data center. If that's your concern then put the VAXcluster in a
    fireproof room (like the gov't uses for their SAC bases), backup the
    power with gasoline generators (like the hospitals use), and secure
    common carrier lines from the building and let AT&T worry about the
    rest!

    .17 makes it sound like there is no need to support FDDI clusters.
    
    HOw many people agree with .17?
    
    How many people agree with the statement "CI is very inexpensive"?
    I thought the cost of CI was "rather high". This is just an impression
    I have from talking with VMS folks. 
    
    						/Bill
    

    I want FDDI clusters,
    CUSTOMERS want FDDI clusters,
    and we want the cluster across the full width of the Ring.
    
    Engineering, Ya hear!? 
    ;?)
    
    hw

    I agree that CI still has lots of life left, and that there are
    certainly applications for CI.
    
    I must say, though, that this does *NOT* preclude other cluster
    interconnects! Given our experience here on MLO5-5 with Ethernet
    clusters and DSSI clusters, I can readily see why a customer would want
    FDDI clusters - this is not a slam on Ethernet clusters (they serve us
    quite well), but a statement that more bandwidth on a general-purpose
    interconnect would be quite useful.
    
    Another side issue is that in the ESB space, we are more likely to see
    a customer demand for FDDI than CI; thus we are more likely to think
    about providing an FDDI spigot than a CI spigot on our products. (Do
    *NOT* take this as a comittment or even a hint about FDDI on ESB
    products!)
    
    Disks and HSCs cloud this issue dramatically. 
    
    ...tom, MicroVAX 4000-(300+x) module designer

Our customer is the Queensland State Government. They are also our 
largest customer here. They currently have 
several large VAX clusters in their central computer centre CITEC. 
However thay also have several large clusters in the headquarters of the 
different government departments here in the capital. They are extremely 
worried about what will happen if one of their local computer centres 
burns down.

What they are looking for is some way of hooking ALL their computer 
centres together as one super cluster, so that in the even that one 
centre burns down they can still operate. This means volume shadowing 
between disks in different parts of the city. They are prepared to 
aggreate several of the computer centres outside CITEC so they have only 
a 2 site configuration to contend with, but would obviously prefer to 
work really distributed.

One scenario would be to put a large disk farm at CITEC which would be 
the shadow area for a number of the external sites. The shadows for the 
real CITEC disks could be at any one of the other sites, but for 
management reasons it would most likely be better to have only one site.

We have already been talking to them for several years about running 
fibre between all the sites just as an extended Ethernet, and they are 
just starting to come to grips with that. Now with the promise of FDDI 
VAX Clusters they see a possible solution for their real problem.

Q1.
Will FDDI VAX Clusters ba able to provide a solution to the above 
problem ?

Q2. When ?

Any other suggestions for a solution ??


Doug Rickard

Brisbane
Australia

    re .21
    
    see 83.*
    rgds,
    hw

CI is obsolete because
	- it requires a proprietary wiring system
	- it is severely limited in possible configurations
	- it is more expensive than the alternatives, for example, DSSI
	- it doesn't support what our customers want in terms of `superclusters'
	- CI does NOT conform to 802

DSSI is obsolete because
	- it was artificially constrained in size and distance

FDDI as a total solution is also obsolete because
	- it is expensive
	- it doesn't scale in terms of size
	- it doesn't scale in terms of speed
BUT!!! FDDI conforms to 802 !!!  (Note, FDDI is not an 802 protocol.)

NISCS is obsolete because
	- it doesn't lend itself to being implemented in hardware/firmware
BUT NISCS does conform to 802 (thanks to a bit of hackery) and can evolve
since it is implemented in software running on hosts that are getting faster
and faster

Now, the question is, what will replace these obsolete cluster interconnects?

The primary problem is evolution.

The clear advantage goes to those things that can be changed with each VMS
release and that can be connected with existing LANs.

So, the thing that replaces these obsolete component systems is anything that
conforms to 802.

With FDDI, it is possible to build a cluster of nodes, each with one vote and
place each in a different building on the same campus.  Now, if any one building
burns down, the other two systems, and the cluster, will continue running.

However, if you want to do the same thing on three campuses, you can't do it
with FDDI, unless you're a common carrier or cost is no object.  However, with
some of the newer common carrier services (digital service) and future services
(SONET), you will be able to build 802 conformant hardware to bridge FDDI
rings across long distances.

And, since 802 supports multiple protocols on the same `wire', an incompatible
802SCS can be introduced to run in parallel with NISCS, or NISCS can evolve
into a better protocol.  (The latter is happening on an ongoing basis.)

We already offer 802 VAXcluster storage servers; they're called VAX processors.
Again, they're performance makes them obsolete, and they were known to be
obsolete from day 0, but they were needed for migration and they will continue
to be part of the migration stratagy.  The real weakness with our storage
strategy today is that our high end storage can not compete performance wise
because it doesn't speak an 802 conformant protocol and therefore needs a
to use a bottleneck VAX to correct this problem.

I know of a number of people who think that we should not have developed non-CI
VAXclusters, but until they start arguing that DEC is too large and we need to
shrink in size, and are effective in convincing people like Ken Olsen of this,
then VAXclusters are going to continue to move away from CI.  And the reason
that this is going to happen is because our customers are going to ask for it
and our sales force will hopefully figure out how to sell it to them.

My message to the field: keep asking for FDDI clusters and FDDI storage, but
make sure that you can deliver before selling it.

My message to engineering: 802 is the most important industry standard to
support in every product that interconnects with another.  Today's 802 choices
are Ethernet/802.3 and FDDI, but others are coming, and fast.

    Re: .23
    
    I wish I knew what you're talking about  :-)
    
    For those of us (I'm assuming I'm not the only one :-) who are not
    quite as familiar with the terminology as you obviously are, can you
    please explain what "802" is?  I'm assuming it's some standard but,
    beyond that, I don't have a clue.  I would like to learn, however.
    
    -  David

Yes, "802" is a "standard", actually, a set of IEEE standards.  The set includes
802.1 which in various parts describes the 802 architecture and bridging and
more, 802.2 which defines the LLC (logical link control) and more, 802.3 which
redefines Ethernet and similar interconnects, 802.4, 802.5 which redefines IBM
token ring but not FDDI, 802.6, etc.

The key features of 802 are:

	1. flat address space usually defined by a 48 bit uid

	   This means that your address will normally be defined at the
	   factory, will be unique in the world, and will not change
	   no matter where you plug into the network.

	2. the service provided is connectionless

	   This means that the interconnect only deals with moving packets
	   and doesn't keep track of whether or not the packets were
	   successfully delivered

	3. multiple protocols are supported

	   This means that not only can the existing common protocols, DECnet,
	   LAT, NISCS, OSI transport, ARPA Internet IP, ARP, MOP, can
	   share the same network, but new protocols can be developed
	   which incorporate new solutions to old problems.

	4. all 802 LANs can be interconnected without regard for protocols

	   This means that bridges can be used to connect the different
	   kinds of LANs without knowing anything about the different
	   protocols being sent over the LANs.  For example, DEC's 10-10
	   and 10-100 bridges support all the protocols listed above plus
	   all others in use now and any future protocols yet to be designed
	   without any changes.

802 does define additional capabilities, but these are just the overhead of
all standards; mostly useless features that are included to get someone to
agree to the standard.  For example, 802.2 defines an immediate ACK mode
of operation similar to the way that CI works, but at this layer of the
protocol tower it reduces performance while increasing complexity and
restricting the topologies that can be supported in a practical fashion.
(Since this features is integral to CI protocol, CI is limited to 45 meters
without both changing the protocol and significantly reducing performance,
plus the CI adapters constrained in design.)

    re .-1
    
    802.4 (ISO 8802/4) - a bus utilizing token passing as access method
    			 ie MAP
    
    802.5 (ISO 8802/5) - a ring utilizing token passing as access method
    			 ie IBM Token Ring

    Re: last 2
    
    Thanks for the explanation.
    
    -  David