The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

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