The Routing Over Large Clouds Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199510260835.KAA02432@lohi.dat.tele.fi>, Juha Heinanen writes:
>    After all, RSVP is a protocol to reserve
>    resources on routers. In the scenario I described there are no routers
>    involved (as there is a direct SVC). The decision to establish such SVC
>    is controlled by the application (through an API). RSVP is *NOT* a
>    QoS-capable host API.
> 
> i'm lost.  based on what curtis has written, i have got the very
> impression that int-serv/rsvp also includes a qos aware host api.  what
> sense would it make to start desiging a protocol to reserve resource on
> routers, if we don't even know that kind of resources would need to be
> reserved?  there must first be the api and based on that people can
> start designing the necessary reservation protocols for routers and
> direct mappings for routerless subnetworks, such as atm.
> 
> -- juha

I think the two have to proceed, if not in parallel, at least keeping
the full set of requirements in mind (ie: don't build rsvp/int-serv
into a dead end and consider the needs of passing parameters on to the
next hop when designing the API).  There should be one API that is
independent of whether QoS is provided hop-by-hop or by direct
connection.

Curtis