Subject: RSVP_HOP Question

From: Michael Mandelberg <[email-masked]>
Date: Mon, 14 Jul 2003 22:28:51 -0400

This question has some overlap with GMPLS, but I'm hoping this is still an
appropriate place to ask it (if not, I'll redirect it). 
 
I am a bit confused about the usage of the Logical Interface Handle in the
RSVP_HOP object. My understanding of the LIH is that it helps the sender of
the PATH message to attach the RESERVE message to the correct "Logical
Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP object. In
addition to the LIH, it includes TLVs which contain an IP address, and an
Interface ID.
 
My question is, what relationship, if any, exists between the LIH in the
RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP?
 
My references are rfc 2205 top of page 50, and rfc 3471 page 26.

Thanks
 
Michael Mandelberg

---

From: David Charlap <[email-masked]>
Date: Tue, 15 Jul 2003 09:46:08 -0400

Michael Mandelberg wrote:
>  
> I am a bit confused about the usage of the Logical Interface Handle in
> the RSVP_HOP object. My understanding of the LIH is that it helps the
> sender of the PATH message to attach the RESERVE message to the correct
> "Logical Interface". Now in GMPLS there is defined an IF_ID RSVP_HOP
> object. In addition to the LIH, it includes TLVs which contain an IP
> address, and an Interface ID.

The LIH is used because in classical RSVP (and possibly also in RSVP-TE)
a Resv message does not necessarily arrive on the same interface that
its corresponding Path message went out on.

If our session is unicast, this is no big deal.  If it is multicast,
however, we need a way to determine which interface the arriving Resv
should apply to, since there may be multiple next-hop interfaces for the
flow (session/sender combination).  The LIH does that.  In each outgoing
PATH message, there's an LIH that uniquely identifies the interface.
When the Resv comes back, it contains the LIH of the corresponding Path
message (not the LIH of the interface sending the Resv) - this allows
the node receiving the Resv to make it all work.

GMPLS, however, does not use this.  The LIH mechanism is too simplistic
to accommodate all of the scenarios that GMPLS needs to suppot (for
instance, a separated control/data plane.)  So the IF_ID HOP object was
invented to provide enough data to make it all work.

> RSVP_HOP and the Interface ID in the TLV contained within the RSVP_HOP?

As far as I know, none.  The IF_ID TLV is used to perform a similar
function, but I wouldn't use anything from RFC 2205 to define its behavior.

-- David