Subject: Re: RSVP Hello

From: Sean Crocker <[email-masked]>
Date: 27 Aug 2001 18:49:07 -0000

> A device (router) cannot send PathErr if it doesn't speak RSVP.  In 2205,
> there is mention of Path messages passing through non-RSVP clouds.  For RSVP
> flow reservations, this is fine, but for ERO/LRO's, this is not.  I would
> think that the only response a router would take that isn't RSVP aware would
> be to send an ICMP port unreachable message back to the source, as the UDP
> port isn't awake.  I am trying to preemt this by knowing ahead of time that
> a router is not listening to or processing RSVP messages.  There are
> procedures for recongizing whether or not LRO is supported, but not whether
> RSVP is supported.  Or am I missing something in the draft?

Chris,

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?

Sean

---------------------------------------
This message was sent by www.trinicom.com Webmail.

---

From: David Charlap <[email-masked]>
Date: Mon, 27 Aug 2001 15:23:12 -0400

Sean Crocker wrote:
> 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