CORBA QoS Control Stream Architecture

IEEE ELECTRO/INFORMATION TECHNOLOGY CONFERENCE 2000

CORBA QoS Control Stream Architecture Edward Babulak, Member, IEEE, Member, ACM, Abstract - In our research, we describe a common object request broker (CORBA) quality of service control stream architecture (CQSCA), controlling audio/video (A/V) Streams in CORBA-based multimedia environment with support for Open Signaling. Such multimedia (MM) applications use live capturing facilities (i.e., camera, microphone, speaker, etc.,) and communicate through transport objects based on streams. Our architecture, in contrast to the existing architectures, supports dynamic choice of QoS for the user with various applications. Index of Terms – CORBA, quality of service, QoS Contract, Trading Service, middleware.

I.

INTRODUCTION

Open system standards are important for the integration of distributed MM system support in order to achieve unified communications architecture. QoS provides a unifying theme on which the functionality and facilities of new integrated standards can be constructed. For future applications, especially those, which are highly interactive and rely on MM information, it is essential that QoS be guaranteed for the whole system. Enhanced communications protocol support such as end-to-end QoS negotiation, renegotiations, degradation and co-ordination over multiple connections is required. Design of distributed MM applications, such as system for access to remote MM databases or teleconferencing, requires careful consideration of QoS issues. Due to the networking bandwidth and processing power required by the presentation quality of live media, such as video, the QoS provision is critical. For applications running in a shared environment, the allocation and management of these resources is very important. In general, the best-effort approaches offered by most existing systems are not suitable for distributed MM, because some users may be ready to pay some higher price for obtaining maximum quality, while others may prefer low-cost presentations with lower quality. Emerging standards for distributed integrated environments, like CORBA from the Object Management Group (OMG) provide a software bus for distributed MM applications [1]. Today's mission-critical distributed systems in military, government or business applications have specific functional and performance requirements being reflected by string QoS constrains [2], [3] and [4]. MM research explores human-computer interaction by making use of text, images, graphs, animation, sound, speech and video [5] and [6]. When combined, developing distributed QoSconstrained MM applications (e.g., Audio/Video Conferencing) is a difficult task because of the strict requirements on system resources and the great diversity of MM standards and devices [7], [8] and [9].

The author is Ph.D. Candidate with the University of Ottawa. He is now with the Department of Electrical and Computer Engineering at Penn State Erie, Erie, PA 16563 USA (e-mail: [email protected]).

1

QoS is becoming increasingly important in distributed MM systems [10] and [11]. The nature of distributed MM applications is such that they require peer-to-peer communication support mechanisms [12] and [13]. MM traffic needs to be delivered to end-systems, networks and end-users in a form that they can handle, while satisfying the constraints imposed by the applications [14], [15] and [16]. QoS mechanisms are required to ensure high quality media playout at high-performance workstations, while at the same time providing appropriately filtered lower quality media playout at low-end systems, i.e. adaptive QoS [17] and [18]. Existing support mechanisms such as multicast protocols are performance deficient. They provide the service based on the least capable link or node involved in the multicast session [19], [20] and [21]. QoS is not a new concept. Traditionally, it is employed within the domain of computer networks to specify a set of parameters assigned to transport connections. As a rule, QoS is established through negotiation between service users and providers [22]. The process of negotiation is simple if the resources are managed by a centralized entity (e.g. an operating system) or by a set of homogeneous entities. Unfortunately, in distributed MM applications, the negotiation and management of resources is a difficult task since resources are very diverse, dispersed and maintained by heterogeneous entities. This paper consists of four sections. In the first section we present introduction, view on connectivity, application scenario, CORBA QoS and a proposed solution. In the second section we present the CQCSA model objectives, MM system service, stream-based communications mechanism and the use of trading service. The third section presents proposed improvements and the QoS contract. In the forth section we present conclusions. A. View on Connectivity One of the most fundamental objectives in networking is the provisioning for connectivity (i.e. establishment of communication path between two end-points). Setting up a communication channel requires a connection management system that coordinates operations among a set of distributed software modules. The connection management system has to meet two requirements: • First, it must provide high performance and be scalable in order to handle the anticipated volume of users. • Second, because of the need to be able to rapidly create and deploy new services, it must be very flexible. Current standards for connectivity services are essentially extensions of the User Network Interface (UNI) and Network/Node Interface (NNI) designed for the “plain old telephone service” (POTS) networks. Modern approaches to provisioning of network services exploit advances in distributed system technologies to provide more flexibility for service creation and deployment [23], [24] and [25]. In these approaches, signaling entities run on a general-purpose distributed computing platform and interactions are

