Conference 7.286::fddi

1. Yes, that is planned.  I don't know if that capability is available yet.

2. That can work.  It depends on the DAS.  Some would support it, some might
   not.  The concentrator allows it.  (This is because the decision to support
   dual homing is made only by the node "at the bottom".  The concentrator
   "above" always allows it.)

	paul

    Paul,
    
    Your previous comment says "The Concentrator Allows it."  Is this in
    the context of being the top device ?  By "planned", do you mean that
    the code is being planned to make our DAC work as the "bottom" device in
    the .0 configuration's Dual-homed topology ?
    
    I would assume that the "A" and "B" port's ring configuration code
    would need to be updated.  Is the algorythm an FDDI standard (like
    Ethernet's "spanning tree") or vendor-specific, to determine redundant 
    links to the same ring ?  
    
    JR
    

In dual homing, you have a station (which may be a concentrator) connected
by both its A and its B port to M ports of concentrators.

In other words:

	+-------+	+-------+
	|   X	|	|   Y 	|
	+-------+	+-------+
	       M\	 /M
		 \A    B/
		+--------+
	        |    Z	 |
		+--------+

So Z is dual homed to concentrators X and Y.  (Z might be a DAS or a DAC,
I didn't show that and it makes no difference.)

According to the ANSI topology rules, X and Y are always willing to accept
these connections.  For an M port, both an A port and a B port are acceptable
neighbors.  That's why I said "the concentrator allows it" on question 2
in .0.

However, again according to the ANSI topology rules, Z is NOT required to
allow both connections.  If it doesn't, it's supposed to give precedence
to the one on the B port.  If Z allows both connections to be present, then
we say it supports dual homing.  If it considers one of those connections
(presumably the A connection) to be an error, then it does not support
dual homing.  So in other words, it's up  to the station "at the bottom"
to support, or not support, dual homing.  

Dual homing is described by the standard; it's not a DEC specific extension
or anything like that, and doesn't require additional protocols.  But it is
an optional feature and stations may or may not implement it.

As far as our products are concerned: dual homing of DEC concentrators
is a committed capability.  In other words, Z could be a DEC concentrator
which is using the link from X as a standby link.  This capability wasn't
originally included, and I don't remember whether it is available already or
is scheduled for availability in the near future.  To get that answer,
please talk to the product manager.

	paul

    Hi,
    
    At a resent product update presentation I learned the v2.3 of the
    DEFCN firmware supports "dual homing". This version is available in 
    November 1990
    
    Regards,
    	Torgny...
    

   I believe I got this correct but I would appreciate a 2nd opinion since this is for
   a large aerospace company here in Seattle...

   My customer wants the redundancy that dual-homing provides but would also like to
   double up on the concentrators as well in order to eliminate any single points of
   failure between the dual backbone and a remote facility.  He also wants to
   eliminate the necessity for having more than two fiber runs due to expense.  I
   believe the following does this without breaking the config rules.  

   a). The question that this config poses is whether an M connection in a dual homing
   config can be made at any depth in the hierarchy, anywhere in the tree.  DC500 #5
   below gets it's A-M connection from DC500 #4 which is *NOT* a component of the dual
   backbone, nor is it's connection at the same level in the tree as it B-M connection
   (For the sake of simplicity, ignore the DC500-1 to DC500-4 link below to answer the
   above).

   b).  Would the DC500-1 to DC500-4 backup link serve as just that?, i.e., as a backup
   link for the situation where the DC500-2 to DC500-4 link goes down (also assuming
   that the DC500-3 to DC500-5 link is also bad) ?



        +------------+            +------------+            +------------+       
 <======|  DC500 #1  |============|  DC500 #2  |============|  DC500 #3  |======>
      A +------------+ B        A +------------+ B        A +------------+ B 
                  |M                         |M                        |M 
                  +----------------+         |                         |  
       Facility Boundary+++++>     |         |                         |  <++++++++++
                                   |         |      +-------- +        |  
                                   |A        |B     |         |A       |B 
                                  +------------+    |       +------------+
                                  |  DC500 #4  |    |       |   DC500 #5 |
                                  +------------+    |       +------------+
                                          |M        |                       
                                          +---------+


   James Timmerman

That topology is perfectly legal.  A-M and B-M connections are valid at any
place, any level.  The A-M will serve as backup when there's also a B-M
present.

On the other hand, the topology shown IS somewhat unusual.  The more common
approach is to construct a regular hierarchy, where each level connects to
the levels directly above and directly below only.  There is no technical
reason for limiting it that way, but it helps keep things simple and
unconfusing.  If there's a good reason for doing differently here, that's fine.
But if the customer doesn't have a real preference, I'd recommend the
usual configuration, simply because it will be more familiar to more people
and therefore easier to design and maintain.

	paul

   Thanks for the reply.  I hope the right people appreciate how useful and
   e$$ective this forum is.

   The reason for this config is that it provides full redundancy for media
   paths *and* electronics with minimal fiber pairs.  I understand that worrying
   about fiber count is usually the wrong metric but in-place interfacility
   fibers are in quite a different cost category than planned or intrafacility
   pairs.  This config also provides non-stop operation across both
   concentrators if a back hoe gets one of the paths.  The standard way of
   configuring dual-homed concentrators would require 4 pairs vs. 2, and would
   not provide non-stop operation across both concentrators if one of the 2 
   fiber runs got chopped. 

   Any potholes in above? If not...

   I saw your comments on some other hopelessly convoluted configurations and
   agree with your 'keep it simple' strategy for these cases.  If understanding
   the config in -.1 can be resolved to any M port from an A or B, would you 
   say that the trade off (deviation from 'standard' config) makes $ense?

   Jim Timmerman

    Doesn't your configuration require THREE pairs across the facility
    boundry?
    
    Also any stations in the "lower" facility would have to connect to BOTH
    of DC500 #4 and DC500 #5, otherwise the redundant concentrators don't
    buy you anything.  (stations connected to DC500 #4 lose connectivity if
    DC500 #4 goes down, and likewise for stations connected to DC500 #5).

Thanks for pointing this out.  Let me back off to this:

Assuming fiber pairs are still scarce enough that I can justify 2, period.
With the config in .5 minus the link between DC#1 and #4 (i.e., only 2 
links), I'd have fully redundant paths and electronics, and a manual 
recovery procedure to effect recovery from media faults. The reconfig would 
consist of patching the B port of the disconnected concentrator to an M port 
of the other.  

