The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:1998-Sep> msg00276



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Colored thread loop prevention

  • From: Eric Rosen <erosen@cisco.com>
  • Date: Mon, 21 Sep 1998 11:35:48 -0400
  • cc: erosen@cisco.com, mpls@netlab.indiana.edu
  • X-Emacs: Emacs 20.3, MULE 4.0 (HANANOEN)

LiWen Wu> There maybe some problems with the LSR which has multipath
LiWen Wu> capability.  

I don't think there is a problem. 

Let's restrict discussion to the ATM case. 

Suppose that an ingress (leaf) node  creates two paths for a particular FEC.
Then it extends two threads, each with a different color.

The only case that could possibly cause a problem is if the two threads meet
downstream at some  node which supports VC merging.  If  we simply apply our
normal procedures,  this node will  not know that  the two threads  have the
same leaf node.  I don't see that this breaks anything though. 

Now let's look at a  different case.  Some intermediate (VC-merging) node in
the path wants  to do load splitting.  Then there  will be multiple outgoing
links.   But since  we are  only talking  of ATM,  this means  that  it must
partition the set  of incoming links, with each partition  being mapped to a
single outgoing link.   Let's say that there are four  incoming links, A, B,
C, and D, and  two outgoing links, E and F, such that A  and B are mapped to
E, while C and D are mapped to F. 

In this case, the natural thing is to set the color and hop count of E based
on the  colors and hop counts  of A and B,  while setting the  color and hop
count of F based on the colors and hop counts of E and F.  Does this cause a
problem? 

If the thread  extended through E and the thread extended  through F meet at
some downstream node, I think the  normal procedures will work.  There is no
need to recognize that these threads have an upstream node in common. 

If you travel downstream of E and eventually arrive back at A or B, then the
loop is detected by the normal procedures. 

Suppose you travel downstream of E and eventually arrive at C or D.  This is
kind of interesting; if the path via F is loop free, this results in packets
received from A  and B traversing the node twice, but  there is not actually
any  loop, and  no loop  will be  detected.  The  packets will  be delivered
correctly.  The path  is suboptimal, but this is a  routing transient, so it
doesn't matter.

The scheme  thus seems  to me  to be compatible  with multipath  routing, at
least as it is likely to be realized by ATM-LSRs.