The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Bin Zhou wrote:
> 
> In RFC3209, there are two similar fields:
> 1. Extended Tunnel ID in Session Object, and
> 2. IPv4 Tunnel Sender Address in Sender_template Object.
> 
> The meaning of these two fields are defined as in the following.
> Extended Tunnel ID: Ingress IP address
> IPv4 Tunnel Sender Address: IP address of sender node
> 
> I think that the ingress node of a tunnel is the same as the
> sender of the tunnel. Is it right? If so, why define two field
> for the same purpose? How to use the Tunnel Sender Address?

They are not necessarily the same.

The sender address in the SENDER_TEMPLATE and FILTER_SPEC objects
actually define the sender.

The extended tunnel ID is a discriminator in order to distinguish
between two sesstions that have the same egress address and have the
same tunnel ID.  Without it, there would have to be an additional
protocol to prevent two different ingress routers from choosing
identical tunnel IDs.

By convention, an address on the ingress router (any address) is chosen
to be the extended tunnel ID - this can guarantee uniqueness.  Any other
method of guaranteeing a unique extended tunnel ID is also valid,
however.

Note also that a zero value for extended tunnel ID is also valid - it is
used when an ingress node wants to allow other ingress nodes to share
its session.  When SE style reservations are used, this will allow LSPs
from different ingress nodes to share resources along common links.

Finally, it should be noted that the LSR MIB does _not_ distinguish
between sender address and extended tunnel ID.  In other words, the MIB
is not capable of describing every possible combination of sessions and
LSPs that RSVP-TE is capable of creating.

-- David