I agree that this is boiling down to a nit, but this is very helpful for my
understanding.  I should probably get my client to scream for at least one
more pair.

Thanks

Dual homing N devices requires 2*N pairs, and 2*N concentrator ports at the
level above.  That's obvious from the definition.

So if you have only two pairs available, you can dual-home ONE device.
A way of doing that would be to have a single concentrator at level 2, 
connected by the two pairs to two top-level concentrators.

Obviously, that single concentrator would be a single point of failure --
but you would have automatic protection from cable faults.

Alternatively, you can have two devices single-homed on the two pairs.
But if you do that, the devices below are NOT protected from cable faults.
(Example: two concentrators at level 2, to which is connected a DAS at level 3.
The DAS is dual-homed with the left connection standby and the right active.
If the fiber feeding the right concentrator fails, that will NOT cause the
M-port for the DAS to shut down.  So while the DAS is still talking to the
right concentrator, that concentrator now has no one else to talk to.

If you want redundancy, you must pay the price.  To protect from cable breaks,
dual-home.  To protect from concentrator failures, double the concentrators
and dual-home what's below.  If you want to be protected from both faults,
you end up with 4*N cable pairs.  That's just the way the picture ends
up being drawn...

Given how big your particular aerospace customer is and how much they have
riding on this, it is absolutely silly to try to save pennies on fiber at
the expense of complexity and vulnerability!

	paul

    OK, how about this....
    
          _________              _________
         |         |            |         |
    -----|A       B|------------|A       B|----------- Dual Ring
         |___M_____|            |____M____|
             |                       |
     ...... / ...facility boundary... \ ......
            |                          |
          __|______              ______|__
         |  B      |            |      B  |
         |        A|_          _|A        |
         |______M__| \        / |__M______|
                 \    \______/____/
                  \_________/
    
    
    	This leaves two fiber pairs between facilities and maintains
    connectivity for the Mports on the lower concentrators if either of the
    inter-facility links is damaged.  This is marginally better than a
    single dual-homed concentrator in that if one of the lower
    concentrators dies then the stations connected to the other one will
    still have connectivity.  If a single dual-homed concentrator dies then
    all stations below it lose connectivity to the dual ring.
    
    	It should be stressed that the DC500 is designed to be a
    high-availablity device.  It's simple design, multiple levels of fault
    bypass and way-overrated power supply all contribute to a high MTBF.  I
    don't know what the actual MTBF figure is.
    
    
    	Late-breaking thought!!!!
    
    Why not bring the dual-ring between facilities???????  That's only two
    fiber pairs.  Then you get the inherent protection of the redundant
    ring.
    
    
    
          _________              _________
         |         |            |         |
    -----|A       B|_          -|A       B|----------- Dual Ring
         |___M_____| \        / |____M____|
                      |      |
              _______/        \_______
             /                        \ 
          __|______              ______|__
         |  A      |            |      B  |
         |        B|____________|A        |
         |_________|            |_________|
                                     
                 
    If either of the lower concentrators fails, the stations on the other
    one remain connected.  And this does not waste M ports on any of the
    four concentrators.
    

Far out.  I hadn't thought about that first setup; it seems that it should
work (though of course it doesn't generalize to more than two devices).
It may cause dizziness among the network support people, though...  :-)

Bringing down the dual ring will also work.  On the other hand, the dual ring
is the most vulnerable part of the network and it's usually best not to
let it go between multiple buildings.

If you can't get more fibers, Steve's suggestions make sense, but I'd still
push for more fiber as the preferred approach.

	paul

   The fiber count drill for this account is actually real.  They have lots of
   money, but not the magnitude it would take to open up streets and manholes.
   Also, the notion that this account doesn't have to pinch penneys or that it
   is still a cash cow for us is in the process of getting a harsh check that
   will upset quite a few lives very soon.

   If the config in .11 is actually a working solution, and they discover this
   later on their own, please believe me, it will directly affect my personal
   success with this client.

   Thank you both for the responsive contributions!

   Jim Timmerman
   

I never meant to suggest that you should hide these options from them --
only that you should recommend the "conventional" approaches in preference
to these somewhat unusual layouts.

	paul

    OK, General enough ? It should be legal...
    
          _________              _________              _________
         |         |            |         |            |         |
    -----|A       B|------------|A       B|------------|A       B|- Dual Ring
         |___M_____|            |____M____|            |_____M___|
             |                       |                       |
     ...... / ...facility boundary... \ ...... ............./.......
            |                          |                    |
          __|______              ______|__            ______|__
         |  B      |            |      B  |          |      B  |
         |        A|_          _|A        |         _|A        |
         |______M__| \        / |__M___M__|        / |_________|
                 \    \______/____/     \_________/
                  \_________/
    

Cute.

Perhaps we should call that topology "dual homed braid"

:-)

	paul