Subject: RSVP-TE: How to use "Tunnel Sender Address"?

From: "Bin Zhou" <[email-masked]>
Date: Mon, 17 Jun 2002 09:34:52 -0400

Hi,

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?

Thanks for your answer in advance.

Bin

---

From: "Senthil K. Venkatachalam" <[email-masked]>
Date: Mon, 17 Jun 2002 12:53:05 -0400

At 09:34 AM 6/17/2002 -0400, you wrote:
>tunnel. Is it right?

Yes.

>If so, why define two field for the same purpose? How

Extended Tunnel ID was *ment* as an additional key to specify the tunnel/lsp
between two nodes. This is in addition to the (Src, Dst, Tunnel, LSP-id)
quadruple.

A popular way to fill this field is to use the src IP address of the LSP.
However, this behavior is not mandatory.

Regards,
Senthil.

---

From: "Bin Zhou" <[email-masked]>
Date: Mon, 17 Jun 2002 13:09:48 -0400

Thanks. Senthil.

In the quadruple (Src, Dst, Tunnel, LSP-id) you mentioned, the Src can be
provided either by Extended Tunnel ID field or Tunnel Sender Address field.

Can I use one of the two fields as a FEC for a host address since there
isn't a FEC element in RSVP-TE?

BTW, I read that guys of fast reroute or route protection are redefining the
Tunnel Sender Address.

Regards,
Bin

---

From: David Charlap <[email-masked]>
Date: Mon, 17 Jun 2002 13:22:41 -0400

Bin Zhou wrote:
> 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

---

From: Yuan Gu <[email-masked]>
Date: Mon, 17 Jun 2002 10:31:29 -0700

> isn't a FEC element in RSVP-TE?

Bin:

Are you trying to send FEC information to intermediate/egress node? FEC is only
known by ingress node when packets need to be classified for LSPs. In
intermediate and egress node, the only way to identify the LSP tunnel in data
plane is LABEL.

Regards!
Yuan

---

From: David Charlap <[email-masked]>
Date: Mon, 17 Jun 2002 13:24:35 -0400

Bin Zhou wrote:
> 
> In the quadruple (Src, Dst, Tunnel, LSP-id) you mentioned, the Src
> can be provided either by Extended Tunnel ID field or Tunnel Sender
> Address field.

No.  Only the tunnel sender address.

The extended tunnel ID does not have to be a valid IP address.  If you
assume it is, your code will not be compliant with the standard.

> Can I use one of the two fields as a FEC for a host address since
> there isn't a FEC element in RSVP-TE?

The entire concept of a FEC is alien to RSVP-TE.  I strongly recommend
that you do not try to shoehorn LDP concepts into RSVP.  It will only
lead to confusion and buggy code.

-- David

---

From: "Bin Zhou" <[email-masked]>
Date: Mon, 17 Jun 2002 13:47:16 -0400

Hi,

But I really need to provide a host address in the PATH message.
How to avoid using the extended tunnel ID?
Otherwise, I want to define a new field, named Tunnel Client Address in the
Session object.

Regards,
Bin

---

From: "Bin Zhou" <[email-masked]>
Date: Mon, 17 Jun 2002 14:02:55 -0400

Hi, Yuan

You ask a good question.
I think Tunnel ID is local in the daemon of the sender. We can use Tunnel ID
and Sender address to distinguish a tunnel. If I need to identify
application in my case, I need host address. The host address should be
informed to destination and intermediate node in my case. So what should I
do?

BTW, I like the maillist very much :)

Bin

---

From: Yuan Gu <[email-masked]>
Date: Mon, 17 Jun 2002 11:21:47 -0700

Bin:

But there is only one RSVP application in each node. Puting your host address
into "extended tunnel id" is allowed(but not mandatory! Other boxes receive it
may only consider it as an identifier of a tunnel rather than a host address.).

I can't figure out what's your exact problem from a few words above. But I feel
it's rather an implementation issue than protocol itself.

Regards!
Yuan

---

From: David Charlap <[email-masked]>
Date: Mon, 17 Jun 2002 16:10:27 -0400

Bin Zhou wrote:
> 
> You ask a good question.
> I think Tunnel ID is local in the daemon of the sender. We can use
> Tunnel ID and Sender address to distinguish a tunnel. If I need to
> identify application in my case, I need host address. The host
> address should be informed to destination and intermediate node in
> my case. So what should I do?

Tunnel ID is not a globally unique identifier in RSVP.  It is not the
same as the tunnel ID that LDP defines.

In RSVP, a _session_ must be defined by the triple {egress-address,
tunnel-id, extended-tunnel-id}.  A session is a _set_ of LSPs that all
share the same session information.  A single LSP is defined by the
combination of its session information and the double {sender-address,
LSP ID}.

If you treat {sender-address, tunnel-id} as a unique identifier (as it
is defined in LDP), then your code will break.

It is perfectly legal in RSVP-TE for one ingress router to use the same
tunnel ID for a thousand different sessions, if they all have different
egress addresses.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 17 Jun 2002 16:18:23 -0400

> Otherwise, I want to define a new field, named Tunnel Client

Your sender address is part of the SENDER_TEMPLATE object.  That's where
you should get it from.  That field has to be a valid IP address, and
should be an address that corresponds to the ingress router.

In a Resv message, this same address will be part of the FILTER_SPEC
object.

You can use a zero for extended tunnel ID, if you like, but you run the
very real risk of sharing your reservations with a completely unrelated
LSP if you do this.

It's really not a big deal to copy your sender address into the extended
tunnel ID as well.

What, exactly is the problem you're having?

If you believe that the sender address in the SENDER_TEMPLATE changes as
the Path message is propagated, you are wrong.  (If you don't believe
this, I apologize for jumping to conclusions, but I have seen people
with this mistaken impression.)  The SENDER_TEMPLATE is an invariant,
just like the SESSION object is.  The sender address contained within it
will always be the address that was assigned to it by the ingress node.

-- David

---

From: "Oleg Allenov" <[email-masked]>
Date: Tue, 18 Jun 2002 17:01:44 +0400

in draft-ietf-mpls-generalized-signaling-08.txt
section 3.1.1 when defining  LSP Encoding Type
why do we differentiate between 1 - Packet and 2 - Ethernet?
Does not generic packet label request covers ethernet and all the other
packet technologies?

Cheers,
oleg