Subject: RE: Last call - RSVP problems

From: Fong Liaw <[email-masked]>
Date: Fri, 25 May 2001 14:16:39 -0700

Suresh/Vishal/Jen

>  -----Original Message-----
>  From: suresh Katukam [mailto:[email-masked]]
>  Sent: Friday, May 25, 2001 12:06 PM
>  To: [email-masked]
>  Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
>  Subject: Re: Last call - RSVP problems
>  
>  
>  >
>  
>  Vishal and Jen,
>  
>  One possible solution is that -
>  There are multiple types of persistency of circuits can be provided
>  
>  1. Tear down a Circuit if a control channel fails
>  2. Tear down a Circuit only if a data path fails.
>  3. Tear down a Circuit only when a Source Node or Destination Node
>  deletes by sending explicit messages.
>  
>  I guess, (3) is what normally happens in today's networks. 
>  Only Network
>  administrator deletes circuits through TL1/EMS etc when 
>  there are problems.
>  
>  (1) is achieved naturally by RSVP refresh mechanisms.
>  
>  (2) is achieved when Refresh Timers are set to Infinite (No 
>  RSVP refreshes)
>  and indicate in RSVP message that tear down when a Data Path Fails.
>  

"Infinite timer" is actually very problematice with RSVP. 
We have specifically recommend NOT to use this, after attempting
to do it.

>  (3) is achieved when Refresh Timers are set to Infinite. By default,
>  circuit is kept irrespective of failures.
>

Same as (2), any proposals that remove the refresh mechanism 
is going to be difficult to prove that all cases are covered.

Instead, we (will) recommend the following in OIF UNI document:
   
   Use RSVP Hello to detect control channel failure. 
   If a control channel failure is detected, LSPs states 
   are maintained as if a node continues to receive 
   RSVP refresh message from the failed control channel.
   The recommended Hello timer will be in second range,
   instead of ms range specified in RSVP-TE draft.  

   If a control channel failed permanently, manual intervention 
   may be required. This is to be studied.

p.s The text is currently being drafted as we type.

Regards,
-Fong  

>  Ofcourse, (2) & (3) introduces some problems when the control channel
>  comes alive. How do two neighboring nodes sync up on what 
>  circuits are
>  still alive and what is gone? This is kind of addressed in 
>  ATM and we could
>  borrow ideas from there. If we all agree on above 
>  persistency levels or just
>  with (3), then I can provide information on how to sync up 
>  etc once nodes
>  come back alive.
>  
>  Thanks,
>  Suresh
>  
>  
>  
>  >
>  > > ****
>  > > Signaling channel failure:
>  > > If any element along the RSVP signaling path of an LSP 
>  fails, the RSVP
>  > > soft state timer in nodes downstream of the failure will 
>  timeout and the
>  > > nodes will delete the LSP, even if the forwarding plane is still
>  > > working! When GMPLS is used to control a transport network, this
>  > > scenario will occur, since the reliability of control 
>  planes is likely
>  > > quite a bit lower than the cross-connects themselves.  
>  In transport
>  > > networks, the data plane reliability expectations are 
>  very high, and any
>  > > factor that increases the already steep challenge of 
>  meeting those
>  > > expectations is not acceptable.
>  > >
>  > > One of the cardinal principles of transport network 
>  architecture is that
>  > > control plane failure must *not* cause the data plane to 
>  fail.  This
>  > > point has been raised and acknowledged at the OIF, but 
>  so far does not
>  > > seem to have been addressed in any of the GMPLS drafts.
>  > >
>  > > Jen
>  
>

---

From: David Charlap <[email-masked]>
Date: Fri, 25 May 2001 17:49:27 -0400

> We have specifically recommend NOT to use this, after attempting

Eliminating refreshes over a link can cause a lot of problems in RSVP,
unless two things are done:

1: Hellos must be active on the link.  Without refreshes, the only
   way to detect failures is either Hello or loss of carrier on the
   fiber.  And loss of carrier won't happen in the case of a software
   failure.  Without Hellos, the only way to detect a software failure
   is missed refresh messages.

2: The reliable message delivery (MESSAGE_ID) mechanism of the RSVP
   Refresh Reduction RFC (Section 4 of RFC 2961) is in place on the
   link.  Without this, you can't be sure that a message sent was
   actually received.  Straight RSVP doesn't have a problem with this,
   because a missed packet will be repeated via the refresh mechanism.
   But if the refresh interval is very large, there must be some other
   means to make sure a message is delivered.

When both of these are in place, then there shouldn't be a problem
increasing the refresh interval to a very large amount, or infinite.

>    may be required. This is to be studied.

If you don't tear down state when a failure is detected, what's the
point of having a failure detection mechanism at all?

-- David

---

From: Guangzhi Li <[email-masked]>
Date: Fri, 25 May 2001 18:05:15 -0400

> We have specifically recommend NOT to use this, after attempting

What are the specific problems? RSVP uses soft state because the traffic
route may change. In transport networks, the working path does not change
except restoration. If you can explain more, that would be help.

Let's see whether we can cover these problems from other methods, such as
link layer hello and reliable transmisson.

> is going to be difficult to prove that all cases are covered.

Has anybody proved that some cases have not been covered ? or assume that it
will be difficult to prove that all cases are coved. The second claim may
not be enough to avoid the "infinite timer" solution. If there is a
fundamental requirement to require soft-state, the question will become
easy.

> p.s The text is currently being drafted as we type.

This is one solution. But GMPLS document does not include this.

Thanks,

-- Guangzhi