The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Mar> msg00207



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

Between OSPF RSVP...

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Wed, 12 Mar 2003 09:21:37 -0500
  • cc: "mpls" <mpls@UU.NET>


In message <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>, "john151@libero
.it" writes:
> Hi all,
> I' m interesting in protection/restoration (P/R) mechanisms and after having 
> read some works, i' d like to do some observations.
> In a TE path protection scenario, there are works dealing with the use of RSV
> P-TE messages to signal, in  example, 
> a link failure.
> But could it have sense this other way of recovery?
> ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechani
> sm to advertise the all network that one link is broken
> ( ... using opaque LSA? ); then all nodes, receiving the LSA with this inform
> ation, could compute an analysis of what LSPs ( LSP having source in that nod
> e ) are interested by the failure. Then, in example, each node that wants to 
> do restoration in a MPLS scenario could make a Label Switching if there is a 
> Backup Path available. 
> This approach has some problem:
> -   a faster trigger on OSPF in detecting failure, since HELLO mechanism is s
> low;
> -   the prioriting of the sequence ---flooding LSA---  and  then ---computing
>  SPF algorithm--- to do faster;
> -   the adding of intelligence in each node to do the Switching.
> 
> I know that these are only some observations containing ( i hope few ) errors
>  and that aren't complete, but since i haven' t found any P/R mechanisms in a
>  TE scenario using OSPF ( or any optimized version of this ), i' d like to ma
> ke you a question:
> is this a possible way of study ( as an alternative to RSVP signalling ) or i
> s completely wrong and out of all standards?
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni Di Giacomo


OSPF/TE already uses the SONET framing detection to trigger fast
flooding of link down.  This is a FAQ.

Ingress then quickly find any affected LSPs (the quickly part is an
implementation detail, but reasonable implementations don't do a
search of all LSPs but rather have this information already available
as a data structure hung off the TE-LSDB entry for the link).

Presignaled disjoint backup LSPs from the ingress are known as
"standby" LSP and are implemented by most LSR as an alternate to FRR.
In practice, standby LSP provide anywhere from sub second to a few
second restoration AFAIK.  Otherwise the ingress must resignal the
affected LSPs on new paths.  This is supposed to take just a few
seconds but in practice if a lot of LSPs are affected most LSR seem to
fall back to IP forwarding and get the LSPs up in 10s of seconds.
Implementations are improving and getting this to consistently a few
seconds, even for large topologies and large numbers of affected LSPs
is being discussed elsewhere usually referred to as the "fast
convergence" problem.

LDP makes direct use of the OSPF derived next-hop.

Curtis