Subject: Aggregated SENDER/SESSION in RSVP (was Re: QoSSIG BOF)

From: Martin Karsten <[email-masked]>
Date: Mon, 24 Jan 2000 17:33:01 +0100 (CET)

In response to several mails arising from my original question:

I'm basically interested in the expressiveness of such aggregated RSVP
requests in terms of contractual relationships (e.g. for charging/billing
mechanisms or policy in general). What happens on the data path is a
different story then, as long as the traffic/QoS contract is satisfied, be
it end-to-end or for a certain path.

Let me rephrase the question: Can RSVP be extended to express all potential
inter-domain and intra-domain requests for specific transmission performance
between [subnet|host] and [subnet|host]? For example, can it then be used
for bandwidth-broker to bandwidth-broker communication/setup for DiffServ
networks or is it absolutely necessary/desirable to have multiple mechanisms
in place?

To me, the open question is whether any general technical solution like RSVP
can be made robust with respect to such administrative issues. The reason is
that, in my opinion, having a single basic mechanism for per-flow and
aggregated traffic/QoS contracts would simplify the development of a single
surrounding policy/charging architecture (which might be of much greater
importance in the future than today).

Wrapping up, even if a single signalling mechanism is somewhat overly
complex for some of the problems addressed by it, there might be trade-offs
against other complexity.

Greetings,
Martin