Subject: Re: Re: path for RSVP-TE RESV message

From: "Arashmid Akhavain" <[email-masked]>
Date: Fri, 22 Feb 2002 21:34:05

Hi,

RFC 2205 in section 2.9 States that:

If the destination address does not match any local
interface and the message is not a Path or PathTear,
the message must be forwarded without further processing
by this node.

Isn't this a contradiction to what RFC3209 says?

Consider the diagram below where all nodes are
RSVP-TE capable nodes and they are all
directly connected.

        ----      PATH        ----
       |    |    ------>     |    |
       | N1 |----------------| N2 |
       |    |A              B|    |
       |____|                |____|
         |F                    C|
         |                      |
         |                      |
         |         ----         |
         |       E|    |D       |
         |________| N3 |________|
                  |    |
                  |____|

Based on 2205, N2 can build a RESV message, hands it
to IP as payload with DA = A. IP can either send it out
on interface B (most logical choice since it's N2's
local interface to the same subnet as A) or it can send it
out on interface C depending on the routing information in N2.

Are we saying that an RSVP-TE node must ignore its routing
table and it must always use the interface it received the
PATH message from to respond back with the RESV? Is
this the case for other RSVP messages as well?

If not, then if N2 sends the RESV out on interface C and N3
does not forward the packet to N1, the LSP is not going to
be established.

But if N3 forwards the packet to N1 without any further
processing, although N1 receives the RESV message through its
interface F, it can still identify the corresponding PSB (Note
that PSB is associated with link AB) and associate the arrived
label with link AB.

Regards,
Arashmid Akhavain

David Charlap wrote:

>Leslie Wong wrote:
>
>I interpret it to mean that in RSVP-TE
>specifically (not in the classical RSVP), the
>RESV message must follow exactly the path taken
>by the PATH message in reverse order (which will
>effectively be the route of the data path).

This is correct.  And it will alwasy be true, unless your code is
very broken.

A node always sends a Resv message to the PHOP router.

With classical RSVP, it is possible that non-RSVP routers in
between yourself and the PHOP may cause the packet to go in a different 
direction.

With RSVP-TE, however, it is a requirement that
all RSVP routers be directly connected to each
other.  So the act of sending the Resv message
to the PHOP router will always send it out an
interface that is connected directly to that
router.  And this is the interface that the label
will be installed on.

-- David

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

---

From: David Charlap <[email-masked]>
Date: Mon, 25 Feb 2002 11:54:03 -0500

Arashmid Akhavain wrote:
> If the destination address does not match any local interface and
> the message is not a Path or PathTear, the message must be forwarded
> without further processing by this node.

Yes.

> Isn't this a contradiction to what RFC3209 says?

Where is the contradiction.  I just looked again and I don't see a
requirement that Resv messages must be dropped under this situation.

> Consider the diagram below where all nodes are RSVP-TE capable nodes
> and they are all directly connected.
> 
>         ----      PATH        ----
>        |    |    ------>     |    |
> Based on 2205, N2 can build a RESV message, hands it to IP as
> payload with DA = A. IP can either send it out on interface B (most
> logical choice since it's N2's local interface to the same subnet as
> A) or it can send it out on interface C depending on the routing
> information in N2.

Correct.

> Are we saying that an RSVP-TE node must ignore its routing table and
> it must always use the interface it received the PATH message from
> to respond back with the RESV? Is this the case for other RSVP
> messages as well?

Yes.  There are other cases where RSVP-TE must ignore the routing table
- like when processing a Path message with an ERO.  The packet has the
session address as its destination, but the next-hop interface is chosen
based on the first non-local subobject in the ERO message.

In general, all messages flowing downstream should be addressed to the
session address, and should have Router Alert set, so that they will be
processed by the proper intermediate nodes.  The next-hops chosen for
these messages should always follow the ERO (for non-Path messages, the
ERO will be stored from the most-recently-received Path message, and
should be available.)

All messages flowing upstream should be addressed to the PHOP address. 
And they should be sent out the PHOP interface.  Router Alert should not
be set.  Since the PHOP router is going to be directly attached
(non-RSVP routers are forbidden), this will guarantee that the packet
will be received on the correct interface as well.

> does not forward the packet to N1, the LSP is not going to

N3 will forward the packet.  It's an ordinary IP datagram addressed to
some other node.  Since the Router Alert option is not set, it should
forward the packet without processing it in any way.

> But if N3 forwards the packet to N1 without any further processing,
> although N1 receives the RESV message through its interface F, it
> can still identify the corresponding PSB (Note that PSB is
> associated with link AB) and associate the arrived label with link
> AB.

N1 will receive the Resv message.  And it can identify the PSB.  The
outgoing interface used by the Path message can be identified this way.

But such a scenario would not happen in reality, because RSVP neighbors
will always be directly connected under RSVP-TE.  The packets will
always be delivered directly to the neighbor (even if the interface
doesn't match), unless the routing table is deliberately configured to
use a sub-optimal route.

-- David