RE: Question on LMP Fault Localization

["Baktha Muralidharan" <muralidb@cisco.com>]

Rich,

 

Thanks!.

 

So, if a Node (node A) sends a channel status to an upstream node (node B) indicating that it  (node A) is experiencing LoL, for node B does the following:

 

1. Figures out which LSPs are carried on the interface reported by node A

2. Each of the LSPs could be taking different route and so, could go out on a different interface off node B. Determines the corresponding "upstream side" interface for each of the LSPs.

3. On each of the "upstream side" interface, checks if it (node B) is receiving light.

4. If even one of the "upstream side" interface is receiving light,  then node B concludes that failure is clear on its' upstream side

 

Assuming a PXC (Lambda link switching) in this case, by the way.

 

Finally, it is interesting that a "lower level layer" (LMP) requires knowledge of "higher level layers" to perform its function. Was it by design?

 

Thanks,

/Baktha

 

---

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Bradford, Richard
Sent: Friday, December 10, 2004 2:32 PM
To: Baktha Muralidharan
Cc: ccamp@ops.ietf.org
Subject: Re: Question on LMP Fault Localization

At 12:44 PM 12/10/2004 -0500, Baktha Muralidharan 
wrote:
> I have question about LMP fault localization 
>   process. It appears that fault
> localization process requires that LMP be 
>   "LSP aware". All other LMP
> procedures, in contrast, are "LSP agnostic" and 
>   work only with interfaces.
>
> The LMP draft illustrates LMP Fault 
>   Localization with two examples. The
> configuration for the first example is 
>   as follows:
>
>        
>   +-------+        
>   +-------+        
>   +-------+        
>   +-------+
>        + Node1 
>   +        + Node2 
>   +        + Node3 
>   +        + Node4 
>   +
>        
>   +       +-- c 
>   ---+       +-- c 
>   ---+       +-- c 
>   ---+       +
>    
>   ----+---\   +        
>   +       
>   +        
>   +       
>   +        
>   +       +
>    
>   <---+---\\--+--------+-------+---\    
>   +       
>   +        +    
>   /--+--->
>        +    
>   \--+--------+-------+---\\---+-------+---##---+---//--+----
>        
>   +       
>   +        
>   +       +    
>   \---+-------+--------+---/   
>   +
>        
>   +       
>   +        
>   +       
>   +        
>   +       
>   +        
>   +       
>   +
>        
>   +-------+        
>   +-------+        
>   +-------+        
>   +-------+
>
>
> "
>    In the first example [see Fig. 2(a)], 
>   there is a failure on one
>    direction of the bi-directional LSP. 
>   Node 4 will detect the failure
>    and will send a ChannelStatus 
>   message to Node 3 indicating the
>    failure (e.g., LOL) to the 
>   corresponding upstream node. When Node 3
>    receives the 
>   ChannelStatus message from Node 4, it returns a
>    
>   ChannelStatusAck message back to Node 4 and correlates the 
>   failure
>    locally. When Node 3 correlates the failure and 
>   verifies that the
>    failure is clear, it has localized the 
>   failure to the data link
>    between Node 3 and Node 4. At that 
>   time, Node 3 should send a
>    ChannelStatus message to Node 4 
>   indicating that the failure has been
>    localized.
> "
>
> In 
>   the illustration above, Node 3 verifies that the "failure is 
>   clear",
> presumably by checking if the interface on its upstream side (i.e. 
>   facing
> Node 2) is receiving light. However, in this case, there is only one 
>   other
> interface (besides the one Node 4 reported on) emenating from Node 3 
>   and so,
> seems simple enough to check if that interface is receiving 
>   light.
>
> Consider the following, slightly modified configuration, in 
>   which Node 3 has
> multiple 
>   interfaces:
>
>        
>   +-------+        
>   +-------+        
>   +-------+        
>   +-------+
>        + Node1 
>   +        + Node2 
>   +        + Node3 
>   +        + Node4 
>   +
>        
>   +       +-- c 
>   ---+       +-- c 
>   ---+       +-- c 
>   ---+       +
>    
>   ----+---\   +        
>   +       
>   +        
>   +       
>   +        
>   +       +
>    
>   <---+---\\--+--------+-------+---\    
>   +       
>   +        +    
>   /--+--->
>        +    
>   \--+--------+-------+---\\---+-------+---##---+---//--+----
>        
>   +       
>   +        
>   +       +    
>   \---+-------+--------+---/   
>   +
>        
>   +       
>   +        
>   +       
>   +        
>   +       
>   +        
>   +       
>   +
>        
>   +-------+        
>   +-------+        
>   +-------+        
>   +-------+
>                                           
>   | | | 
>   |
>                                           
>   | | | 
>   |
>                                           
>   | | | |
>
> How does Node 3 know which interface to check to see if the 
>   failure is
> further "upstream"? It looks like Node 3 needs LSP route 
>   knowledge to locate
> the "upstream" interface (corresponding to the 
>   interface Node 4 reports on)?
Yes, LMP needs to know this 
information.

> If yes, how will the LMP instance 
>   on Node 3 gather the LSP information?.

It's left as an 
implementation detail. Presumably the LMP module in each node exchanged 
information with the signalling module in each node. It is already assumed that 
the LMP module provides control channel, data-link and TE-Link information to 
the local signalling and routing modules. This is a case where the direction of 
that exchange is reversed.
-- Rich


> Channel Status only provides 
>   interface ID.
>
> Thanks,
> /Baktha
> Cisco Systems, Inc.