Today two users having direct access to a QoS capable network (e.g. ATM) won't be able to set QoS parameters, if the TCP/IP suite is used for data transfer. Because of the abstraction of all lower layers by IP, only a best-effort service could be provided. Even if the communication is realized seamless via ATM. But the utilization of other protocols makes sense in special cases only, if it is possible to ignore compatibility to the world wide established protocols of the TCP/IP suite.
Goal
The aim of the Project is the realization of transport services, which choose the best fitting protocols by their own. The services provide a typical TCP/IP interface for the application, so that standard application may benefit from the services without modification. A extended interfaces is provided to new multimedia applications, which enables the definition of QoS parameters. This way the BIP services provide a high efficient network access, dependent to the application requirements and the available network infrastructure:
If ATM is available end to end:
New multimedia applications could use QoS functionality and additional protocol modules could be used on demand (retransmission, connection management, flow control, ...)
TCP/IP based standard application will communicate more efficiently without TCP/IP. If needed a third party could be used to configure QoS for these applications also.
If ATM is not available end to end:
A best-effort service will be provided to new multimedia applications.
Standard applications will still use the TCP/IP stack.
Figure 1: BIP protocol stack
Both new multimedia applications and standard applications will benefit from ATM or could use TCP/IP alternatively. No modification of the applications is required for this.
The BIP services have two main components (Figure 1). The BIP Library provides an interface, which is syntactically and semantically compatible to the systems standard network interface (e.g. Winsock or BSD Sockets). Further the BIP Library determines if ATM is available end to end and therefore decides which protocol stack will be used. The component generic protocols provides protocol modules, which will be used on demand only. Since this modules must be present at the endsystems only they could be extended and replaced like "plug-ins".