Subject: Modification of Tspec

From: Graham Cope <[email-masked]>
Date: Tue, 23 Nov 1999 17:14:49 +0000

I have a couple of related questions about the behaviour of RSVP when a
Tspec is modified. I hope that somebody could clarify for me.

Suppose that a sender issues a new Tspec requesting more bandwidth
(larger r or p). What happens if a router cannot accept the change?
(e.g. for GS, not enough R or S).
  As a result this will reject the new RESV. But, suppose that it can
still accommodate the original amount of bandwidth. Would:
a/ The whole reservation be lost (clearly undesirable behaviour), or,
b/ Is there some way of saying 'you can have what you had before (or
perhaps some intermediate value), but you can't have all the requested
amount'?

I think that there is a clue in RFC 2209, section 2,
'RESV MESSAGE ARRIVES'. It says that :

'if the UPDATE TRAFFIC CONTROL fails ....  restore the original
reservation in an old RSB', and then a RESV message would then be
returned for the old reservation.

This would then cause a loss of sync. Downstream routers have accepted
the modification, but upstream ones don't. Plus, all old PHBs'  Tspecs
have been modified. Possible ways to restore sync that I can think of
are:

a/ Tear the reservation (a bit drastic)
b/ Rejecting router to revert to the old state (but this can't be done
since the old PSB is lost)
c/ Let sender app sort it out.
d/ Don't worry about it, and continue out of sync until the next refresh
comes along - which, incidentally, won't necessarily restore sync.

All comments appreciated,

Graham

---

From: David Charlap <[email-masked]>
Date: Tue, 23 Nov 1999 15:35:06 -0500

Graham Cope wrote:
> 
> I have a couple of related questions about the behaviour of RSVP when
> a Tspec is modified. I hope that somebody could clarify for me.
> 

A sender sending a new TSpec isn't the problem.  If the network can't
handle the requset in the TSpec (which is always possible), the Adspec
that arrives at the receivers will reflect this.

The receiver, when sending out a new Resv should take the values of the
Adspec into consideration and not just blindly request whatever's in the
TSpec.

Still, conditions could change between the Path arriving and the Resv
propagating back to the sender.

> perhaps some intermediate value), but you can't have all the requested

A Resv change that isn't accepted by the network should not cause the
path to be lost.

> returned for the old reservation.

Correct.

>    since the old PSB is lost)

You mean the old RSB, right?  The Path didn't go anywhere.

> c/ Let sender app sort it out.

The sender app doesn't know what's going on here.  The sender issued a
Path message.  The receiver sent the Resv.  The Resv doesn't ever make
it back to the sender if the Resv is rejected by a transit router.

It's up to the receiver app to sort it out, if either endpoint is going
to take action.

> d/ Don't worry about it, and continue out of sync until the next
>    refresh comes along - which, incidentally, won't necessarily
>    restore sync.

If I read RFC 2209 correctly, I think the router (where UPDATE TRAFFIC
CONTROL failed) also sends a ResvErr message to the NHOP.  This should
create a blockade state in the NHOP and propagate the ResvErr back to
the receiver.  Presumably, the receiver can fall back to a prior
reservation and issue another Resv for fewer resources (possibly the
previous reservation), which (hopefully) should be accepted by the
network.

-- David