expressed in terms of high-level operations over an infrastructure that provide open and uniform access to abstractions that model local states of the networking resources. The signaling infrastructures have to be carefully engineered so that performance of the connection management system is capable of handling a large volume of expected user requests. B. Application Scenario The best way to describe the scenario where Open Signaling and the QoS plays a crucial role would be in the domain of MM distance learning over high-speed heterogeneous networks. Let us assume that the system users are interconnected over a heterogeneous backbone network, supporting MM applications for tele-learning. The professor is giving a lecture through live video across the country to a certain number of students. The scenario will change dynamically if suddenly, some students may desire to join the new session. Need for openness is more in demand if we are sending video and audio streams [26]. In case of MM where video or audio data is being transmitted, the most important parameters are the end-to-end delays and jitters. These parameters impose strict timing constraints on the underlying communication subsystems. We may assume that participants are spread out geographically and are connected through various networks and operating on different platforms. Users may join the session via a dummy terminal located in the local lab, or through a pocket or portable PC. User network connections may be ATM or TCP/IP and yet all expecting suitable QoS. C.

CORBA QoS

To illustrate the solution for a QoS provision in a CORBAbased environment we may consider following: • Selection of real-time object request broker (ORB) capability: An object wishes to find a server that can provide a service with real-time characteristics, such as video on demand. To meet the QoS needs, not only must a suitable server be found, but also the ORBs involved in supporting the end-to-end interaction must have real-time capability [27]. The initiating object will need to express its QoS requirements. These must be taken into account in determining which servers and which infrastructures can be used to provide a service, as well as in allocating adequate resources to support the interactions between objects. • End-object adaptation to provide changes in available QoS: Video and audio transfers are needed to support complex applications such as a tele-conference, collaboration in virtual worlds, etc. As the operation proceeds, other demands on resources are made with the result that the originally negotiated bandwidth can no longer be made available to support the video stream. However, the end-objects are capable of operating in degraded modes without prejudicing the application’s operation, such as by switching from color to black-and-white or by sacrificing resolution. The endobjects and the communications infrastructure determine jointly that the reduced QoS available is capable of supporting one of these degraded modes, and the end-objects switch to operate in that mode. Subsequently, resources are freed, the end-objects and the infrastructure determine that a less degraded mode is possible and the end-objects switch to operate in that improved mode.

2

D.

Proposed Solution

Our work is motivated by the challenge of providing a dynamic adaptation of QoS parameters during the MM application set-up. In order to satisfy user’s QoS needs we may apply trading services1 to allocate resources necessary [28]. The trading service would provide resources necessary for optimum QoS connection2. The customers subscribe through their account for specific QoS parameters. According to the account privileges, the client will be allocated device and network resources through the CQSCA QoS management mechanisms. There are two levels of QoS negotiations: • At the transport level studied by Columbia (xbind) [29], [30] and [31]. • At the application level, which constitutes a subject of our research. II.

CQSA MODEL OBJECTIVES

The basic objective of our work is to build a “QoSenhanced” system, in which users can specify, requirements provided by the system [32]. Some systems will support dynamics of user QoS requirements while others will not. Levels of confidence or guarantees offered may vary each system. Meeting the user QoS requirements will be a direct result of end systems, communications networks and all other systems that end-to-end user traffic or interactions may pass through. Therefore user requirements will have to be translated (“mapped”) into requirements on processing and technology. This includes operating systems (OS), ORBs, applications, protocols, routing, etc [33] and [34]. Deployment of CORBA being used as a software bus, providing resource allocation and control of QoS for MM applications is shown in Figure 1. User's QoS requirement for rapid access to information may be satisfied by means that involve a negotiation process between all system elements. From the user's perspective, that process is part of QoS, but in the corresponding solution it may be implemented as a system function that must itself be performed with a particular QoS, such as a bound on the time allowed to complete the negotiation. For example: • A user's delay requirement may translates into throughput and storage requirements in the engineering solution, or • A user requirement for reliability and coherence may translates into engineering requirements to use transaction-processing techniques [35]. The QoS assurance is given through resource allocation, monitoring, and maintenance [36] and [37]. CORBA provides abstraction only for control interfaces. Control through interfaces alone is not sufficient. For a third party vendor to expand on the system with only control interfaces, the vendor must know something of the semantics behind the other components within the system.

