The MPLS WG Archive

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

Sean Crocker wrote:
> 
> Here's one way to do it that's been covered before, at least for
> MPLS-TE.  Given the following topology:
> 
> Upstream---Non-RSVP---Downstream
> 
> Upstream sends PATH.  Non-RSVP looks at it due to Router Alert
> option set.  It's not configured for RSVP, but it *should* forward
> it on to the true destination instead of discarding it.  I'd say
> *must*, but RFC2113 isn't clear to me on what should happen.  This
> is just an observation from experience.
> 
> When Downstream receives the PATH, the downstream performs a sanity
> check.  If the IP header TTL is less than the RSVP header TTL, then
> it's probably safe to say there's a non-RSVP neighbor by sending
> error code 24, error value 8 back to the PATH originator.
> 
> Some implementations do this, some don't.  Folks, is this
> considered a reliable enough mechanism to be specified in the
> RSVP-TE draft?

This is mandatory behavior.

This algorithm is described in RFC 2205.  In there, RSVP is supposed to
respond to a non-RSVP router by setting the "adspec break" bit in the
ADSPEC object.  This way, the egress router will know that the Path went
through a non-RSVP router, and that QoS reservations can not be
guaranteed.

In RSVP-TE, the PathErr for non-MPLS router was invented because MPLS
itself can't work if one or more node along the LSP doesn't participate
in the signaling.

-- David