Re: Last call - RSVP problems

[suresh Katukam <skatukam@cisco.com>]

>

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.

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

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