The MPLS WG Archive

["Feng, Mark" <m_feng@trillium.com>]

IMO, the Resv message should be sent out at the interface where Path is
received. This is true for RSVP-TE as indicated below; and it should be true
as well for classical RSVP. I don't see the value of querying the routing
table, since the path is known at this point.

The statement quoted below regarding the handling of message, IMO, does not
apply to unicast. Like David indicated below, all the messages traverse in
the reverse direction shouldn't have the router alert on. As a result, even
if the message arrives at a different router, RSVP module at that router
shouldn't even see it.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:David.Charlap@marconi.com]
> Sent: Monday, February 25, 2002 8:54 AM
> To: mpls@UU.NET
> Subject: Re: path for RSVP-TE RESV message
> 
> 
> Arashmid Akhavain wrote:
> > 
> > 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.
> 
> 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        ----
> >        |    |    ------>     |    |
> >        | 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.
> 
> 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.
> 
> > 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.
> 
> 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
>