The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

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".
>
>