The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

"Martin, Christian" wrote:
> 
> RSVP is soft-state in both its distribution mechanism and its
> framework for distribution.  So, although there is reservation
> state OAM, there is no way to determine of the reservation messages
> are being delivered properly in the first place, at least in the
> current vendor implementations.

Implementation is the big deal.  There is the concept of a Resv Confirm
message in RSVP - part of RFC 2205.

When used, the end-to-end handshaking changes from two way (Path-Resv)
to three-way (Path-Resv-Confirm).  If there is a need for the egress to
know that the LSP has been set up, apart from simply receiving labeled
packets, it can use this mechanism.

But, as you say, not all implementations support this.

> Back to RSVP-TE, let us do something similar.  Again, we have two
> RSVP-TE endpoints that we wish to build an LSP between.  During the
> reservation setup step, we discover that we are not receiving RESV
> or RESVERR messages back.  Hrm.  Where is the problem?  We can do
> pings and traces, but that does not inform us whether or not there
> is a nodal RSVP handling issue on one or more processing devices in
> the path.  But what device?!  This is where I see a problem.

This is actually covered in the draft.  Admission control errors, which
in RFC 2205 cause the generation of ResvErr, in the RSVP-TE draft cause
the generation of PathErr.  See section 4.7.3 of the RSVP-TE draft.

In the case of a failure that takes place after the LSP is set up, RSVP
Hello will detect the failure and appropriate PathErr/ResvErr messages
should be sent to the endpoints of the LSP.  I don't know about GMPLS
(where data- and control-planes are separate) but I would assume that a
similar mechanism exists there.

In other words, the ingress node will be told about the failure.  It can
then try again with different parameters or report the failure to
management.

-- David