Subject: Last call - RSVP problems

From: Jennifer Yates <[email-masked]>
Date: Fri, 25 May 2001 14:05:37 -0400

A number of potentially major protocol problems have been identified
within the OIF with the current signaling protocols (focusing on RSVP).
These problems arise in transport networks because the data plane is
separate from the signaling plane.

I don't believe these issues have been addressed on the mailing list -
if they have, please explain where.

****
Connection (LSP) teardown:
There is a problem with connection deletion in the current RSVP draft.
If a PathTear is sent in the forward direction (with say a
unidirectional connection), the first node (cross-connect) will delete
the connection and then forward the PathTear to the next cross-connect
and so on.

Since loss of light will propagate faster than the PathTears, all
downstream cross-connects will detect the loss of light and alarm on it,
possibly triggering restoration.  This is clearly unacceptable behavior.

The right solution is that the deletion message in the forward direction
should inform all of the nodes that the connection is being deleted, and
the actual deletion should propagate in the *reverse* direction.
Therefore, additional protocol extensions are needed to get the correct
behavior on deletion.

This issue has been already been discussed within OIF documents e.g.,
OIF2001.200 (RSVP Extensions in support of deletion confirmation and
maintenance during failure), and in the ITU e.g., "Signal flows during
exception cases". This issue does not appear to be reflected in the
GMPLS documents presented for last call.

****
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: Dimitri Papadimitriou <[email-masked]>
Date: Fri, 25 May 2001 20:47:55 +0200

Hi Jennifer,

At that i didn't raise this question but today it seems we
don't have a LoL propagation (except in all-optical networks)
so i was surprised that this question raised at the OIF
since dealing with SDH/Sonet UNI. So in most cases today 
"PathTear" is a link-by-link deletion process the LoL won't
propagate faster than the PathTear since you can now control
the signal deletion at each hop. Am i right ?

Notice this does not preclude to generalize the process as
proposed in your suggestion.

- Dimitri.

---

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

Dimitri:

Comments in line.

> don't have a LoL propagation (except in all-optical networks)

GMPLS was clained to work in all-optical networks.

> since dealing with SDH/Sonet UNI. So in most cases today "PathTear" is a
> link-by-link deletion process the LoL won't propagate faster than the
> PathTear since you can now control the signal deletion at each hop. Am i
> right ?

Even on a link, it is possible that the downstream node will delect LoL before
receiving the PathTear message. If the downstream node was engineered with
fault detection, some faked actions will happen, such as alarm or restoration.
Still, this is a problem.

- Guangzhi