Subject: Hierarchical Tunnel Establishment in RSVP-TE

From: Tony Li <[email-masked]>
Date: Fri, 9 Jun 2000 22:24:48 -0700 (PDT)

| How does one establish hierarchical tunnels using RSVP-TE?
 |  
 | I know that the label object can be deeper than one label, but you need more
 | than this to establish hierarchical tunnels.

A hierarchical tunnel requires the participation of at least two LSRs.  The
operation of the LSR creating the innermost tunnel is straightforward and
is unchanged from what has been endlessly discussed here.

For an LSR to create an outer tunnel, it simply creates another tunnel and
specifies MPLS as the L3PID.  It then forwards packets received on the
inner tunnel by pushing a label for the outer tunnel.  The RSVP control
traffic for the inner tunnel is also forwarded through the outer tunnel
after first being encapsulated with a null IP label.

Recurse, ad nauseum.

Simple, really.  ;-)

Tony

---

From: Bora Akyol <[email-masked]>
Date: Fri, 09 Jun 2000 22:51:31 -0700

Tony

Thank you for the explanation. I have a few more questions.

1. Do the RSVP messages for the second (hierarchical) tunnel get forwarded via the
previously established LSP or go hop by hop?

2. What happens to the bandwidth reserved for the original tunnel when a
hierarchical tunnel rides over it?

3. In the following example:

A-->B               E-->F
          \              /
           C---->D

Let there be an initial tunnel established between B & E with the ILMs from B to E
as follows

B--C: 23
C--D: 34
D--E: 45

Let us also assume that we want to establish a second tunnel from A to F.

When a PATH message goes from A to F, how does B, C, D, E know that this is a
hierarchical tunnel vs a regular tunnel (related to question 1 above).

What exactly are the steps that are performed?

I am asking these questions to make sure that I have the right understanding of
this use of RSVP-TE, and I appreciate your answer.

Regards

Bora

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 09 Jun 2000 23:28:29 -0700

Bora,

Let me try to reply with what I think will happen .. I am sure Tony will
correct me if needed :).

> previously established LSP or go hop by hop?

I think there are two cases: 

A. If in your diagram B-E is within one administrative domain you don't want
your customers to establish TE in your core (A-F) therefor the A-F RSVP Path
should travel inside the B-E tunnel.

B. If in your diagram all routers are inside the same administrative domain B
should process RSVP Path messages as usual and forward in further according to
ERO they carry.

So I think the answer is - it depends on implementation - but I think in
practice both options could be usefull.
 
> hierarchical tunnel rides over it?

In short: The allocated bandwith for the outer tunnel is the one which is used.

Notice that a classical example of hierarchical tunnel is a simple fast reroute
feature. 1..N "inner" LSPs go via the backup tunnel by just adding one more
label on the top of the current stack. During the reroute procedure (under link
or node failure) the only bandwith used on the backup path is the one
allocated/reserved by the backup tunnel. The inner tunnel's reservation should
not matter.

> What exactly are the steps that are performed?

See question (a).
 
R.

---

From: "madhukar khare" <[email-masked]>
Date: Sat, 10 Jun 2000 11:09:47 -0400

How does this relate to OSPF areas and BGP, how would the routing protocols
be deployed in such a case?
or is there no specific relationship?

-madhukar

------------------------------------

Madhukar Khare
Digital Technology
Bedford MA 01730

[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 10 Jun 2000 08:28:22 -0700

Madhukar,

It doesn't relate to BGP at all (at least I don't know of any implementation
using BGP for TE - I think I saw one draft on it somewhere).

Multiarea LSPs is an interested topic on it's own and really should be
discussed separately. Although somehow related to this thread could be using
outer LSP in the core for interarea LSPs. In that case there could be two
scenarios:

1. We are not avertising the outer LSP tunnel as link:

All issues reg multi-area LSP need to be considered. Depending on the selected
scheme this may or may not require changes/extensions to the IGPs. 

It is up to the ABR's implementation to handle the incoming RSVP Path from one
area/level. 

A. It could forward it inside the preestablished core LSP,
B. It could run spf and build the ERO for it's own core,
C. It could glue the LSPs using a LDP label,
D. It could even drop the RSVP Path :) if non of the above is implemented.

2. We have implemented LSP advertisemnt as a link
(draft-kompella-mpls-optical-00.txt):

That obviously requires extensions to IGPs. At least I think of a few scenarios
where the idea presented in this draft could be used for regular TE (nothing to
do with 
optical networks). I think presenting them here is bit too early.

R.

> madhukar khare wrote:

---

From: Rahul Aggarwal <[email-masked]>
Date: Sat, 10 Jun 2000 21:41:48 -0700

Hi,
This pertains to the current thread as well as to: 
draft-kompella-mpls-optical.txt

A forwarding adjacency LSP (FA-LSP) is advertised into the
IGP. However from what I have seen 
there is no way to include a FA-LSP in an ERO.
Thus in the case being discussed if the LSP fron B to E 
is advertised as FA-LSP1 the ERO for the LSP
from A to F (LSP2) could include FA-LSP1. So the ERO could look
like: A->B->FA-LSP1->F. 

I guess it is possible to achieve the above by including
the path learned from the path sub-tlv for FA-LSP1 in 
the ERO for LSP2. Its also possible to specify a loose route
from B to E. However it seems like adding a ERO sub-object
to RSVP for including a FA-LSP may be more efficient
in some cases. 

Will appreciate any comments on this.

thanks,
rahul

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 12 Jun 2000 10:57:15 -0400

> after first being encapsulated with a null IP label.

Tony,

Two minor points.  

If the outer tunnel is constrained (by configuration) to accept only
inner tunnels with one L3PID, then that L3PID can be placed on the
outer tunnel.  If there are optimization possible for a particular
L3PID (IP src/dst hash to split loading along the way comes to mind
for IPv4) then putting the inner L3PID on the outer tunnel has
advantages.

No where have I seen a requirement to put a null label on traffic
destined to the egress LSR.  I had been assuming that if the IP packet
under the top label has the address of the router ID of the egress
under the outer label, then the packet would be delivered to the
egress.  If the egress required PHP, then the penultimate LSR would
put a null label on the control traffic for the the inner label and
the egress would POP the null label and see its own IP address.
Otherwise, the egress would see two null labels.

If I'm missing something and/or there will be any interoperability
problem with the way I intended to encapsulate control traffic inside
the outer label, please tell us about it.

Curtis

---

From: Bora Akyol <[email-masked]>
Date: Mon, 12 Jun 2000 08:09:15 -0700

Moreover, is this material discussed in RSVP-TE, if not why not?
A discussion of hierarchical tunnels in that draft or an accompanying draft would
have been nice.

Bora

---

From: Tony Li <[email-masked]>
Date: Mon, 12 Jun 2000 10:21:51 -0700 (PDT)

Curtis,

 | If the outer tunnel is constrained (by configuration) to accept only
 | inner tunnels with one L3PID, then that L3PID can be placed on the
 | outer tunnel.  If there are optimization possible for a particular
 | L3PID (IP src/dst hash to split loading along the way comes to mind
 | for IPv4) then putting the inner L3PID on the outer tunnel has
 | advantages.

I agree that this is also possible for implementations that want to parse
up the label stack.

 | No where have I seen a requirement to put a null label on traffic
 | destined to the egress LSR.

The requirement exists if you take the more general approach of specifying
an outer L3PID of MPLS and then wish to tunnel (otherwise unlabeled) RSVP.
Under the approach that you've proposed, this would not be necessary.

Tony