Conference 7.286::fddi

re .0:

Each protocol will have its own technique for taking advantage of multiple
adaptors.

The beauty of a single DAS adaptor is that the failover is quick and transparent
to all protocols.  It is, however, a single point of failure.

Dual homing is not possible with SAS adaptors (even with two of them).  Dual
pathing is per protocol.  I strongly suggest connecting each of the two adaptors
in a system to different concentrators, otherwise, if you connected both to the
same concentrator, then it would be a single point of failure.

I will address only DECnet here for now (if you wish to discuss other protocols,
too, name them).  DECnet is available as two different products, Phase IV and
Phase V (a.k.a. OSI).

Phase IV on OpenVMS Alpha is an end node only implementation.  The support for
multiple lines is limited.  It is hampered by the design whereby it establishes
the MAC address to be a function of the DECnet node number.  This means you must
not connect the two adaptors to the same extended LAN.  If you did you would
constantly see side changes reported by the bridges.  The seperate LANs should
be connected together with a Phase IV DECnet router.  The circuit costs should
be set to different values for each.  All traffic will flow over the lower cost
circuit until it fails.  The higher cost circuit will take over without
disruption to active logical links via adaptive routing.

Phase V/OSI OpenVMS Alpha is also an end node implementation (for now). 
However, the support for multiple lines is much better.  It goes so far as to do
path splitting across the adaptors (there might be something akin to Phase IV
circuit costs (NSAP Selector?)).  It does not change the MAC address, so both
adaptors can be connected to the same extended LAN without driving the bridges
crazy.

    Hi,
    
    Thanks a lot for your reply.
    
    1. You mentioned dual homing is not possible with SAS. What would be
       the limitations of not having this. What are the other shortcomings
       vis-a-vis DAS.
    
    2. Also can I have fall-back with NSAP using SAS.
    
    Thanks again.

re .2:

The limitation of SAS, as far as dual homing goes, has mainly to do with
failover times.  Although to the user, dual homing and dual pathing seem to be
just about the same thing, they are different in the speed with which they deal
with component failures.

			Dual Homing
			-----------

	+--------+---+		+---+--------------+
	| system | A |----------| M | concentrator |
	+--------+---+		+---+--------------+
		 | B |--+
		 +---+  |
			|	+---+--------------+
			+-------| M | concentrator |
				+---+--------------+

Dual homing, as shown above, is an excellent way to configure.  It provides
considerable redundancy and very quick failover times.  However, it does have a
single point of failure, namely, the DAS board in the system.

			Dual Pathing
			------------

		+---+		+---+--------------+
		| S |-----------| M | concentrator |
	+-------++--+		+---+--------------+
	| system |
	+-------++--+		+---+--------------+
		| S |-----------| M | concentrator |
		+---+		+---+--------------+

Dual homing requires two SAS boards.  It eliminates the single point of failure.
However, the failover times will be longer.  Also, there may be added complexity
to configure each protocol for the additional board.

Fall-back, or fail-back, for NSAP (I'm assuming DECnet/OSI) is automatic and
transparent.  DECnet continues to try and bring the broken circuit back online. 
When it does recover, DECnet will route traffic over it appropriately.  All of
this is completely independent of DAS vs. SAS.  The only thing about DAS is,
depending on the failure, NSAP will have never been effected by the ring wrap.