Subject: addressing on RSVP PTEAR message

From: Marc Lewis <[email-masked]>
Date: Fri, 18 May 2001 15:03:53 -0700

I'm asking this question here because the "action" seems to be here, not on
the RSVP list.

RSVP-TE Path Tear messages travel downstream toward all receivers.  They are
required to be forwarded hop-by-hop without delay.

My question is: Should the IP destination be the next hop, or the egress
router?  RFC2205 doesn't seem to be clear on this point.  If the answer is
the IPDA should be the egress router, then that presumes the packet needs to
have the IP Router Alert option (otherwise the packet would simply be routed
by transit LSRs and not passed to the local rsvp module).  I have been
working under the assumption that only PATH messages had the Router Alert
option turned on.  

The RFC clearly states that RESV messages do not use the Router Alert
option, as they are forwarded hop by hop using the route from the RSVP_HOP
objects in the PATH messages.  If the PTEAR uses the router alert option, it
would make sense that the RTEAR also uses the router alert option.  However,
that isn't consistant with the RESV *not* using router alert.

My understanding was that the PATH messages used IP Router Alert, and were
addressed to the egress router, so that the rsvp implementation could
determine if non-rsvp capable routers were in the upstream path.

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Fri, 18 May 2001 18:22:04 -0400

Marc Lewis wrote:
> router?  RFC2205 doesn't seem to be clear on this point. 

IP destination address must be the session destination address; RA
option must be set. 2205 is quite explicit about it; see sec. 3.1.5 p42.

> If 
> the answer is

Path, PathTear and ResvConf are sent with RA set.

> that isn't consistant with the RESV *not* using router alert.

Resv travels upstream following Path state. At each hop the IP destination
address is that of the previous hop (derived from previously established
Path state).

> determine if non-rsvp capable routers were in the upstream path.

That's correct - one way is to compare incoming TTL with Send_TTL in the
common header.

Cheenu

---

From: David Charlap <[email-masked]>
Date: Fri, 18 May 2001 18:36:44 -0400

Marc Lewis wrote:
> 
> I'm asking this question here because the "action" seems to be here,
> not on the RSVP list.
> 
> RSVP-TE Path Tear messages travel downstream toward all receivers.
> They are required to be forwarded hop-by-hop without delay.
> 
> My question is: Should the IP destination be the next hop, or the
> egress router?  RFC2205 doesn't seem to be clear on this point.  If
> the answer is the IPDA should be the egress router, then that
> presumes the packet needs to have the IP Router Alert option
> (otherwise the packet would simply be routed by transit LSRs and
> not passed to the local rsvp module).  I have been working under
> the assumption that only PATH messages had the Router Alert option
> turned on.

It must be targetted at the egress router, using the router alert
option.

Keep in mind that Path Tear messages must be able to go through even
when a Resv message has not been received.  Until the Resv arrives, the
address of the next-hop router is unknown.

Also keep in mind that RFC 2205 was designed around multicast. There may
be several next-hop routers all hanging off of the same interface.  The
send the PathTear to each one individually would be a waste of
bandwidth.

> The RFC clearly states that RESV messages do not use the Router
> Alert option, as they are forwarded hop by hop using the route from
> the RSVP_HOP objects in the PATH messages.  If the PTEAR uses the
> router alert option, it would make sense that the RTEAR also uses
> the router alert option.  However, that isn't consistant with the
> RESV *not* using router alert.

Path, PathTear and ResvConfirm) all are sent to the egress router using
router-alert.  Resv, ResvTear and Hello are always explicitly sent to a
peer router - making router alert unnecessary.  Errors (PathErr and
ResvErr) are forwarded without processing by any transit nodes they pass
through, so there is no need to use router alert on them.

> My understanding was that the PATH messages used IP Router Alert,
> and were addressed to the egress router, so that the rsvp
> implementation could determine if non-rsvp capable routers were in
> the upstream path.

Router alert is not used to detect non-RSVP routers, but in order to
avoid breaking when these routers are present.  The TTL value in the
RSVP common header is used to detect non-RSVP routers.

It is also used due to an inherent inability to know the IP address of
the (possibly several) downstream RSVP routers that should be receiving
the Path message.  Since PathTear messages must go to the exact same
places, they must be transmitted with the same kind of IP header.

-- David