Subject: LSP hierarchies using RSVP

From: "Abes, Andi" <[email-masked]>
Date: Tue, 18 Jan 2000 18:08:14 -0500

Ok,
I've been trying to figure out how to use / setup Label hierarchies using
RSVP,
and in a joint effort (with Rohit), reached the following 2 possibilities,
each having its merits.

My problem though is that both these approaches are not documented in the
drafts in a straight to 
the point way.

I'd be happy to hear opinions.

Opaque tunnels

In this mode, an pre-existing LSP (that might have been signaled using
RSVP), is used to transparently connect 2 RSVP speakers. The routers that
construct the tunnel (the "core" routers) are unaware of any higher level
labels exchanged across it.
This has the following properties:
The state the needs to be maintained in the "core" routers does not include
the "edge" reservations. 
Only the ingress of the tunnel is responsible to perform admission control
through for the tunnel.

A network topology as depicted below, will not allow router "w" to create a
reservation towards "y" that utilizes the tunnel (marked with "="), since
router "B" can not perform admission control to the tunnel.

   +--+     +--+     +--+    +--+    +--+
   |x |-----|A |=====|B |====|C |----|y |
   +--+     +--+     +--+    +--+    +--+
                      |
                      |
                      |
                     +--+
                     |w |
                     +--+
This scenario will work as follows (assuming the tunnel is pre-established):
Router "x" will issue a path message, that includes a label request.
Route  "A" will intercept this message, and send it towards router "y" on
the existing LSP. The message is sent with no "router-alert" of any kind,
and thus router "B" will not be aware of it's existence.
Router "C" receives this message and intercepts it (since it intercepts all
IP packets with protocol == RSVP). It then records the state, and forwards
the request towards "y".
"y" allocates a label, and sends a RESV message to "C"
"C" realizes that the RESV message will be sent on an LSP, and thus
allocates a 2 level label stack. The top label is the LSP label, the higher
label indicates "y". The message is sent to "A"
Router "B" is not aware of the RESV message be forward through him.
"A" receives the RESV message, and reserves the resources. The RESV messages
passed to "x" will only include 1 label.

 "Admission controlled" tunnels

This type of a tunnel allows for correct operation in the scenario described
above. 
Each router along the "core" network performs admission control, and thus
any of them
can merge additional paths onto the tunnel.

The way it works:
"x" sends a Path with a label request towards "y"
"A" intercepts it. It adds on a "router-alert" label as the top label.
"B" intercepts it, since it is flagged with the router alert. It associates
the request with the reservation currently in place for the tunnel by
examining the lower level label. It forwards the Path downstream, after
updating the current Path state for the tunnel.
"C" performs the same type of processing the "B" performed and then forwards
the request to "y".
"y" performs its own admission control and issues back a label.
"C" assigns a 2 level label stack. The top label is the existing LSP's
label. The higher label identifies "y".
As the RESV message traverses the tunnel, each router will receive it, since
it's destined to him. The message is updated with the top label used by that
router for the existing LSP.
"A" realizes his the egress of the tunnel, and only passes 1 label to "x".

pros:
This method allows a "egress targeted" tree to be built and maintained,
while consuming only needed resources.
Additional senders can join in the middle of the tunnel and cause an
increase in reservation only 
in those parts of it where it's needed
Cons:
This scheme requires the "core" routers to maintain state for every "outer"
tunnel that traverses them

---

From: "Abes, Andi" <[email-masked]>
Date: Mon, 24 Jan 2000 16:05:27 -0500

Hi,

As the authors of the RSVP extensions draft, 
I would appreciate your comments on this mail, 
which was sent to the mailing list, but generated  
no responses.

Do you agree with the statements made ?
Do these assumptions fall with-in the use you intended
for the extensions ?

Do you think that incorporating some of this in the
draft might make life easier on somebody that is attempting
to use RSVP as a way to setup tunnels ??

If I'm completely off tack, please let me know.

TIA for any comments,
Andi.

-----Original Message-----
From: Abes, Andi [mailto:[email-masked]] 
Sent: Tuesday, January 18, 2000 6:08 PM
To: MPLS mailing list
Subject: LSP hierarchies using RSVP

Ok,

Opaque tunnels

   +--+     +--+     +--+    +--+    +--+

The way it works:

pros: