The MPLS WG Archive

[Guangzhi Li <gli@research.att.com>]

Hi,

In RSVP-TE, section 2.5, it says"
The LSP_TUNNEL_SESSION object is used to narrow the scope of the RSVP session to
the particular TE tunnel in question. To uniquely identify a TE tunnel, we use the
combination of the destination IP address (an address of the node which is the
egres of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which
is placed in the Extended Tunnel ID field."

To apply RSVP-TE to MPLS, destination is the egress node IP address, source is the
ingress node IP address, both are placed in LSP_TUNNEL_SESSION object. Without
Extended Tunnel ID, you can not uniquely identify a TE tunnel.

It seems that both source and sender are ingress node when RSVP-TE talks about the
LSPs.

RSVP was originally designed for multicast applications, where sender and receiver
are clear. In MPLS, LSPs are not exactly applications anymore, I think.

-- Guangzhi

Eric Gray wrote:

> Marc,
>
>     In at least one case, the IPv4 address is required in the
> extended tunnel ID.  That case is described in section 4.6.4
> as shown below:
>
> =========================================================================
> 4.6.4. Reroute and Bandwidth Increase Procedure
>
>    This section describes how to setup a tunnel that is capable of
>    maintaining resource reservations (without double counting) while
>    it is being rerouted or while it is attempting to increase its
>    bandwidth.  In the initial Path message, the ingress node forms a
>    SESSION object, assigns a Tunnel_ID, and places its IPv4 address in
>    the Extended_Tunnel_ID It also forms a SENDER_TEMPLATE and assigns a
>    LSP_ID. Tunnel setup then proceeds according to the normal procedure.
> =========================================================================
>
> In addition, though I cannot find where it is explicitly stated right at
> the moment, I believe the IPv4 (or IPv6) address in the SENDER_TEMPLATE
> object is supposed to be for the ingress LSR on the LSP.  This is implied
> by the statement (on page 9, last paragraph in section 2.1):
>
> "The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION
>  object uniquely identifies an LSP tunnel".
>
> This statement would not be true if two separate ingress LSRs could
> each choose to use the same 'sender' when creating the SENDER_TEMPLATE
> object.
>
> --
> Eric Gray
>
> You wrote:
>
> > Several recent messages have concerned the issue of how to discern the
> > Ingress LSR's IP address.  Though it is true that some routers seem to put
> > it in the Extended Tunnel ID field of the SESSION object,
> > draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it.
> >
> > Furthermore, RFC2205 is not terribly clear about what the phrase "a sender"
> > means, which is used repeatedly in describing the workings of RSVP message
> > objects.  Assuming it means the Ingress LSR (the original sender) leads to
> > one interpretation, and assuming it means the LSR that sent the message
> > being examined (simply an RSVP peer, not necessarily the Ingress LSR) leads
> > to another interpretation.  I suspect, but am not certain, the latter
> > assumption is the correct one.
> >
> > It does seem reasonably unambiguous, however, that the Ingress and Egress IP
> > addresses are reliably to be found as the source and destination addresses,
> > respectively, of the IP header of PATH messages.  Quoting from 3.1.3 in
> > RFC2205: "Each message contains a sender descriptor defining one sender, and
> > carries the original sender's IP address as its IP source address".
> >
> >