Subject: Re: routing PATH messages

From: David Charlap <[email-masked]>
Date: Thu, 10 Aug 2000 17:48:14 -0400

alfred wrote:
> 
> I have a question regarding the treatment of PATH messages in a
> router.
> 
> A PATH message arrives at a router over interface I1. The preferred
> interface over which this packet will be forwarded is I2 (as
> determined by the nextHop in the routing table). DId the inventors of
> RSVP envision this as being the only way to determine the interface
> over which the packet will be forwarded?  Did they preclude the use of
> other mechanisms (like policy based routing or access-lists) to
> override the preferred nextHop from the routing table and forward the
> packet over some other interface I3.

RSVP is a signalling protocol, not a routing protocol.

As such, it is not RSVP's place to determine where packets get forwarded
to.  It is expected that some other program on the router (like OSPF,
ISIS, etc.) make that determination.

RSVP forwards Path messages based on the routing table because that is
how the data packets will be forwarded.  The Path (and the returning
Resv) messages must pass through the same routers that the data packets
pass through, or everything breaks.

So, if you need to run a routing protocol that forwards packets in
directions other than the shortest path (maybe it's policy-based,
constraint-based, or something else), you can do so.  If the router can
forward data packets in this way, it should (hopefully) be able to tell
RSVP which interface each flow will be using, and it will be able to
send its Path messages in the same way.

-- David

---

From: Retvari Gabor <[email-masked]>
Date: Fri, 18 Aug 2000 16:29:41 +0200

Hi!

> RSVP which interface each flow will be using, and it will be able to
             ^^^^^^^^^
> send its Path messages in the same way.

Just a short comment: identifying solely the outgoing interface along an
alternate path (i.e.: not the shortest one - there is no reference in
the kernel routing table) is not enough information for RSVP forward the
PATH message in the desired direction, as it provides no means to
determine the MAC addreess of the next hop along the path...please refer
to the linux-net list archive for further discussion...

	Retvari Gabor/BUTE-DTT

---

From: David Charlap <[email-masked]>
Date: Fri, 18 Aug 2000 12:57:16 -0400

Retvari Gabor wrote:
>> constraint-based, or something else), you can do so.  If the router
>> can forward data packets in this way, it should (hopefully) be able
>> to tell RSVP which interface each flow will be using, and it will be
>                     ^^^^^^^^^
>> able to send its Path messages in the same way.
> 
> Just a short comment: identifying solely the outgoing interface along
> an alternate path (i.e.: not the shortest one - there is no reference
> in the kernel routing table) is not enough information for RSVP
> forward the PATH message in the desired direction, as it provides no
> means to determine the MAC addreess of the next hop along the
> path...please refer to the linux-net list archive for further
> discussion...

1: There are more kinds of interfaces other than Ethernet.  Point to
   point interfaces don't use or require MAC addresses in their layer-2
   headers.

2: If the outgoing interface requires MAC addresses, then the
   information will be available, just like it is available for
   forwarding data packets out that interface.

-- David