Subject: tunnel bandwidth change and RSVP-TE

From: Markus Jork <[email-masked]>
Date: Wed, 5 Apr 2000 19:45:59 -0400

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 is a new concept introduced by
RSVP-TE and so I'm wondering what exactly the semantics of
that PathErr message are.
A PathErr message has always implied that a Path message
cannot reach the destination and thus the ingress has to assume
that the tunnel lsp went down. Or was the intention to handle
an admission control error in a PathErr message like a ResvErr
including the "InPlace" flag?
In the first case (PathErr indicates the path could not be established),
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.

Markus

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Apr 2000 20:08:13 -0400

At 07:45 PM 4/5/00 -0400, Markus Jork wrote:
>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

I believe this is introduced by some implementations, not by RSVP-TE.

>including the "InPlace" flag?

While such a modification to RSVP is possible, I don't believe it's covered 
in the current documents.  Some thing along these lines may result from 
some of the proposed optical related extension, but it's still a bit too 
early to tell.

Lou

---

From: George Swallow <[email-masked]>
Date: Thu, 06 Apr 2000 14:44:33 -0400

Markus -

> and not on the Resv message coming back upstream.

I always intended that BW changes be handled exactly this way.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Apr 2000 17:17:39 -0400

> I always intended that BW changes be handled exactly this way.

George,

Does that mean that:

  1.  Once a set of parameters are set in a PATH message, all PATH
      messages MUST have the same set of parameters.

or

  2.  Once a set of parameters are set in a PATH message, all PATH
      messages SHOULD have the same set of parameters.  If not, there
      is a risk of admission control rejecting the request.  For some
      cases such as reduction in bandwidth, the risk of being rejected
      by admission control is nil (excluding the possibility of bugs)
      or small.

If you mean 2 (path messages SHOULD use the same parameters), then
there is a requirement for midpoint nodes to try to accommodate the
change.  If so, can any parameter change, such as holding and
reserving priority.

If you mean 1 (path messages MUST use the same parameters), then
midpoint implementations can be simplified somewhat.

We would appreciate it if you would clarify this by telling us if you
meant MUST or SHOULD in the above context, and update the draft to
make the clarification explicit.

Thanks,

Curtis

---

From: George Swallow <[email-masked]>
Date: Thu, 06 Apr 2000 17:51:56 -0400

Curtis -

I meant SHOULD.  Or more precisely it is RECOMMENDED for the TE
Application's use of RSVP.  A MUST would be a significant change to
RSVP and I didn't think that would fly.

...George