1

Trading service represents the process of arbitration of services. Providing we have “high bandwidth” ATM connection it makes sense to make use of high quality end-devices, such as high-end terminals, workstations, video and audio devices. In case of having a very poor connection available, the use of high quality end-device may not improve the quality of service expected.

2

Figure 1. Deployment of CORBA

A.

MM System Service (MMS)

A MSS provides a set of recommended practices to facilitate cross-platform compatibility of MM data and applications [38]. The MSS specification is being developed by the IMA (Interactive MM Association). The IMA members include the main software and hardware suppliers and consumers around the world. The MSS architecture provides an infrastructure for building interactive MM applications in distributed and heterogeneous computer systems, dealing with synchronization of QoS requirements. MSS is structured using an object-oriented approach, based on an underlying infrastructure built on top of CORBA and CORBA Services together with an independent MM Stream Protocol (MSP), which supports the streaming of timecritical data. Figure 2 illustrates the components present in the MSS architecture. The interfaces of these components are being standardized by the IMA, as is the MSP. Every client in the MSS environment establishes a data flow through two virtual devices bound by a virtual connection. These components may be running locally or remotely. • Virtual devices encapsulate the process of capture or rendering of a particular kind of media. Associated with each virtual device are a stream object and one or more format objects.

3

•

• •

•

Stream objects control the media position and the flow of data from/to the device. They can also provide an interface for controlling the synchronization between streams. Virtual connections also have associated stream objects to control the media flow. Ports encapsulate low-level transport semantics, while format objects define the pattern used to encode and decode the information flowing through the port. Virtual connections allow the flow of media data between devices. They provide an interface to connect two ports with compatible data formats. A stream object controls the flow of media through the connection. Virtual connections can also support multicast communication between devices. A group element, with which clients can also interact, is used to manage the distinct data flows present in a connection using a single stream interface. Groups provide an effective mechanism for atomic resource allocation and control of end-to-end QoS.

Figure 2. MM System Services

Clients can also register (or subscribe) to an event channel in order to receive notification of internal or external events, and can use this information in any way to control the flow of media through the associated connection. B.

Stream Based Communication Mechanism

Despite its adequacy for transmission of best-effort data, CORBA, like its counterparts, does not have support for real-time data delivery. The immediate solution for the implementation of MM applications would be the use of CORBA for transmission of control data, while the stream data would have to be transferred using a lower-level network protocol providing mechanisms for QoS specification or resource reservation. However, it is not reasonable to use high-level middleware to provide protocol and distribution transparency for best-effort data, and on the other hand exposes the programmer to the lower-level protocols used for transmission of stream data. It is highly desirable that distributed object middleware provide the same kind of high-level abstraction, which is available for best-effort data, to deal with media traffic. To make CORBA suitable for real-time data, OMG is defining streaming mechanisms to be introduced at application level in the CORBA architecture. The streaming mechanism defines a group of abstractions to deal with stream data in MM systems, as

4

illustrated by Figure 3. The abstractions are called MM devices (MM device), stream adapters, and stream control: • MM devices are software components that abstract MM hardware. • A stream adapter transfers stream data through the network, getting data from and delivering data to MM devices. The data delivery is subject to QoS constraints described during the creation of the stream, i.e. during the binding of two or more MM devices. • The stream control is a normal CORBA object accessible remotely through the client-server invocation scheme. It can be a remote object or can be located in the same address space as one of the MM devices. Modification of the QoS parameters associated with a stream (such as maximum delay and bandwidth), the control of the data flow (i.e., starting and stopping flows of data), and the addition and removal of new parties from a multi-party stream connection can be performed through the stream control object.

Figure 3. Stream-based Communication Mechanism

C.

The use of Trading Service

