Towards an Architecture for Distributed Multimedia Applications ...

Towards an Architecture for Distributed Multimedia Applications Supporty L. Besse, L. Dairaine, L. Fedaoui, W. Tawbi, K. Thai

Laboratoire MASI Université Pierre et Marie Curie, Paris VI 4, Place Jussieu, 75252 Paris cedex 05 (France) Emails: fbesse, dairaine, fedaoui, tawbi, [email protected]

Abstract In this paper we present the basic principles of a general architecture for distributed multimedia applications support over ATM-based networks. The architecture is aimed at providing the services, the mechanisms and the interactions required by multimedia applications. The architecture is based on the quality of service and communication management functions associated to the services it provides.

Keywords: Multimedia, Architecture, QoS, Synchronization, Transport, AAL, ATM.

1 Introduction Distributed multimedia applications involve dierent kinds of media like audio, video and text with varying characteristics. The transmission of these media introduces several Quality of Service (QoS) constraints such as limited delay, jitter and error rate, and guaranteed throughput. Some media like text require error-free transmissions but may tolerate delays while, on the contrary, a video transmission can accept some amount of errors (depending on the coding techniques) but has delay constraints. The traditional communication systems and architectures are not well suited to support these requirements. So, the integration of multimedia applications into a system requires the denition of new functions and

