The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jul> msg00071



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RSVP_HOP Question

  • From: David Charlap <David.Charlap@marconi.com>
  • Date: Tue, 15 Jul 2003 09:46:08 -0400
  • Organization: Marconi, Vienna VA
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

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.

> 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?

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