The growth of computer networks and transmission capacity facilitates an increased amount of services offered in distributed systems [39], [40] and [41]. One of the CORBA services is the trading service, which supports clients in searching for suitable services. To support a client in searching for a special service, a trader can be used. This trader has a service directory, which contains available services specified by service type and service property values. If a client requests a service, the trader procures a convenient one [42]. In case of a MM application, CORBA could provide access to the remote objects requested by the application [43]. The selection of objects and communication resource allocation must be optimized for the desired QoS. Trading problem in particular could be approached from three different angles: • clients searching for the suitable service, • integrating different local trader functions in order to extend service access support beyond local network boundaries, or • The service that would take into consideration the QoS aspects dynamically. Because of the growing quality needs of many communication services, a trader should be able to allow service requests with QoS aspects. Trading could be useful in underlying infrastructures. In other words, the QoS will reflect on what we want as compared to what we get and how that relates to the total resource capacity.

5

A trader is a third party object that enables clients to find information about suitable services and servers. Services provided by service providers can be advertised, or exported, in a trader. Such advertisements, known as service offers, are stored in the trader’s database. The advertising object (the service provider or object acting on behalf of the service provider) is called an exporter. Potential service users (importers) can import information on the available services and their accessibility. The trader tries to match the importer’s request against the service offers in its own database. After a successful match the importer can interact with the service provider. The relationships between trader, importer, exporter and administrator are illustrated in Figure 4. In addition to the adoption of the CORBA architecture as the core of the proposed MM framework, we propose some improvements in the current implementations and additional services to allow the framework to provide the desired functionality for distributed MM applications.

Figure 4. Trader Function

III.

PROPOSED IMPROVEMENTS

The proposed improvements and additions are following: • a CORBA stream architecture see Figure 5, with capabilities of QoS-based binding process, • a set of application-level QoS parameters for different categories of MM applications, • concept of enhanced trading service translating application QoS parameters to a network-level QoS parameters and • the provision of a MM component hierarchy to facilitate the open signaling for distributed MM applications. These additions to the core architecture, including the stream mechanism, are totally feasible at the application level. This fact assures that eventual modifications in the standard and in the support are unnecessary. Essential components illustrated in Figure 5 are following: • A stream: represents continuous media transfer, usually between two or more virtual MM devices. A stream adapter represents the endpoint of a stream. A simple stream between a microphone device and speaker device. A stream can contain multiple flows. An operation on a stream (for example, stop or start) is applied to all flows within the stream. It is also possible to manipulate individual flows through the stream controller interface. • A MM device (as opposed to a virtual MM device) abstracts one or more items of MM hardware. A MM device can

6

support more than one stream simultaneously, for example a microphone device streaming audio to two speaker devices. A stream adapter and a virtual MM device will exist for each stream connection. MM devices, virtual MM devices, streams and stream adapters are all represented by IDL interfaces: MMDevice, VDev, streamCtrl and streamAdapter respectively. A MM device can be connected or “bound” to one or more compatible MM devices using a stream. A MM device can potentially support any number of streams to other MM devices. Each stream connection will be supported by creation of a virtual device and a stream adapter (representing the device specific and network specific aspects of a stream endpoint respectively). Virtual devices will have configuration parameters associated with them. For example, a microphone device might be capable of encoding audio data using either µ-law or A-law [10]. The sampling frequency might also vary. When two virtual devices are connected using a stream they must ensure that they are both appropriately configured. For example, if the microphone device is using A-law encoding and a sampling frequency of 8-kHz then it must ensure that the speaker device it is connected to is similarly configured. It does this by calling configure() on the VDev interface for the speaker device with the appropriate parameters. This procedure occurs when a streamCtrl object binds two virtual devices together. Changes in configuration can also occur while a stream

is flowing between two virtual devices. An MMDevice supports operations to set up a stream between two or more peer MMDevices on the network. For example, to bind two MM devices using a stream the application programmer could call the following operation on the MMDevice interface: “streamCtrl bind(in MMDevice peerDevice, in streamQoS theQoS).” This operation will return a reference to the streamCtrl, which the user can then use to stop, start, or otherwise manipulate the stream.

Figure 5. Concept of QoS via Trading

•

7

