Subject: RE: tunnel bandwidth change and RSVP-TE

From: Markus Jork <[email-masked]>
Date: Wed, 5 Apr 2000 20:33:00 -0400

On Wednesday, April 05, 2000 8:08 PM, Lou Berger  wrote:
> At 07:45 PM 4/5/00 -0400, Markus Jork wrote:
> >The problem is as follows: I want to increase the bandwidth
> >of an already established tunnel without the danger of
> >deleting the tunnel when this change attempt fails.
> >(The same problem exists for any other parameter subject
> >to admission control such as the holding priority.)
> >
> >In traditional RSVP, the receiver would make the decision
> >of increasing the flowspec for a session. If that attempt
> >fails at any node, the old flowspec would stay in place and
> >a ResvErr message would be sent back to the receiver.
> >There is an "InPlace" flag in the error object that indicates
> >this situation.
> >
> >Things are different with RSVP-TE. Here, the sender (i.e. tunnel
> >ingress) should be in charge of modifying the bandwidth
> >of a tunnel. If the attempt to increase the bandwidth fails at any
> >node, an "Admission Control Failure" PathErr message has to be
> >sent back to the ingress.
> 
> This presumes allocation on path.  While this can be done, the semantics of 
> RSVP really don't properly handle this case. (as you point out.)  The 
> normal way this would work, even with RSVP-TE is for the updated tspec to 
> be passed to the receiver (the egress) and for the egress to then request 
> an increase.  this will lead to normal RSVP processing.
>
> >This is a new concept introduced by
> >RSVP-TE and so I'm wondering what exactly the semantics of
> >that PathErr message are.
> 
> I believe this is introduced by some implementations, not by RSVP-TE.

Section 4.7 of the draft says:
"If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and an
Error Value of 0x0002."

Markus

---

From: Markus Jork <[email-masked]>
Date: Thu, 6 Apr 2000 16:32:20 -0400

On Thursday, April 06, 2000 2:45 PM, George Swallow  wrote:
> Markus -
> 
> > one can use the make-before-break approach for increasing
> > the tunnel bandwidth. This will work fine as long as admission
> > control is done on the Path message travelling downstream
> > and not on the Resv message coming back upstream.
> 
> I always intended that BW changes be handled exactly this way.
> 
> ...George

Ok, works for us. But I guess it would be good to clarify this in
the spec.

thanks,
Markus

---

From: Fong Liaw <[email-masked]>
Date: Thu, 6 Apr 2000 16:20:39 -0700

Markus

I might be stretching my knowledge about RSVP
and RSVP-TE. But I believe the old reservation
using a different sender id will not be deleted 
even if the new one failed. I believe RESV
message carries the "largest" reservations by
all listed senders. When reservation of one sender 
timed out, the reservation will be recalculated on
next refresh cycle or error message which would
result in the old reservation.

This is exactly the "make before break" behavior
you wanted. There might be issue on efficiency
of the control messages, but I believe that is
not what you are asking.

-Fong

-----Original Message-----
From: Markus Jork [mailto:[email-masked]]
Sent: Thursday, April 06, 2000 1:32 PM
To: 'George Swallow'
Cc: [email-masked]'
Subject: RE: tunnel bandwidth change and RSVP-TE 

thanks,
Markus