Last call - RSVP problems

[Jennifer Yates <jyates@research.att.com>]

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