A Stream Interface: the streamCtrl interface abstracts a continuous media flow between virtual devices. It supports operations to create a stream, which binds MM devices. There are also operations to start and stop a stream. If the user requires more complex functionality (for example, rewind) he/she can extend the basic stream interface to support this. When the user requests a stream between two or more MM devices he/she can explicitly specify the stream QoS.

QoS could mean different things at different levels. For example, a MM device, which supports video, will be concerned with QoS parameters like frame-rate and color depth. This type of QoS will be referred to as applicationlevel QoS. Underlying network protocols, however, will support a stream. The QoS for a network protocol may include parameters like minimum bandwidth and jitter. This type of QoS will be referred to as stream QoS. An application programmer can establish a stream between two devices by calling the operation bind_devs() on the

streamCtrl interface: “void bind_devs(in MMDevice A_party, in MMDevice B_party,in streamQoS theQoS)”. This is equivalent to calling bind() on a MMDevice interface. The argument “theQoS” will generally be an application-level QoS specification. The appropriate protocols will be chosen by the streamCtrl and a translation will occur between application level QoS and network level QoS for these protocols. If the MMDevices decide they can accept the connection, they will each create a streamAdapter and a VDev to support the stream between them. The Media Streaming Framework supports point-to-multipoint streams. These allow a single “source” device to be connected to many sink devices via a

multicast stream. For these purposes the streamCtrl interface supports operations such as: bind_A_party() which adds a source streamAdapter (for example, to a video camera); bind_B_party() which adds a sink streamAdapter (for example, to a TV) and unbind_party() which removes an A or a B party. • Stream Adapter Interface: A stream adapter represents the endpoint of a stream. A stream adapter logically contains and controls the endpoints for each of the individual flows in a stream. There are two types of stream adapters: • An “A-party” and a “B-party.” As the name suggests the former initiates a connection, the latter responds to the initiation request. The choice of which adapter is the “A party” and which is the “B party” is entirely arbitrary. A choice must be made because connection set-up must be started at one end or the other. The concept of “QoS via Trading” assumes the consumerprovider interactions necessary to establish streams of MM data. A user submits a set of QoS parameters for the conference set-up to the administrator. The QoS specifications are mapped onto an enhanced trader invoking the stream adapter and virtual devices with a specific QoS to start the conference. In orther words the trader invokes the QoS objects.

Figure 6. QoS Contract

8

A.

QoS Contract

With the adoption of the CORBA-based architecture integrating the client-server A/V streaming, the distributed MM application gains the ability to control the QoS in the uniform fashion via high-level abstractions. Besides, the object-oriented nature of CORBA provides a large set of benefits to the application development process (e.g. reusability, encapsulation, use of software engineering techniques, etc.). In our approach, we introduce the notion of QoS contract between two parties engaged in a collaborative session. The trader would register QoS Contract in ServiceOffer Factory and make it available to ServiceOffer. Trader may be used to establish a QoS Contract between party A & B as illustrated in Figure 6. A QoS parameters are set during the process of stream establishment and binding of objects. QoS specifications must be met before actual transmission of data between the stations A and B.

Stations A and B have established a QoS Contract. The basic configuration to which QoS is relevant in an object-oriented architecture is that of two end-objects A and B, which wish to interact across a supporting object infrastructure, and wish at the same time to set some performance constraints on those interactions. At the most abstract level a binding object R can represent the object infrastructure3 (see Figure 7).

A

R

B

Figure 7. Basic Contract Concept

QoS contracts for A, B, and R represent the requirements that objects A and B may have on the infrastructure, and the agreements reached between the parties to satisfy those requirements. A QoS contract is an expression containing the object's expectation of its environment and its obligation. It has the following semantics: • So long as the environment meets the object's expectation, the object will meet its obligation. While QoS contracts are a very important part of the specification of QoS, additional items of specification that may be required include: • actions required to monitor QoS, • actions required to maintain QoS, • actions to be taken if the QoS contracts cannot be sustained for example through loss of resource, or the arrival of higher-priority traffic. These actions may be taken by the infrastructure, the end-users or both, and may also involve systems management objects, • actions to alert objects that changes in achievable QoS are occurring, • The means by which agreements on QoS are reached etc. The complete set of agreements reached to meet some end-toend QoS requirement may be termed as the QoS regime. The QoS regime will relate to a set of interactions between A and B via R. Possible connections in this sense are: • all interactions between A and B, for the duration of the binding; • all interactions between A and B, up to some point at which a new QoS regime is established (e.g. by re-negotiation); • A single interaction. Clearly a QoS regime must be established either before the liaison to which it applies can begin, or as part of the first 3

