Re: Last Call for draft-ietf-rolc-apr-00.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> > 
> > Your conclusion 2) is predicated on their being an ommission in the
> > int-serv work.  If so, fix the ommission for the general case, rather
> > than stating that the only way to do this is to essentially ignore the
> > work of RSVP and int-serv and limit yourself to directly connecting
> > the end system to the NBMA.
> 
> We don't need to ignore the work on RSVP and int-serv, but we also need
> to remember that if a pair of hosts on a common NBMA would like to
> establish a direct SVC (because of QoS and/or traffic characteristics),
> then RSVP has to do with this. 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.
> 
> Yakov.


Just like the application today should not need to know whether the
destination is on the same subnet and do things differently, the
application should only need to know it's requirements.  In passing
the requirements through the API to make the reservation, the
operating system can recognize that a direct connection is possible
and make the decision as to whether one should be set up based on the
characterisitics and the needs of the application.

The application passes information through an API.  The information
characterizes the expected traffic and requirements of the
application.  The first cut-through decision occurs on the immediate
host.  If cut-through is not chosen then the traffic and a periodic
reservation request is forwarded to the next hop.  If the first hop
was an uncongested ethernet, the next hop router may make a
cut-through decision and decide to create an SVC or provide other
special treatment for this traffic.

The application should not need to know how the network service is
being provided.

Curtis