Subject: Re: LSP utilization

From: Raymond Law <[email-masked]>
Date: Sun, 29 Jul 2001 22:48:36 -0400

I agree the problem that I posed may not be MPLS specific; it applies to 
ATM circuits as well.  I think this may be more of a TE problem than a MPLS 
problem.

Basically I heard two solutions from the list.  The first solution is to 
assign a new LSP with the adjusted (measured from the first initial LSP) 
bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and 
the delay to do so) involved in this solution worth what it provides 
(better LSP utilization)?

The second solution is to do load balancing when setting up LSPs.  I agree 
that load balancing can definitely lead to better utilization of the 
LSPs.  However, I am more interested in the situation where, after load 
balancing and setting up LSPs for the FECs, the amount of traffic sent 
through the LSPs change, resulting in over- and under-utilization of some LSPs.

Ray,

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 30 Jul 2001 08:26:45 -0700

Raymond,

> (better LSP utilization)?

The order is not exactly as you wrote. The old LSP is not being
destroyed first, but rather a new LSP is being attempted to be created
using shared explicit rsvp reservation style. If the new reservation
fails the old tunnel continue to be active if it succeed we build a new
tunnel (no double bandwith reservation) we switch traffic to a new
tunnel. After this old is no longer refreshed. 

It is automatic with ability to adjust the interface stats collection
timers as well as the resize interval. 

R.

> Raymond Law wrote:

---

From: Raymond Law <[email-masked]>
Date: Tue, 31 Jul 2001 01:37:49 -0400

Robert:

If I understand correctly, the new LSP is reserved with the same ingress 
and egress LSR but with different amount of reserved resources such that 
both LSPs combine to match the new bw requirement of the traffic flows.

I can see how the above works if the old LSP needs more bw, then it just 
sets up a new LSP with some more bw to accommodate the traffic (no double 
bw).  What if the old LSP is actually allocated more than enough bw and you 
want to take away some bw from it to give it to other LSPs?  How would you 
set up the new LSP with less bw than the old one?

Is the new LSP set up like a regular LSP or is it set up using the existing 
knowledge of the old LSP so as to lower the overhead associated with 
setting up a whole new LSP.

Can you point me to some more info on this please?

Thanks.
Ray,

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2001 05:36:34 -0700

Raymond,

> both LSPs combine to match the new bw requirement of the traffic flows.

No. The new LSP's BW = (old bw +/- delta bw). (Note delta can be
negative :). So when the new LSP is build we as I already indicated stop
refreshing the old one. 

Also notice that at any time there is no double reservation of resourcse
(shared explicit rsvp reservation style is used).

R.

PS. I will send you offline some vendor specific doc ;).

---

From: David Charlap <[email-masked]>
Date: Tue, 31 Jul 2001 10:25:11 -0400

Raymond Law wrote:
> 
> If I understand correctly, the new LSP is reserved with the same
> ingress and egress LSR but with different amount of reserved
> resources such that both LSPs combine to match the new bw
> requirement of the traffic flows.

That's not the way SE-style reservations work.

With SE style reservation, all senders (ie all LSPs) in a single session
always have identical resource reservations.  When the egress sends out
a Resv for the second LSP with different resources, the routers will
change the reservation for the first LSP as well.  If the two LSPs have
divergent paths, Resv messages will be sent along both paths, in order
to keep the two LSPs in sync.

> I can see how the above works if the old LSP needs more bw, then
> it just sets up a new LSP with some more bw to accommodate the
> traffic (no double bw).  What if the old LSP is actually allocated
> more than enough bw and you want to take away some bw from it to
> give it to other LSPs?  How would you set up the new LSP with less
> bw than the old one?

Same as before.  Use make-before-break.  Create a new LSP in the same
session.  The egress sends back an SE-style Resv message for both LSPs
with the new amount of resources.  All the transit routers update their
reservations.  When the Resv hits the ingress, it can shunt traffic onto
the new LSP, and signal a teardown for the old one.

> Is the new LSP set up like a regular LSP or is it set up using the
> existing knowledge of the old LSP so as to lower the overhead
> associated with setting up a whole new LSP.

There is no real difference here.  If the new and old ones have features
in common, the ingress can choose to reuse what it knows.  Or it can
choose not to.  This is an implementation issue.  Either way, the Path
message leaving the router will be the same.

-- David