There are configurations involving more than two end-objects, which remains the open issues for further studies.

9

interaction of the liaison. There are a number of ways of doing this and points in time at which it can be done: • before system operation i.e. during system design, implementation, configuration, installation or initialization dynamically, by some management action, prior to the establishment of the binding between A and B; • dynamically, by some selection or negotiation process as part of the establishment of the binding between P and Q; • Dynamically, as part of a single interaction. All these means must be supported by the QoS architecture in CORBA. In practical circumstances R will typically be implemented as a complex collection of objects {O i}, some of which are ORBs, while others are objects that provide services of various kinds, such as trading. The objects A, B and {O i} will all have QoS contracts, which must guarantee the agreements in the QoS contracts on A, B and R. This immediately leads to future studies on the following open issues: • What constraints must be satisfied by the QoS contracts on A, B and {O i} in order to ensure that the QoS contracts on A, B and R are satisfied? • How are values for these contracts chosen within the constraints? • By what process are these contracts and indeed other agreements within the QoS regime established? • What mechanisms are used and at what times? We may need to investigate: • how to handle requirements for tradeoffs between different QoS characteristics, and tradeoffs between QoS and cost; • How to specify the “soft” levels of agreement, the probabilistic ones, in such a way that a clearly understood QoS can be delivered. The tentative conclusion is that the architecture for QoS does not need to take special account of either of those services. However, the trading architecture will need to participate in QoS mapping in QoS-enhanced systems.

IV. CONCLUSIONS The objective of this research was to address the problem of QoS provision for CORBA-based distributed MM across heterogeneous platforms. By itself, CORBA provides viable solutions to the issues of interoperability and openness in heterogeneous collaborative environments. It is common practice to deal with QoS in a very static manner during design and implementation of the system. In order to provide system-wide QoS behavior, some guidance must be given on how QoS requirements are mapped across the system layers. The QoS architecture must clearly indicate to what extent the system provides flexibility to customize the behavior. This issue is essential when the system is configured. A system must be aware if it is static or if it can be modified dynamically by a change in QoS requirements from the user or a QoS management function. QoS management functions make changes to the various aspects of the system in order to maintain guarantees of a previously negotiated contract. In summary, our research offers a comprehensive approach to QoS provisioning in CORBA-based distributed

MM [44] and [45]. It introduces a new architecture and methodology essential to deal with a QoS in complex heterogeneous environments. The concept of QoS provisioning via a trading service with the notion of a QoS Contract is suggested. In future work, we intend to extend the functionality of available objects in xbind framework, to support interactions with a trader. Incorporation of functionality for IONA Trader for example would support compatible infrastructure with xbind. ACKNOWLEDGMENTS The author is grateful for guidance given to him during his residency at the University of Ottawa. All including, Dr. N.D. Georganas the Thesis Director, Dr. Ionescu the Thesis CoDirector and Dr. Groza have contributed to this research. The author is currently a full-time Faculty at the Department of Electrical & Computer Engineering at Penn State Erie. The author wishes to express his sincere gratitude to Dr. R. Progelhof, the Director of School of Engineering & Engineering Technology for his guidance and motivation, to Dr. R. Ford, In Charge of Department of Electrical & Computer Engineering for his support and supervision. Finally, my gratitude goes to my colleagues including, Dr. R. Weissbach and to Dr. C. Coulston for their critical review. REFERENCES [1] Object Management Group “CORBA 2.0 Specification”, OMG Technical Document PTC/96-03-04, USA, March 1996. [2] C. M. Adam, M.C. Chan, A. A. Lazar, J.-F. Huard and K. S. Lim, “The Binding Interface Base Specification Revision 2.0”, OPENSIG Workshop on Open Signaling for ATM, Internet and Mobile Networks, The Moller Centre, Cambridge, UK, April 17-18, 1997; also CTR Technical Report #475-97-09,Center for Telecommunications Research, Columbia University, New York, April 16, 1997, available under URL: http://comet.ctr.columbia.edu/publications/ standard_contributions/BIB.html. [3] C. Aurrecoechea, A. Campbell, and L. Hauw. “Survey of QoS Architectures.” Multimedia Systems Journal, Special Issue on QoS Architectures, 1997. [4] N.D.Georganas, "Multimedia Applications Development: Experiences", J.Multimedia Tools and Applications, Vol.44, No. 3, May 1997, pp.313-332 (Invited). [5] G.V. Bochmann, B. Kerherve, A. Hafid, P. Dini and A. Pons, Functional Design of Adaptive Systems. In Proceedings of the IEEE Workshop on Multimedia Software Development, Berlin, Germany 1996. [6] G.v.Bochmann, R.Dssouli, J.Gecsei and B.Kerherve Posters on: ” QoS Negotiation and Adaptation: Project Overview “ The Third Annual CITR http://www.iro.umontreal.ca/labs/citr/posters.html, 29 Sep 1995. [7] Masaki, S., et al. “ Personal multimedia-multipoint teleconferencing system for broadband ISDN”, 3rd IFIP WG6.4 Conf. On High Speed Networking, Berlin Germany (March 18-22, 1991) pp.263-278). [8] D. Anderson, R. Herwitch and C. Schaefer, SRP: A resource Reservation Protocol for Guaranteed Performance Communications in the Internet, The International Computer Science Institute, Berkley, 1991. [9] Ahuja, S., Ensor, J. and Horn, D.N. “The Rapport

