The MPLS WG Archive

["Martin, Christian" <cmartin@gnilink.net>]

OK.  So we have a detection mechanism during the failure.  Looks as if the
vendors aren't reporting this in the debug output.  Either way, this is an
after the fact detection mechanism.  What I was looking for is a way to
determine if the path is RSVP-aware end-to-end before an LSP is being
established, or even worse yet, rerouted.  Thanks for clarifying this.

chris

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Monday, August 27, 2001 3:23 PM
> To: mpls@UU.NET
> Subject: Re: RSVP Hello
> 
> 
> 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
>