This work has been supported by CNET (French's National Telecommunication Research Center) under grant n 92-1B-178 on the Formal Design of Cooperative High Speed Multimedia Systems. Any views expressed in this paper are those of the authors alone. y Proceedings of IEEE ICMCS Conference (International Conference on Multimedia Computing and Systems), May 1994, Boston, USA.

services which provide these applications with the requirements they request for. Such an integration has to be done within a general framework that takes into account the new characteristics of the applications. Several issues have then to be considered. First, applications requirements should be mapped from applications specications in an easy and ecient manner. Second, synchronization requirements have to be met by suitable services and their associated protocols. Third, access to the communication subsystem has to be correctly congured according to application needs. In this paper, we address these issues within an architecture consisting of four levels: Application level, Synchronization level and Communication subsystem level. The latter is divided into the transport level and the network level, which provides AAL services. QoS management functions are considered at all the levels of the architecture. A exible management of the connections based on communication proles is also provided. The paper is structured as follows. In section 2, we give the main issues that have motivated the development of the architecture and the related work. Section 3 gives the general structure of the architecture and the principles of QoS and connection management. The application level, the synchronization level and the communication subsystem level are then detailed in sections 4, 5 and 6 respectively. Section 7 concludes the paper.

2 Motivation and related work Most of current works on multimedia communications are focused on isolated issues. There is a lack of a global architecture that integrates the functions required by multimedia communications in a general

way. The major concerns addressed by multimedia applications are:  the real time nature of media (voice, video, etc), i.e., the real time constraints they impose for their transmission and their presentation ;  the possibility to manage several multimedia ows simultaneously;  the possible distribution of data sources and sinks. Hence, the main issues that have motivated our proposal are the following:  understanding and mapping of applications requirements in a clear and ecient manner;  meeting synchronization needs (e.g., intra-ow and inter-ow synchronization) and dening their associated services and protocols;  providing a suitable choice of communication services with the required functionalities;  considering QoS at dierent communication levels. In fact, QoS serves as a basis for a homogeneous expression of requirements and a suitable way to manage these requirements at the dierent levels on the base of the dened abstractions at each level;  dealing with dynamic QoS, an issue that has been ignored by most of the existing works. While dynamic QoS introduces some management complexity, it is very important to consider as it is an inherent characteristic of multimedia applications and a good means for augmenting successful communications (e.g., accepting dynamic QoS degradations and continuing to serve a given ow);  providing a exible connection management scheme which allows the choice of communication services according to applications requirements and hence allowing to bypass services and protocols that are not required;  integrating the above issues correctly in a general architecture. The proposed architecture should have a well dened and limited number of levels, and a clear mapping should be achieved. Among the existing works on multimedia architectures, [12] presents a general one based on QoS. In this architecture, there is no exibility in the choice of the

communication services. On the other hand, a good mapping of the requirements cannot be achieved. We will achieve this mapping by the denition of proles associated to Management Information Bases (MIBs) that give the complete knowledge of specic applications requirements. [13] presents also an architecture for multimediaapplications support. The architecture is very general and is not able to provide any precise level for the communication services and functions it uses. In fact, the work supposes that there is an underlying architecture (e.g., OSI architecture) over which it relies and it is limited to high level considerations. On the other hand, there is no possibility for dynamic support of QoS within this architecture. The Tenet approach [11] does not consider any application issues. It is limited to the transport protocol layer and below. Hence, there is a lack concerning the mapping of applications requirements and the way to deal with applications related issues. In [20], new architectural concepts for multimedia communication support are introduced. The rst objective was to provide an ecient and parallel protocol implementation. As opposed to layering architectures like OSI, the protocols are seen as function aggregates that can be congured on application request. This exible choice of communication functions has inuenced our proposal.

3 A Multimedia communication architecture In this section, we attempt to provide a means to cope with the requirements described above, by dening a new architecture. We present the main concepts of the architecture. Then, we give two key concepts, that are QoS management and connection management.

3.1 Basic architecture design

The goal of our distributed multimedia communication architecture is to provide an environment which allows an easy design and support of multimedia applications. The architecture is composed of four levels. It consists of two main parts: the upper level, namely the application level, refers to the generic distributed multimedia applications platform over which distributed applications are expected to run. The second part denes a communication support platform for multimedia applications. It takes into account two main features: synchronization and communication.

ACM SCM TCM AALCM

AALQOSM

CONNECTION MANAGER

TQOSM

AAL LEVEL

SERVICE MANAGER

TRANSPORT LEVEL

OF

SQOSM

SYNCHRONIZATION LEVEL

QUALITY

APPLICATION LEVEL

AQOSM

Synchronization is often necessary in distributed systems to control the event order and timing of multimedia interactions [18]. Synchronization processes multimedia information ows. It allows simultaneous presentation of multiple ows, generated by one or several senders, and delivered to one or several receivers. On the other hand, the communication rely on a communication subsystem level. We assume that the latter is based on a ATM network, with end-to-end AAL interfaces. These can be accessed either directly or through a transport level. Nevertheless, a transport level may be desirable for multicast facilities or other end-to-end functions which do not appear in the AALs. Two related features characterize the proposed architecture: the QoS management and the connection management. They are both associated with the services dened at each level of the architecture. The QoS management functions control and dynamically react according to a dened strategy. They appear at each level as a specic QoS manager . The connection management provides a means for managing a multimedia session among all the services oered at each level of the architecture. The idea behind the connection management is to have a generic interface to access the levels. It permits an abstraction regarding the interconnection between the dierent levels. As the QoS management, the connection management function is ensured by specic connection managers . The architecture diers from the existing ones in that it provides a way to compute a path , from the application level down to the communication subsystem level. Such a path is given to a connection manager entity. It is computed according to a communication prole by a QoS manager. In doing so, it is possible to bypass some communication services if they are not relevant for the application. Figure 1 depicts the model of the architecture. It shows the four levels considered, namely application, synchronization, transport, and AAL levels. The two vertical boxes refer to the QoS manager, including a specic QoS manager as well as a connection manager at each level. The centered boxes, called MPUs (Multimedia Processing Units), contain the set of mechanisms and functionalities for a given level. These mechanisms are able to provide a set of services according to the functions of the level.

Figure 1: Our proposed four levels architecture

3.2 Connection management Connection management constitutes an important part of the architecture. In fact, this function provides a means for a exible and suitable connection choice, depending on application requirements. These requirements are described, for the connection part, as a prole given by the AQOSM (Application Quality of Service Manager). For each ow corresponds a prole which is dened at the application level as a path to follow by the ow. It gives the information on the services to use for handling the ow. At the application level, the application connection manager (ACM) has the responsibility of asking for the rst service in the communication prole, computed by the AQOSM. If there is more than one service to choose according to the prole, the ACM asks only for the rst one. Then, it is the task of the requested level's connection manager to ask for lower services. In the synchronization level, the SCM (Synchronization Connection Manager) fullls the same task as the ACM, by asking for a transport or an AAL service. If a transport service is requested, the TCM (Transport Connection Manager) chooses the suitable AAL. Once a communication service established at a given level, it is the responsibility of the corresponding QOSM (QoS Manager) to control and notify any problem that may occur. It may also contribute in local renegociation of a connection, with possible degradations as specied in the prole and tolerated by the application. The advantage of this approach resides in a maximum of exibility in the choice of the connections it provides. This is done without imposing strong constraints on the system. The only requirement is to allow the specic connection managers to bypass a certain level when the latter is not required, unlike

ACM SCM

8.b 8.a

8

TCM

3 3.a

TRANSPORT LEVEL

7.b

AAL LEVEL

6.b

7.a

7

AALCM

4 4.a

5

6.a

N service request N.x internal level action

SERVICE MANAGER

SYNCHRONIZATION LEVEL

OF

CONNECTION MANAGER

9 2.a

QUALITY

Figure 2 depicts the interactions between the architecture components during an initialization phase. By initialization, we mean the rst step occurring upon a multimedia session startup.

9.a

2

AALQOSM

3.4 Example of an initialization phase

1.a 1.b

APPLICATION LEVEL

TQOSM

A common function of all the dened levels of the architecture deals with QoS management. The major functions to be provided by QoS management are the mapping functions specic to each level, the QoS monitoring including the QoS control, and the interaction functions between the levels. Taking the QoS as the common basis to deal with multimedia communication issues renders the requirements management task easier. In fact, it allows to have a clear separation of the management functions at a given level with the appropriate abstractions (i.e., QoS parameters). These functions are realized by the QOSM (QoS manager) consisting of the AQOSM (Application QOSM) at the application level, the SQOSM (Synchronization QOSM) at the synchronization level, the TQOSM (Transport QOSM) at the transport level, and the AALQOSM at the AAL level. The role of mapping functions at a given level is to provide the lower level with suitable and understandable QoS parameters needed for the requested service. This function is more complete for the AQOSM which is responsible of giving the full communication prole that determines the services required for a particular ow. It is possible to have all the QoS information in the prole dened by the AQOSM. But this is not mandatory. QoS should be controlled continuously and the concerned QOSMs should react to cope with any problem related to QoS at their level. Monitoring QoS depends on the used service. Interactions take place between all the managers, but only the AQOSM can interact with the applications. This interaction is necessary for two purposes: mapping applications requirements from applications requests; and reporting any QoS changes or problems to the application. Interaction functions allow to deal with dynamic issues.

10

SQOSM

3.3 QOS management

1

AQOSM

an OSI system where a level can only access the next lower one. Moreover, the set of all the connection managers hides to the application the details of the path that the ows will follow.

6

1 User request 1.a application request 1.b profile passing

6

Network QoS notification 6.a network QoS result 6.b AAL QoS result

2 ACM request 2.a requested synchronization QoS passing

7

AAL QoS notification 7.a AAL QoS result 7.b transport QoS result

3 SCM request 3.a requested transport QoS passing

8

Transport QoS notification 8.a transport QoS result 8.b synchronization QoS result

9

Synchronization QoS notification 9.a application QoS result

4 TCM request 4.a requested AAL QoS passing 5 AAL request

10 Notification to user

Figure 2: Example of an initialization phase Actions are represented by arrows. Bold vertical arrows indicate interactions between two adjacent levels. They are numbered from 1 to 10. Thin horizontal arrows refer to internal level actions, and are subnumbered. The rst action is the user request (1), asking for the opening of the multimedia session. The request is given to the AQOSM (1.a) which computes the communication prole. The latter is then given to the ACM (1.b), which makes a request to a lower level communication manager (2, 3, or 4), the SCM in the example (2). A communication manager does the same and gives the upper-level requested QoS parameters to the corresponding MPU (2.a, 3.a, 4.a). The MPUs should wait for the lower level QoS results (eective QOS) to choose the most suitable mechanisms according to the prole and the requested services. These results are given to the QoS manager by the lower level notication (6, 7, 8, 9), and is passed to the MPUs (6.a, 7.a, 8.a, 9.a). Finally, the MPUs return their computed quality of service to their QoS manager (6.b, 7.b, 8.b). The last action refers the user notication (10).

4 Application level Application level is the rst level of the architecture where quality of service needs to be managed. At this

level, the support for interactivity and dynamicity is provided in addition to the mapping of application requests.

4.1 The Application Quality of Service Manager: AQOSM The Application Quality of Service Manager (AQOSM) has the task to transform an application request for multimedia data transmission into a set of QoS requirements and services. Thus, the AQOSM is in charge of making the link between the user requirements and the other levels' services and manage this link dynamically. The mapping is achieved through a prole. For each request of media transmission, the AQOSM determines a general communication prole. This one gives the dierent services (of the underlying levels) to use for the transmission of the ows.

4.1.1 Request mapping

A minimal set of constructs has been dened to allow the applications to express their needs and to provide at the same time a simple means for mapping function. These constructs include sending (SendfFlow_ Typeg[Transmission_Mode[option]]), and synchronization (Synchronized_With[option]) primitives [17]. The options describe a degree of synchronization or real time sending of the ows, and hence permit to know what the constraints are on the ow transmission. The sending or synchronization request may also specify if the ow type accepts degradation (in the option eld). This last issue is important for the handling of dynamicity. The AQOSM receives this request and processes it in order to generate the communication prole. The request concerns a given ow type (for instance MPEG or H.261 for video). The AQOSM uses MIBs that give the correspondance between a given ow type and the associated QoS parameters, such as delay, throughput, and so on. The AQOSM generates a prole that contains the services to use in the synchronization and communication subsystem levels, in order to fulll the application requirements. For example, consider an application involving an audio ow and a subtitle ow which corresponds to the textual translation of the rst one. Assuming that both ows need to be synchronized, in order to have a simultaneous presentation, and transmitted to several destinations. Table 1 gives the details of the proles of the two ows. Both proles specify the use of synchronization, transport and AAL services.

Audio Prole Synchronization Transport AAL

Text Prole Synchronization Transport AAL

intra_owfjitter=(6-10ms), delay=(100-150ms), ow_priority, source_id, sink_idg inter_owflinked_to(text_ow), skew=(240ms), masterg multicastfgroup_address, reliableg rate_control jitter=(6-10ms), delay=(100-150ms) AAL_type1fjitter=(6-10ms), delay=(100-150ms) error_rate(10;7), no_retransmissiong intra_owfjitter=(0ms), delay=(100-150ms), ow_priority, source_id, sink_idg inter_owflinked_to(audio_ow), (skew=240ms), slaveg multicastfgroup_address, reliableg rate_control jitter=(0ms), delay=(100-150ms) AAL_type3/4fow_mode, error_detection,handlingg

Table 1: Communication proles examples Note that a negotiation phase takes place between the involved AQOSM to determine the nal prole of each ow. This negotiation allows the applications to agree on a common QoS and the allowed degradations and is based on the protocol dened in [17]. If the result of the negotiation is successful, the AQOSM sends nally the prole to the application connection manager (ACM).

4.1.2 AQOSM interactions

The AQOSM has an adaptive behavior that allows to manage the dynamic changes of QoS during a session. Dynamic changes may have several causes. They could be originated by problems of the underlying levels or by new application requests. According to the principles of the architecture, the SQOSM, TQOSM, or AALQOSM (depending on the prole) may notify QoS changes to the AQOSM which takes appropriate actions. The decisions that the AQOSM takes in case of QoS problems are based on priority information for the ows and the QoS degradation or improvement range. When the AQOSM degrades a ow type or stop it, it noties the application if this latter has requested for.

4.2 Connection management

The ACM determines the rst level to which the service request has to be submitted. This is done

according to the prole. In the above example, the request is done to the SCM. At the same time, the prole is submitted to this level to allow it to ask for the following service in the determined path. In doing so, we hide all communication details to the application and hence oer a exible way to use communication services.

5 Synchronization level Depending on the application requirements, it may be necessary to perform ow synchronization. Recently, many eorts have been spent on multimedia synchronization [5, 6, 8, 9, ?]. According to [1], three dierent types of synchronization are dened:  type I : refers to intra-ow synchronization which characterize the synchronization inside a ow originated from a single source and arriving to a single remote sink;  type II : refers to inter-ow synchronization which characterize the synchronization of several ows coming from a single or multiple sources (i.e., centralized or distributed) to a single remote receiver (i.e., constituted of single or multiple centralized sinks);  type III : refers to the inter-destination synchronization which characterize the distributed simultaneous presentation of a ow bundle (i.e., a set of synchronized ows), coming from a single or multiple senders to a single or multiple receivers.

5.1 Synchronization requirements The underlying communication subsystem should be able to provide some capabilities to cope the application requirements, via synchronization level. For example if interactivity involving synchronization services, is needed then low delay transmission between participants is a minimum set of requirements. In order to allow ecient synchronization processing, we assume that the communication subsystem (transport or AAL) should rationally provide the following QoS: bandwidth guarantee, bounded information unit loss, in sequence information unit delivery, bounded end-to-end delay, and multicast facilities. The transport service is supposed to be adjustable to select or not some mechanisms. For example, real time presentation of transmitted media may not select retransmission-based error recovery mechanism.

These requirements are available with the ATM network oer and the new transport protocols such as XTP [19].

5.2 Synchronization services The synchronization service ensures the conveying of a bundle by ensuring the respect of the temporal relationships between transmitted information units (IUs). Depending on the dierent temporal relations between the components of a bundle, several types of synchronization can be performed. For example, a bundle composed of an audio ow and subtitle ow needs an intra-ow processing for each of these ows. The periodic audio ow must be regulated to avoid presentation problems due to mismatching period between source and sink. The subtitle ow should be controlled by time signature preservation mechanisms [6, 15] to ensure that the temporal structure of the presented ow at both the sender and the receiver is the same. In addition to these intra-ow requirements, an inter-ow synchronization has to be performed to ensure the simultaneous presentation between audio and subtitle ows. Moreover, if the multimedia bundle is broadcasted to several receivers, it may be necessary to coordinate the distributed presentation (inter-destination synchronization). Figure 3 shows the information required to describe a multimedia bundle. The bundle identier (bundleid) gives an idea of the useful components for a synchronization service. bundle_id

flow_id1 ... flow_idN bundle_matrix

 F _id1   F _id1 X   ... ...  F _idN ◊ 

source_id sink_id delay jitter flow_propriety flow_priority

source@site source_attribute sink@site sink_attribute

... F _ idN  ... ◊   X ...  ... X 

Figure 3: Structure of the bundle identier Each ow is characterized by a source and a sink identier and several attributes like delay, jitter, internal ow property (e.g., periodicity, delete/duplication of IU possibility, etc.) and ow priority (e.g., slave, master [4]). Source and sink are dened by their addresses and their characteristics (e.g., collection or delivery delay [9], etc.). Temporal relations between ows (i.e., skew) are expressed in the bundle matrix which permits to deduce inter-ow and interdestination synchronization constraints.

The bundle identier is a structure used by the synchronization services accessed with several primitives. These primitives are bound to synchronization mechanisms as those proposed in [6, 15]. They are given in table 2. Primitives

start_bundle stop_bundle pause_bundle resume_bundle stop_ow pause_ow resume_ow add_ow delete_ow modify_ow put_IU get_IU

Parameters

bundle_id, status bundle_id, reason bundle_id bundle_id ow_id, bundle_id ow_id, bundle_id ow_id, bundle_id ow_id, bundle_id, ow_id, bundle_id, ow_id, bundle_id, ow_id, bundle_id, ow_id, bundle_id,

status status status status status

Table 2: Synchronization Primitives The proposed primitives are structured in three classes. The rst class concerns the bundle manipulation (ended by _bundle). These primitives allow a control over the entire bundle. The third class of primitives deals with ow management in the bundle (ended by _ow). They allow a control on specic ow (e.g., pausing a given ow). The last class of primitives permits the sending and receiving of information units (ended by _IU). In order to have the complete set of primitives, these can be extended by OSI-like service extensions (request, indication, response, conrmation), depending on their own semantics.

5.3 Connection and QoS management The synchronization connection manager (SCM) translates requests from the ACM into lower level connection manager requests (i.e., TCM or AALCM), with possible interactions with the synchronization MPU and the SQOSM (see section 3.4). When the start_bundle primitive is invoked by the ACM, the SCM has the aim to build up a bundle identier (given the communication prole) used to select the suitable synchronization mechanisms. On the other hand, the SCM makes a request to the underlying level (according to the prole) to open the suitable connections. The requested communication QoS parameters are given to the synchronization MPU which deduces the actual synchronization QoS parameters. The SQOSM compares the actual and requested synchronization QoS parameters and noties the upper level, if there is any change.

6 Communication subsystem level The communication subsystem provides information transfer between end-systems. The architecture is based on an ATM sub-network with end-to-end AAL services. To avoid unuseful redundancies in communication functionalities, a suitable selection of transport functionalities has to be done. It is commonly agreed that conventional transport protocols such as ISO TP4 or TCP and their associated services are not able to make the best possible use of transmission capabilities of new high speed networks. Furthermore, they cannot provide guarantees required by multimedia applications. Most of current works on transport level are focused on the denition of a new transport service embedding point-tomultipoint communications and emphasizing the QoS concepts [7, 3, 2]. Comparing transport and AAL functionalities highlights a straight overlap that is translated in unuseful redundancies. A strictly hierarchical approach would only introduce heaviness, and even inconsistencies (e.g., performing error recovery by retransmission over AAL 1). In other respects, multimedia applications need new communication mechanisms such as AAL type selection, assured multicast and QoS control. The diversity of the constraints enforced on the communication subsystem requires this one to be as exible as possible. In particular, dierent types of services have to be supported for point-to-point and point-to-multipoint communications: connectionoriented, connectionless, connectionless with acknowledgment, transaction-oriented. The transport level should therefore be designed as a set of functional blocks to combine and congure according to the required service and the service provided by the AAL like in [20]. The connection management must provide dierent connection set-up mechanisms (implicit, explicit, fast connect) and termination mechanisms (abrupt, graceful for each transfer direction). Control mechanisms should be turned on or o, with selectable policies (e.g., no error control or selective retransmission). The eXpress Transfer Protocol [19] is currently one of the most promising lightweight transport protocols for high speed networks. It seems to fulll our needs, provided some extensions related to QoS. However, the architecture does not restrict to one particular protocol. The architecture's communication subsystem has not only to provide means for negotiating end-to-end QoS but to control and monitor it over all the com-

munication duration. The transport QoS semantics has been proposed to be extended with three types of QoS: best eort, threshold and compulsory [7]. In the proposed architecture, these notions provide a good way to control the QoS by the TQOSM. A request to the transport level, from either the ACM or the SCM, involves a request by the TCM to the AALCM. The prole associated to the transport request allows the AAL type selection and furthermore the AAL-SAP to which the request has to be submitted. The QoS supplied by the AAL is returned to the TQOSM. According to the gap observed between the oered AAL QoS and the transport QoS to provide, protocol functional blocks are congured and available QoS values are computed. They are reported to the TQOSM and then compared with the requested values. According to the QoS type, the QOSM of the requesting level is nally notied with a failure or a success.

7 Conclusion In this paper we have presented the basic principles for a multimedia communication architecture. The novel aspect of this architecture is the exible connection management it provides in addition to a suitable QoS support. The architecture has been primary designed for an ATM-based network, but can be easily extended to work on any network providing QoS guarantees. For example an Internet running ST-II protocol. Future work will focus on dening the functional blocks of the transport level. These functional blocks will rely on the XTP protocol. We also plan to dene inter-ow and inter-destination mechanisms, required at the synchronization level.

References [1] L. Besse, L. Dairaine and E. Horlait, Synchro-

nisations Multimedia Distribuée: Problématique, Concepts et Modèle, Procs. of CFIP Conf. Mon-

tréal, CANADA (September 1993)

[2] S. Boecking et al., The BERKOM MultiMedia Transport System , International Conference on Open Distributed Processing, Berlin, Germany (September 1993) [3] S.

C. Andersen, High-Speed Transport Service (HSTS) , Proposed Contribution to ISO/IEC.JTC1.SC6/WG4 (July 1992)

[4] D. P. Anderson and G. Homsy, Synchronisations

Policies and mechanisms in a Continuous Media I/O Server, Report N UCB/CSD 91/617,

University of California, Berkeley, USA (February 1991) [5] L. F. R. Carmo, P. de Saqui-Sannes and JP. Courtiat, Basic Synchronization Concepts in Multimedia System, Procs. of Multimedia IEEE Conf. San Diego, USA (1992) [6] L. Dairaine, H. Santoso and E. Horlait, A Deter-

ministic and Statistical Intra-ow Synchronization Services , Procs. of IEEE MICC Conf. Kuala

Lumpur, MALAYSIA (November 1993) [7] A. Danthine, Y. Baguette, G. Leduc and L. Léonard, The OSI95 Connection-Mode Transport Service - The Enhanced QoS , Fourth IFIP Conference on High Performance Networking, Liège, Belgium, December 14-18 (1992) [8] M. Diaz, P. Senac and P. de Saqui-Sannes, Un modèle pour la spécication et le contrôle de la synchronisation en environnement distribué, Procs. of CFIP Conf, Montréal, CANADA

(September 1993) [9] J. Escobar, D. Deutsch and C. Partridge, Flow Synchronization Protocol, Research Report BBN, 10 Moulton Street, Cambridge, MA02138, USA (March 1992) [10] D. Ferrari, Delay Jitter Control Scheme for Packet-Switching Internetwork, Computer Communications, Vol. 15 N 6 (July/August 1992) [11] D. Ferrari, A. Banerjea, and H. Zhang, Network Support for Multimedia, a Discussion of the Tenet Approach, Tenet group, International Com-

puter Science Institute, Berkeley, CA, TR. 92-072 (November 1992) [12] ISO/IEC JTC1/SC21/WG1, A Suggested QoS Architecture for Multimedia Communications

(September 1992) [13] C. A. Nicolaou, A Distrivuted Architecture for Multimedia Communication System, Ph. D. Thesis, University of Cambridge, UK (December 1991). [14] M. d. Prycker, Asynchronous Transfer Mode, Col. Computer Communications and Networking, Ellis Horwood (1991)

[15] H. Santoso, L. Dairaine, S. Fdida and E. Horlait, Preserving Temporal Signature: a Way to Convey Time Constrained Flows, Procs. of IEEE Globe-

com Conf., Houston, USA (November 1993) [16] W. Tawbi, L. Fédaoui and E. Horlait, Management of Multimedia Applications QOS on ATM Networks, IFIP International Conference on

Computer Networks, Architectures and Applications: Networks92, Trivandrum, India (October 1992) [17] W. Tawbi Quality of Service in Multimedia Com-

munication Systems: A Study of a Framework and Specication for a Negotiation Protocol between Applications , Ph.D Thesis, University of

Paris 6, France (December 1993) [18] N. Williams, G. S. Blair, G. Coulson and N. Davies, A Support Platform for Distributed Multimedia Application, Research Report, Distributed Multimedia Research Group, Lancaster University, Lancaster UK (1992) [19] Protocol Engines Inc., XTP Protocol Denition , Version 3.6, January (1992) [20] M. Zitterbart, B. Stiller and A. Tantawy, A

model for Flexible High-Performance Communication Subsystems , Journal on Selected Areas in

Communication (May 1993)