10

multimedia conferencing system” Conf. On Office Info. Syst. Palo Alto, CA., March, 1988, pp. 1-8. [10] R. Steinmetz and K. Nahrstedt, Multimedia: Computing, Communications and Applications, Prentice Hall, 1995. [11] R. Steinmetz, Towards an Architecture for Distributed Multimedia Applications Support; Proceedings of the International Conference on Multimedia Computing and Systems, Boston, Massachusetts, May 1994. [12] P. J. Kuhn, “ QoS in ATM Networks”, Slides, 1995. [13] ISO/IEC JTC1/SC21/N9309: Open System Interconnection,Data management and Open Distributed Processing, QoS, Basic Framework,Working Draft, January 1995. [14] J. T. Schuilenga, “ QoS Monitoring and Modelling of Continuos Streams in a Distributed Environment”, M.Sc. Thesis KPN Research/ University of Twente, April 1995. [15] Steinmetz, R., and Meyer, T., “Modeling distributed multimedia applications”, Int. Workshop on Advanced Communications and Applications for High Speed Networks, Munich, Germany (March 16-19, 1992). [16] A. Campbell, G. Coulson and D. Hutchison, A Quality of Service Architecture, ACM SIGCOM Computer Communication Review, Vol. 24, No. 2, pp. 6-27, April 1994. [17] K. Raymond, “Stream and Qos: a White Paper”, Contribution to OMG Telecommunications Special Interest Group (TELSIG), December 1995. [18] Zhonghua Yang and Keith Duddy, "Distributed Object Computing with CORBA", DSTC Technical Report 23, June, 1995. [19] S. Deering. Multicast Routing in a Datagram Internetwork. Ph.D. thesis, Stanford University, 1991 [20] N. Shacham. Multipoint communication be hierarchically encoded data. In IEEE Infocom’92, pages 2107-2114, 1992. [21] J.M.S. Doar “Multicast in the Asynchronous Transfer Mode Environment”, PhD Dissertation, St. John’s College, University of Cambridge, January 1993. [22] U. Black “ATM: Foundation for Broadband Networks”, Prentice Hall, 1995. [23] Lazar, A.A., Lim, K.S and Marconcini, F., "Realizing a Foundation for Programmability of ATM Networks with the Binding Architecture", Journal of Selected Areas in Communications, Vol.14, No.7, September 1996, pp. 1214-1227. [24] R. O. Onvural “Asynchronous Transfer Mode Networks Performance Issues”, Artech House, 2/e 1995. [25] P.G. Bosco (CSELT), E. Dahle (Telenor), M. Gien (Chorus), Grace (BritishTelecom), N. Mercouroff, N. Perdigues (Alcatel Alshtom Recherche), J.B.Stefani (France Telecom) “The ReTINA Project: An Overview”, ReTINA Technical Report 96-15, 1996. [26] Tawbi, W., and Horlait, E., “Video Coding and Quality of Service”, MASI Internal Report, University of Paris VI, France (1992). [27] Lazar, A. A. "Programming Telecommunication Networks", IEEE Network, September/October 1997, pp. 2-12. This paper is a Revised Version of the keynote address given by the author at the International Workshop on Quality of

