People from IBM T. J. Watson Research Center have developed an RSVP-based control architecture. Their implementation is described in a paper [#!IBM-implementation!#] published in April 1998.
They worked on IBM AIX operating system. A new kernel module was designed: the QoS manager is responsible for ``creating and maintaining reservation states of QoS connections, allocating and managing network buffers for these connections and policing and shaping of network bound traffic.'' The socket API was extended in order to provide an interface to the QoS manager.
This provides an IP over RSVP implementation. The control architecture that I implemented deals directly with ATM, thanks to Ariel. IBM implementation is independent from the link layer protocol used. Tests have been made using ATM and IEEE 802.5 Token Ring.
Therefore, a server running AIX on an ATM network will perform ATM signalling using UNI4.5 3.1. According to their results, creating and then deleting a reservation and a connection takes between 16.8ms and 30.4ms (see table ![[*]](crossref.png)
), depending on the server used. However, those results are optimistic since the time spent tearing down the ATM virtual connection is not taken into account, and since ``the most significant part of the [..] latency is contributed by the ATM signaling overhead.'' Considering the times given in section , we can guess that a real setup/teardown operation would take about 25ms. Therefore, this implementation is twice as fast as the Ariel one.
| |||||||||
However, devices cannot renegotiate resources for existing connections with UNI 3.1 (this is possible with UNI 4.0). Modifying an RSVP reservation therefore means setting up a new ATM connection with the new parameters and then tearing down the old one. This would take the same time as before, i.e. 25ms. With the Ariel control architecture, it would take the time to process the Resv message and to do an Ariel RPC, plus the time for the message to travel towards the source of the data flow, i.e. about 20ms. The Ariel implementation is in this case 20% faster than the IBM implementation.