Subject: reservations

From: "tom worster" <[email-masked]>
Date: Fri, 5 Nov 1999 21:07:23 -0500

this new draft has been submitted:

http://jadn.com/~fsb/draft-worster-gsmp-reservation-00.txt
http://jadn.com/~fsb/draft-worster-gsmp-reservation-00.pdf
http://jadn.com/~fsb/draft-worster-gsmp-reservation-00.doc

c u
tom

---

From: Joachim Buerkle <[email-masked]>
Date: Mon, 08 Nov 1999 12:10:04 +0100

Sorry Tom,

can you please send this draft to the list, because this links are "not
found"!
jadn.com is a nice domain but the "~fsb" con not be found.

Do you will present this draft during this weeks meetings?

Thanks
Joachim

- - - - - - - - - - - - - - - - - - - - - -

---

From: Joachim Buerkle <[email-masked]>
Date: Mon, 08 Nov 1999 14:38:18 +0100

Tom,
I found at on Avris homepage (Thanks Avri!).

I just read your draft now.
The idea is the same as I had with my draft
<draft-buerkle-gsmp-usage-flags-00.txt>.
You proposing the to add a new message in the format of  the "add branch
message" and I  proposing to extend the "add branch message".
As I already said in our discussion with Avri I basically don't care
which way the GSMP  WG decides to go, I just want to have a solution for
the problem "reservation and to step connection establishment". So I
expect a discussion and decision about this tomorrow.

I see also the following open issue you pointed out in your draft:
 "A related problem is how to perform parameter negotiation in the
  case that admission control (CAC) is the responsibility of the
  switch. Under some conditions both ATM and MPLS allow a network
  node to change the values of certain parameter values if the
  requested values cannot be supported. But if CAC is performed by
  the switch then the controller has no way to know what traffic
  parameters the switch could support. If we give the switch the
  option of changing the traffic parameter values in a Reservation
  Request and returning parameters that can be supported then the
  switch needs to select which parameter or parameters to adjust.
  This is difficult because the network layer protocols constrain
  which parameters may and may not be adjusted. Potentially the
  controller could find appropriate parameters by iterative
  algorithm using several Reservation Requests. This approach could
  be excessively costly in time and computation. This question
  remains an open issue."

I don’t know whether there is somebody who wants to allow a time costly
algorithm. So I expect that in the case where the switch can not support
the traffic parameters because of the current traffic condition this
will probably result in a "reject" of the connection establishment.
In the case where the switch can not support the traffic parameters
because of his
implementation we probably can find a way that the switch tells the
controller his
capabilities up front during a synchronization phase.

In the case where somebody don’t want to implement a whole traffic class
like "abr". We
probably can leave it in the responsibility of the switch that he (or
CAC) is than using
another traffic class without telling the controller (Even if this needs
more resources).
Yesterday I talked to a guy who has also this problem, because in his
case the CAC is
also in the responsibility of the switch. He said he don't want to use
this time costly
algorithm. He wanted to have a possibility to map not supported traffic
classes to other traffic classes up front. Unfortunately I don't have
his business card, but I hope I speaks up here by his self.

c.u.
Joachim

- - - - - - - - - - - - - - - - - - - - - - - - - - -