Service, Columbia University, New York, May 21-23, 1997. Published in the workshop proceedings (pp. 3-23). [28] QoS – Framework, ISO/IEC CD 13236.2, October 1995. [29] "The xbind Project at Columbia University", Lazar, A.A., Web Site, at http://comet.ctr.columbia.edu/xbind [30] "The Binding Interface Base", Lazar, A.A., Lim, K.S. and Marconcini, F., CTR Technical Report # 412-95-18, Center for Telecommunications Research, Columbia University, New York, June 1995. [31] "Binding Model: Motivation and Description", Lazar, A.A., Lim, K.S. and Marconcini, F., CTR Technical Report # 411-95-17, Center for Telecommunications Research, Columbia University, New York, June 1995. [32] Andrea V. et al. “Distributed Multimedia and QoS: A Survey,” IEEE Multimedia, summer 1995. [33] P. Robin, G. Coulson, A. Campbell, G.S. Blair, and M. Papathomas. “Implementing a QoS controlled ATM based communications system in Chorus”. In Proceedings of 4th International Workshop on Protocols for High Speed Networks, Vancouver, Canada, 1994. [34] Perrow, G.S., et al. “The Abstraction Modeling of Management Agents” Proc. Of the Int. Symposium on Integrated Network Management, ISINM95, May 1995. [35] Popien, C., Schürman, G., Weiß, K.-H.: Distributed Processing in Open Systems (in German). Teubner, 1996. [36] P. Leydekkers and M. Mikael Jorgensen, “Stream Interfaces”, TINA-C, Contribution to OMG Telecommunications Special Interest Group (TELSIG), December 1995. [37] A. T. Halteren, P. Leydekkers and H.B. Korte, “ Specification and Realization of Stream Interfaces for the TINA-DPE”, KPN Research, Proceedings of TINA-95, February 1995. [38] IMA, Interactive Multimedia Association “IMA Recommended Practice, Multimedia Systems Service”, Second Draft, September 1994. [39] Schill, A., Zitterbart, M.: A System Framework for Open Distributed Processing; Journal of Network and Systems Management, Vol. 1, No.1, pp. 71-93, 1993. [40] Spaniol, O., Popien, C., Meyer, B.: Services and Service Trading in Client/Server Systems (in German). Thomson Publishing GmBH, 1994. [41] Schill, A., Mock, M.: DC++: Distributed Object Oriented System Support on top of OSF DCE; Distributed Systems Engineering Journal, Vol. 1, No. 2, 1993. [42] D. Thißen, C. Linnhoff-Popien, “Finding Optimal Service Within a CORBA Trader,” to appear. [43] Jon Siegel, “CORBA fundamentals and Programming”, John Willey & Sons, Inc. 1996. [44] Yagi, H., et al. “TINA-C Service Components,” Proc. TINA95 Integarting Telecommunications and Distributed Computing-from Concept to Reality, February, 1995. [45] Nuncio M.S. Zuquello and Edmundo R.M. Madeira. “A mechanism to Provide Interoperability between ORBs with Relocation Transparency”. In IEEE 1997.

11

Edward Babulak received the High National Diploma in Electronics in 1976 and the B.Sc. Degree in Electrical Engineering in 1982, both from the Slovak Technical University. Edward worked 10 years in industry as a project manager, consultant and a system engineer. He received a High National Certificate in Computer Aided Engineering from Brighton College of Technology, U.K. in 1990 and a Master of Science Degree in Computer Science from the University of East London, U.K. in 1991. Edward is currently a part-time graduate student at the University of Ottawa, working on the completion of his doctoral thesis in Electrical Engineering. He has been a faculty member in Electrical and Computer Engineering at Penn State Erie since August 1999 and holds the rank of a lecturer. His research interests are in the areas of QoS Provision for a CORBA-based multimedia applications, distributed heterogeneous systems and parallel computing. He is a member of the IEEE, the ACM and the Project Management Association.