Re: Question on LMP Fault Localization

["Bradford, Richard" <rbradfor@cisco.com>]

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.