The MPLS WG Archive

[Guangzhi Li <gli@research.att.com>]

Vishal:

If mpls WG agrees that these issues are problems in GMPLS and would like to fix
them before last call, there will be some possible solutions from different
contributions.

Jen provides a suggested procedure for the first one. A possible solution for the
second one could be to define an infinite refresh timer (never expires). Another
solution could be time-out without removing states, etc. Details need more work.

Thanks,

Guangzhi

Vishal Sharma wrote:

> Jen,
>
> Your points are well taken. My question is: will the carriers be willing to
> provide some suggested solutions to both these problems, particularly
> the second one.
> Perhaps having corresponding IETF documents addressing these
> problems and their possible solutions would help to move the
> discussion forward.
>
> -Vishal
>
> On Friday, May 25, 2001 11:06 AM, Jennifer Yates [SMTP:jyates@research.att.com]
> wrote:
> > 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