two-party or multipoint connection carrying traffic from a ..... Connection refused. 4.2.4 Data Handler. This module is responsible for the handling of data trans-.
A Protocol Architecture for Guaranteed Quality of Service in Collaborated Multimedia Applications Ahmed Bashandy Raymon Paul Shahab Baqai Sahra Sedigh Husni Fahmi Arif Ghafoor School of Electrical & Computer Engineering, Purdue University, West Lafayette, Indiana 47907 T & E/ OSD, 300 Pentagon, Washington , D.C. 20301
Abstract The role of multimedia applications in our day-to-day life
Computational Backbone
has dramatically increased in the last few years. In this paper, we present an architectural framework for the distributed multimedia systems. The architecture consists of three layers: the application layer, the con guration and synchronization layer, and the network layer. The three layers are backed up by two backbone layers, namely, the database and the computational backbone. We present Figure 1: Layered architecture for distributed a precise description of each layer together with formal multimedia applications speci cations using nite state automata. 1Networked Introduction so that transitions not starting with either \+" or \{" and distributed multimedia information sys- tion are transitions caused by the module itself but do not retems are expected to play an important role in engineer- sult in transmission of messages. Transitions starting with ing and technological progress in the future. With devel- a \+{" sign are those by messages received from opments in such areas rapidly becoming a reality, many local modules or remotecaused nodes, but result in messages sent ambitious multimedia based projects are being pursued to other local or remote modules. by the the industry, academia, and the governments [1]. Typically, a multimedia presentation or document conThis paper is organized as follows. In the next Section, tains media objects which need to be presented to the end we describe the application layer. In Section 3, we describe user according to some temporal as well as spatial con- the con guration and quality management layer. In Secstraints. tion 4, we describe the network layer. In Section 5, we The multitude of multimedia applications that are be- describe the backbone layer. The conclusion and future ing put forward provide a synopsis for a broad class of work is presented in Section 6. distributed multimedia services that fall under the general category of Computer Supported Collaborated Work (CSCW) applications. We identify the CSCW application 2 Application Layer as an interactive multimedia environment which allows ef cient real-time search and retrieval of multimedia infor- The application layer is the highest of the three layers of mation over broadband networks. In multimedia CSCW the proposed model. This layer views the system from the applications information exchange may involve communi- perspective of the end-users. Thus all types of workgroup, cation in a workgroup or client-server environment. Func- interactive, and messaging paradigms are included in this tionally the multimedia system can be partitioned into layer. As mentioned in the Introduction, CSCW constidi erent components which are essential for its operation. tutes a broad class of multimedia applications. Hence, in In this paper, we specify a functional architecture that this paper, we focus in this class of applications. can be used to de ne distributed multimedia systems from Two important features of CSCW systems are the mode the application as well as the service providers' point of view. We identify the various functional aspects within a of interaction and the geographical distribution of the The mode of interaction may be synchronous distributed multimedia system and propose a uni ed lay- users. or asynchronous, and the geographical distribution eiered architecture to support di erent distributed multime- ther local or remote. The four resulting categories condia applications. Each layer is further divided into speci c sist of: (1)synchronous-local such a category is word functional units that co-operate to provide the services ofprocessing; (2)synchronous-remote such as teleconferencfered by one layer to the layer above it. Fig. 1 depicts the ing systems; (3)synchronous-local which has no imporproposed layered architecture. distinction has been noticed between this category The di erent functional units are modeled by nite tant and the asynchronous-remote category; (4)synchronousstates automata. In our nite state automata, we adopt a remote such convention similar to the one adopted in [2]. Transitions board systems.as electronic mail, messaging and bulletin starting with a \+" sign are those caused by messages received from local modules or remote nodes. Transition The formality of communications also a ects CSCW destarting with \{" sign are those caused by the module it- sign. Technology has focused on formal communications, self but result in messages sent to other local or remote whereas informal communications constitute a major pronodes. In this paper we have extended the above conven- portion of cooperative work. Several di erences between formal and informal communications, are mentioned in [3] Database Bacbkone
Application Layer
Configuration and Synchronization Layer Network Layer
2.1 Basic Causal Semantics of Collaborative Environments A collaborative environment can be represented by a hi
IDLE
2.2 Application Layer Functions
The application layer is the multimedia layer responsible for collaborating user contributions and performing various application-speci c functions subject to pre-speci ed quality of presentation. From the networking point of view, the main function performed by the application layer is concurrency control. Depending on the level of interaction desired, corresponding levels of concurrency control should be exercised. In token based concurrency control mechanisms, each ow is assigned a single token upon creation. The token acts as an authorization for data transmission, and if required by the application, may be subsequently replicated, distributed, or transferred. Token mechanisms allow for several degrees of concurrency control, including the following: (1) Floor control where each ow has a single token, which is transferred from user to user whenever the oor is transferred; (2) Chalkboard interaction where interaction takes place in two phases such that in the rst phase, a single user is given exclusive and uninterrupted control over the ow, while n the second phase, other users are allowed to address the speaker by replicating the token; (3)discussion groups where the conversation breaks up
-init_conv
Figure 2: Hierarchy of a Collaborative Environment.
+conv_refused
Mn
WAIT_CONV
M2
+conv_established
M1
+conv_terminated
Fn
CONV
F2
-init_flow
F1
+flow_refused
Ck
WAIT_FLOW
C2
+flow_established
C1
in Figure 3.
+flow_terminated
2.3 FSM for the Application Layer A nite state diagram for the application layer is depicted
FLOW
erarchical structure, as proposed in [4]. The hierarchy depicted in Fig. 2.1 is an integration of the existing approaches. In this gure, a collaborative environment is represented by the root node \E". In the hierarchy, concurrent conversations, C1,C2, ,Ck, may be established. A conversation is a logical entity that consists of one or more
ows. An example of a conversation can be a video conference between two or more persons. Once conversations are established, ows, F1, F2, ,Fn, are subsequently instantiated for each conversation. A ow is de ned as a two-party or multipoint connection carrying trac from a single medium. A medium is usually a data type or a collection of data types that have similar QoP requirements. For example, a colored video stream can be considered a medium while an audio stream as another medium. Referring back to the example of the video conference, two di erent ows are instantiated for the audio and video streams. The video ow is carrying the frames of the faces of the persons participating in the video conference while the audio ow is carrying their voices. A user or group of users may participate in multiple conversations, and may take di erent roles (i.e. participant, chairperson) in various conversations. E
into smaller sub-conversations and a single token is shared by the sub-conversations; (4)brainstorming wher ethere is no concurrency control. Other functions provided by the application layer, include spatial management, event response, providing separation between public and private workspaces and establishing continuity between applications used while working alone and those used in meetings [5].
Figure 3: Finite State Model of the Application Layer. The application layer is initially in the idle state, until a user requests the establishment of a conversation. The application layer then sends the primitive init conv to the con guration and quality management layer, and moves to the state wait conv. If the conversation is successfully initiated, the con guration layer responds with conv established(conv id), which moves the system to the conv state, if not, it issues the primitive conv refused, returning the system to the idle state. Upon the initiation of the conversation, the application layer may request the creation of one or more ows, by issuing the primitive init flow, and moving to the state wait flow. If the ow is successfully created, the con guration layer responds with flow established, and the system moves to the flow state. If the ow creation fails, the primitive flow refused is issued instead, and the application layer returns to the conv state. Flows are terminated by sending the flow terminated primitive, and upon termination of the last ow, the system returns to the conv state. Conversations are terminated with the conv terminated primitive, and upon termination of the last conversation, the system returns to the idle state. The primitives are explained in more detail below: response: init conv(participant list), conv established(conv id) This primitive is issued from the application layer to the con guration and quality management layer in order to initiate a conversation. The con guration layer responds with a unique conversation id. join conv(user id, conv id), response : This message is join ok(user id, conv id) sent to the con guration and quality management layer to specify that the user user id wishes to join
the conversation conv id. The con guration layer responds with the primitive join ok to indicate that the speci ed user is now added to the communication structure of the conversation. response : leave conv(user id, conv id), leave ok(user id, conv id) This message is sent to the con guration layer to specify that the user user id wishes to leave the conversation conv id. The con guration layer responds with the primitive leave ok(conv id, participant list) to indicate that the speci ed user is now removed from the communication structure of the conversation. terminate conv(conv id), response : conv terminated(conv id) Upon receipt of the leave ok primitive, the application layer checks the participant list. If the list is empty, it issues the terminate conv primitive, instructing the con guration layer to terminate the conversation and all remaining ows. The con guration and quality management layer responds with the conv terminated primitive. reinit flow(conv id, medium, parameters), sponse : flow initiated(flow id, token) This message is sent to the con guration layer to request the creation of a ow within a conversation speci ed by conv id. The ow will carry trac of the type speci ed by medium. Based on the medium, the QoP parameters may be determined and delivered to the con guration and quality management layer. The con guration and quality management layer responds with a unique ow id, and a token, which is used to authorize control of the ow.
3.1 Layer Services
The con guration and quality management layer provides two types of services, namely, end-to-end quality assurance and resource management. Such services are based on the QoP parameters speci ed by the application layer. In this section, we describe the services provided by the con guration and quality management layer.
3.1.1 Quality and synchronization considerations The application/user speci c quality requirements are provided by the application layer. The application/user usually specify quality in term of some user perceivable parameters. The con guration layer is responsible for translating teh quality of presentation (QoP) to network Quality of Service (QoS) parameters, which would then be used to determine the resource required and synchronization mechanism to be used. This presentation quality mapping to QoS can be performed as a layer function. Continuous streams, like audio and video, consist of smaller presentation units which have to be played out within strict temporal speci cations. In multimedia systems, synchronization is the preservation of the temporal constraints within and among multimedia data streams at the time of play-out. Many synchronization schemes, such as feedback, resource controlled, and deadline based, have been proposed [6,7]. Synchronization is implemented as one of the con guration layer functions.
3.1.2 Con guration and resource management
Most of the multimedia applications require both clientserver and multicasting types of connectivity. Information exchange may involve communication in a workgroup or client-server environment. Depending on the distribution of the multimedia information, as identi ed by the application layer, we may need to establish point-to-point, conv status(status change type, multi-cast, unidirectional multi-cast, or a combination of procedure name), response : status changed() connection con gurations. In addition, depending This primitive is used for event handling. The type these on the type of application, certain services may be reof status change and the procedure to be called are quired such as data encryption and authentication. indicated as arguments. To ensure the satisfaction of the QoP requirements, the layer reserves resources at the end points 3 Con guration and Quality Man- con guration and provides the network layer with necessary information to establish a path or a multicast tree, and reserve agement Layer in the intermediate nodes. The con guration Di erent multimedia objects have di erent quality, stor- resources age, communication and presentation requirements. Also, layer may use existing protocols such as RSVP [8]. each application may require customized system environ- 3.2 Layer Functions ments and specialized protocols to cater for the di erent The con guration and quality management layer provides aspects in supporting the application. To ensure the de- multiple services to the upper layer. In order to provide livery of multimedia information at the destination within these services, the layer carries out certain functions that the quality constraints, we require intelligent management can be implemented as independent modules. In this subof resources and protocols to provide exible and ecient section, we present the functions performed by the con gmechanisms for communication of multimedia data over uration and quality management layer. computer networks with the available resources while en- 3.2.1 Determining the Connection Type and suring the speci ed quality. The ultimate objective of a Characteristics distributed multimedia system is to ensure in-time, that is One of the important functions of the con guration and synchronous, presentation of information within the qual- quality management layer is to decide the type and characity constraints required by the application. teristics of the network sessions based on the application. As the name suggests this layer is responsible for con- Characteristics and types of connections include secured guration management and maintaining quality require- channels versus open channels, unicast versus multi-cast, ments at the time of play-out of multimedia data. In the and public versus private channels with proper authentifollowing subsections, we identify the services performed cation. These characteristics and types can be determined by this layer and then present the functions necessary for by the arguments of the primitives issued by the applicaproviding these services. tion layer.
3.2.2 User-speci ed Quality mapping to QoS
The user or application speci c presentation quality is application and media dependent. To determine the resources required for transportation of multimedia data within the given quality, these application or user speci ed quality constraints have to be mapped to network QoS parameters. Usually, users specify QoP is a fuzzy manner. It the responsibility of the con guration layer to map such fuzzy parameters into concrete QoS requierements. 3.2.3 Filtering with quality constraints Under resource limitations, it may be possible to drop some data and still satisfy the quality requirements of users and/or applications. When dealing with encoded, compressed, or encrypted data, the e ect of dropping of a packet may not be uniform. It is one of the functions of the con guration and resource management layer to decide which portion can or cannot be dropped based on media speci c properties and the QoP requirements. 3.2.4 Scheduling Server-based scheduling algorithms can be used to preschedule transmission of multimedia streams to remote clients to achieve synchronized play-out at the destination. These scheduling algorithms need to have low-complexity for real-time scheduling and be able to deal with network randomness and resource limitations. After the server and routers grant the resources to the requesting client, the synchronization algorithms are applied. For this purpose the server and routers can use a predetermined transmission schedule that is consistent with the time a new client joins the session.
4As mentioned Network Layer in Section 1, the network layer is the low-
est layer in the three layer model that we proposed for the collaborative multimedia applications. The network layer is concerned with conveying multimedia data from one point to another in a distributed system. In this section, we identify the services and functions of the network layer. Then we specify the primitives sent to and from the network layer. Finally, we give a nite state machine model for the di erent modules and functional units of the network layer.
4.1 Services and Functions of the Network Layer The network layer is the multimedia layer responsible for
delivering a network stream or datagram from one or more source nodes to one or more destination nodes subject to pre-speci ed quality of service parameters. Based on the above de nition, we can identify several functions and services provided by the network layer. We distinguish between a service and a function by the fact that a service has to involve upper layer interaction while a function may or may not involve upper layer interactions.
4.1.1 Services Provided by the Network Layer Connection establishment for connection oriented sessions: A network process requests a con
nection to a remote network process subject to certain quality of service parameters. The network layer provides and manages such a service if it is possible. Management of multi-cast groups: The network layer provides facilities for a group of applications to send and receive data from one another. The network
layer provides the necessary functionality for creating/destroying multi-cast groups and joining and leaving an existing group. The network layer also allows di erent members to have di erent quality of service parameters and manages permissions and security issues. Providing information about the network: Information can be divided into general information and session speci c information. General information can be the capacity of a path or the presence of a certain network process on a certain node, such as using the ping command. Session speci c information can be performance data, such as number of packets lost, throughput or maximum capacity of a path, and the minimum or maximum propagation delay along a path. Transmitting and receiving Data: An application should be able to transmit and receive data in the form of a network stream or datagram. The network layer provides the necessary means to ensure the delivery of data as speci ed by the QoS parameters. These means include switching capabilities, packetization, segmentation and re-assembly, modulation, and others.
4.1.2 Functions of the Network Layer
The functions of the network layer are operations that the network layer performs to provide services to the upper layers. The functions may or may not have direct coupling with users, whereas services are directly coupled with the user of the layer. Route Establishment: One of the most important functions of the network layer is route establishment. The user speci es the destination and the quality of service, and it is the job of the network layer to nd an appropriate route, if any exists. If the destination is a multi-cast group, the network layer creates a tree or update the existing multi-cast tree rather than establishing a route. Route nding usually involves exchanging of messages across the network, invoking several central and distributed algorithms [9]. Security and Encryption: Network Layer should provide data encryption and authentication schemes. There is a wide variety of data encryption methods [10]. Error Detection and Correction: To ensure reliability, the network layer should provide fast error detection and correction mechanisms [11]. For multimedia data, error correction through error correction codes is preferable over retransmission schemes. Hardware Transparency: Since a data network supports a very wide range of hardware devices, the network layer should be able to hide the details of the hardware and provide a level of abstraction that enables network processes to work on heterogeneous networks. Several schemes have been suggested. One of them is the XBIND architecture [12], in which all resources, including network resources are mapped into hierarchical object oriented system.
4.2 Finite State Representation of the Network Layer
In this section, we give a formal representation of the network layer through several nite state machines. We envision the network layer as composed of several modules. Such modules can communicate with other modules on the same node or with modules on a remote node. Upper layers can obtain services from the network layer by sending messages to the Interface Module. Each module is represented by a nite state machine. Each nite state machine is represented by a directed graph and a table. The heading of table contains the following titles: Transition, Input Message, From, Output Message, To and Semantics. Transition indicates the name of the transition. Input Message indicates the message that resulted in the current transition. From indicates the source module of the input message. Output Message indicates the message that is sent from the module as a result of the transition. To indicates the destination module. Semantics indicates the meaning of the transition.
4.2.1 Route Manager Module
The Route Manager Module is responsible for establishing the virtual circuit between the initiator and the acceptor. The initiator is the node which has an application requesting the establishment of a virtual circuit to a remote application residing on a remote node. The acceptor is the node which has an application waiting for a virtual circuit connection. Fig. 4 and table 1 summarize the speci cations of the Route Manager Module. Table 1: Speci cation of the Route Manager Module
WAIT +hop_found FOUND
-fhop ACTIVE
-res
WAIT
+no_hop +res_acc
+VC_create +VC_Connect
+res_ref
-VC_Fail
FAIL
IDLE
RES
timeout
-VC_Refuse
-VC_Create +no-resource
+VC_Refuse
+-allocated WAIT
+VC_Accept -allocate SUCCESS
WAIT
Figure 4: FSM for the Route Manager 4.2.2 HopFinder Module
The HopFinder Module is responsible for nding the next hop of the route between the source and destination based upon the speci ed quality of service. Fig. 5 and Table 2 summarize the speci cations of the hop nder module. QUEUE_WAIT
IDLE
ACTIVE +fhop
WAIT
nl
tl
lt tl
LOCKED
-send_hop SUCCESS +hop_found
-error_hop
-comp_nh
WAIT +no_hop
Transition
Input Message
From
+VC Connect VC Connect Interface or Peer or or Route +VC Create VC Create Manager {fhop +hop found
send hop
hopfinder
+no hop
error hop
hopfinder
{res
Output Message
To
fhop
hopfinder
reserve
+res acc
Reserved
+res ref
Reserved
Config. Layer Config. Layer
{VC Create timeout +VC Refuse VC Refuse +VC Accept VC Accept
VC Create
+{ no resource no resource
Peer Route Manager
Peer Route Manager Peer Route Manager Config. Layer
Allocate
Interface allocate
Config. Layer
Config. Layer
interface
{allocate +{allocated VC Success
Config. Layer
VC fail
FAIL
Semantics Message from interface or Peer Route Manager to establish a VC Find the next hop in the VC Hopfinder sent next hop address hopfinder cannot find next hop Temporary reservation resources Successfully reserved resources Config. Layer cannot reserve Send a request to the next hop No response from next hop Next hop refuse connection Next hop accept connection Allocate the reserved resources permanently Allocate the reserved resources permanent Resource Manager cannot allocate resources
Figure 5: FSM for the HopFinder Table 2: Speci cation of the HopFinder Module Transition
Input Message
+fhop
fhop
From Route Manager Module
Output Message
To
comp nh
Comput. Backbone
send hop error op
Route Manager Route Manager
lt nl tl {comp nh +hop found next hop er+no hop ror hop {send hop {error hop
Comput. Backbone Comput. backbone
4.2.3 Acceptor Module
Semantics Message from connect to find next hop Lock Information Tables Information Tables not available Information Tables locked Compute next hop Next hop found Cannot compute next hop Send the next hop Send fail to find next hop
This module is responsible for accepting a connection request at the destination node. Although this module exists in every node, it is only active when the interface module at the destination node is waiting for a connection in the ACCEPTING state. Fig. 6 and Table 3 summarize the speci cation of the Acceptor Module.
SUCCESS
Table 4: Speci cation of the Data Handler Module
+allocated WAIT -allocate
-R_CONNECT +VC_Create
IDLE
ACTIVE
Transition
+no_resource
-VC_Refuse
+data in data in { N DATA +send send {sent
FAIL
Figure 6: FSM for the Acceptor Table 3: Speci cation of the Acceptor Module Transition
Input Message
+VC Create VC Create {allocate
From Peer Route Manager
+allocated +no resource no resource
Output Message Config. Layer Config. Layer
To
Allocate Allocate
Config. Layer Interface R CONNECT,Module, Peer VC ACCEPTRoute Manager Peer VC Refuse Route Manager
{ R CONNECT {VC Refuse
Input Message
Semantics Message to establish VC Allocate resources Resource Allocated successfully Config. Layer cannot allocate resources Inform the Upper Layer and peer Route Manager that connection is established Connection refused
4.2.4 Data Handler
This module is responsible for the handling of data transmitted and received. This includes encrypting secured data, segmentation, re-assembly and forwarding. In addition, the data handler delivers each data packet to the Con guration Layer for further processing such as ltration and synchronization. Fig. 7 and Table 4 summarize the speci cation of the data handler. WAIT
From
Output Message
To
Semantics
N DATA
Upper Layer
data-in
Next hop data handler
Data arrived from the previous hop Deliver data to upper layer Upper Layer sending data Forward data to next hop
Previous hop data handler Upper Layer
and the new intermediate nodes with its tree so that each node can update its local view of the network. Fig. 8 and Table 5 summarize the speci cation of the multi-cast joiner. ACTIVE
+New_Member -comp_tree +N_JOIN IDLE +-no_tree WAIT +-no_resource +new_tree +-allocated TREE
Figure 8: FSM for the Multi-Cast Joiner Table 5: Speci cation of the Joiner Module Transition
Input Message
+N JOIN N JOIN +NewMember
NewMember
{comptree
From
Output Message
To
comp tree
Comput. Backbone
Interface New member node
Comput. Backbone Comput. +{ no tree BackMG FAIL Interface no tree bone Success Interface +{ alloConfig. MG or other or Newallocated cated Layer multi-cast Member tree nodes +{ Config. Interface no resourceno resource Layer MG FAIL
+new tree new tree
+data_in
-N_DATA IDLE -sent +send
Semantics Interface wants to join a multi-cast group A new member on a remote node wants to join a multi-cast group Compute the new multi-cast tree New multi-cast tree computed Cannot compute multi-cast tree
No resource available
WAIT
Figure 7: FSM for the Data Handler 4.2.5 Multi-cast Joiner
4.2.6 Interface Module
This module handles the request sent from the upper layers and provides them with the appropriate responses. Fig. 9 and Table 6 summarize the speci cation of the InThis module is responsible for including an upper layer terface Module to a multi-cast group. We assume that each member of the multi-cast tree maintains a local view of the multi- 5 The Backbone Layers cast tree rooted at itself in addition to a local view of The backbone layers represent the back-end and support the network. When the upper layer on some node wants component of the collaborative multimedia system. These to join the group, the Multi-cast Joiner Module decides layers do not contribute directly to the distributed mulwhether it is possible to add a new member based on the timedia applications, rather, they provide the essential current status of the network. If it is possible, it informs primitives needed by the di erent layers to carry out their the multi-cast joiners on each member and intermediate main functions and provide the expected level of abstracnode of its tree. Each member node recomputes the multi- tion. In our layered architecture, we have two backbone cast tree rooted at itself and informs the other members layers, namely the database backbone and the computational backbone.
CLOSED +N_OPEN
+N_CLOSE
+N_MDESTROY
+N_MCREATE +-N_JOIN
ACCEPTING
+N_ACCEPT
WAIT
OPEN
+-N_MREFUSE +-N_CONNECT +-N_REFUSE
+N_DISJOIN -N_MHANGUP
WAIT
+-N_MEST
+R_CONNECT +--N_EST -N_HANGUP +N_DISCONNECT CONNECTED JOINED -send
+recv +N_SEND
SENDING
+recv
-send
-N_DATA
+N_SEND RECEIVING
-N_DATA
SENDING
RECEIVING
Figure 9: FSM for the Interface
5.1 The Computational Backbone It is evident from the description of the layers that a
great deal of computational e ort is needed to perform the prescribed function of each layer. The primary function of computational backbone is to provide the algorithms, primitives, computational tools and processing power for the other layers to perform computationally expensive functions. Primitives provided by the computational backbone can be mathematical primitives, such as square root, cosine, sine, ..etc. It can include list processing primitives such as sorting, obtaining the maximum, the minimum, the variance, and the mean of lists. It can include special array processors for mathematical computation and matrix processing, mathematical tables, special functions libraries, such as error function and gamma function. To illustrate the importance of the computational backbone, consider the problem of resource allocation presented in [13]. In this paper, The con guration and synchronization layer is required to employ the fair resource allocation algorithm to allocate bandwidth to di erent competing sessions such that the degradation of the QoS is evenly distributed among the sessions. This algorithm requires solving a nonlinear programming problem which can be computationally expensive. One of the services provided by the computational backbone is to provide the primitives and possibly the algorithms and libraries to quickly solve such problems.
5.2 The Database Backbone The second backbone layer is the database backbone. The
primary task of this layer is to provide sucient storage and ecient access to various data items used by the di erent functional layers in the architecture. The functions related to this layer include naming of objects, name resolution, access methods, and address resolution of distributed objects. Issues related to location transparency, and protocols for inter-server communication and synchronization
are also treated in this layer. For example, there is no central authority, but location of documents and the user interface are relatively uniform across the world. WWW protocols, such as URL's (Uniform Resource Locators), HTML (HyperText Markup Language), and HTTP (HyperText Transfer Protocol), are examples of services provided by the database backbone Another important services provided by this layer include maintaining raw data, providing indexing and meta data to allow fast access and maintain a database of multimedia documents in a abstract forms such as OCPN [14]. Global directories are used to store the above meta-data. This meta-data should be accessible to distributed local sites and have unambiguous semantics. Part of this directory may be located centrally, and parts may be distributed among the di erent sites. Another issue treated in this layer is the replication of such meta-data. Replication introduces access eciencies but at the same time space in-eciencies, as well as update diculties. Finally, this layer also handles mechanisms for deadlock avoidance among di erent sites.
6In thisConclusion paper, we presented an architectural framework
for collaborative multimedia systems. The architecture is composed of multiple layers, each provides a level of abstraction to the higher layer. In addition, each layer consists of independent functional units that communicate through a standard framework of messages. The main advantage of this approach is facilitating the independent implementation of each layer while maintaining compatibility and portability among a broad range of platforms. The proposed architecture can be a foundation for a broad range of multimedia research.
References
[1] E. A. Fox, \Advances in interactive digital multimedia systems," IEEE Computer, vol. 24, no. 10, pp. 9{ 21, October 1991. [2] P. Za ropulo, H. C. West, H. Rudin, D. D. Cowan, and D. Brand, \Protocol analysis and synthesis using a state transition model," in Computer Network Architecture and Protocols (P. E. Green, ed.), ch. 24, pp. 645{669, Plenum Press, 1982. [3] S. A. Scrivener and S. Clark, \Introducing ComputerSupported Coooperative Work," in ComputerSupported Co-operative Work (S. A. Scrivener, ed.), pp. 20{38, Avebury Technical, 1994. [4] H. P. Dommel and J. J. Garcia-Luna-Aceves, \Floor control for networked multimedia applications," in ACM SIGCOMM'95 Middleware Workshop, (Cambridge, MA), ACM, August 1995. [5] E. M. Schooler, \Conferencing and Collaborative Computing," Multimedia Systems, vol. 4, pp. 210{ 225, October 1996. [6] S. Ramanathan and P. Rangan, \Feedback techniques for intra-media continuity and inter-media synchro-
[7] [8]
[9] [10] [11] [12]
[13]
[14]
nization in distributed multimedia systems," The Computer Journal, March 1993. T. Little and A. Ghafoor, \Multimedia synchronization protocols for broadband integrated services," IEEE Journal on Selected Areas in Communications, vol. 9, pp. 1368{1382, December 1991. R. Barden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, \Resource ReSerVation Protocol (RSVP) Version 1 Functional Speci cations." Request For Comments 2205, September 1997. http://www.cis.ohiostate.edu/htbin/rfc/rfc2205.html. C. Hedrick, \Routing information protocol (RIP)." Request For Comments 1058, June 1988. D. Denning, Cryptography and Data Security. Addison-Wesley Publishing Company, 1982. R. E. Blahut, Theory and practice of error control codes. Addison-Wesley Pub. Co., 1984. A. A. Lazar, K.-S. Lim, and F. Marconcini, \Realizing a foundation for programmability of atm networks with the binding architecture," IEEE Journal on Selected Areas in Communications, vol. 14, pp. 1214{ 1234, September 1996. M. Woo, N. U. Qazi, and A. Ghafoor, \A synchronization framework for communication of preorchestrated multimedia information," IEEE Network Magazine, vol. 8, no. 1, pp. 52{61, January/ February 1994. T. Little and A. Ghafoor, \Synchronization and storage models for multimedia objects," IEEE Journal on Selected Areas in Communications, vol. 8, pp. 413{ 427, April 1990.
Table 6: Speci cation of the Interface Module Transition
Input Message
From
+N OPEN
N OPEN
Upper Layer
+N CLOSE
Output Message
N CLOSE
To
Upper Layer
+N MCREATEN MCREATE Upper Layer +N MCREATEN MDESTROY Upper Layer +N ACCEPT N ACCEPT
Upper Layer
Semantics Request a Service Access Point Disconnect upper layer from Network Layer Create a multi-cast group Destroy an existing a multi-cast group Upper layer ready to accept connections
+{ Upper N CONNECTN CONNECT Layer
Route VC Connect Manager
Connect to a remote machine
Route Manager Route Manager
N REFUSE Upper Layer
Connection to remote node refused Connection to remote node established Connection to remote node broken Break connection to remote machine
+{ N REFUSE
VC-Fail VCSuccess
+{N EST { N HANGUP
N EST
Upper Layer
N HANGUP Upper Layer
Upper +N DISCONNECT N DISCONNECT Layer N JOIN
Upper Layer
+{ N MREFUSE MG Fail
MultiCast Joiner Route Manager
+{N JOIN
+{N MEST MG Success { N MHANGUP +N DISJOIN N DISJOIN +N SEND
N SEND
{N DATA
Join a multi-cast group
N MREFUSE Upper Layer
N MHANGUP Upper Layer
Connection to remote node refused Joining the multi-cast group is successful Membership to multi-cast group broken Remove membership from a multi-cast group Send data to remote node or multi-cast group
Data Handler
Send the data to the data handler
N MEST
Upper Layer send
recv
Upper Layer
Upper Layer
{send {recv
MultiCast Joiner
N JOIN
Data Handler N DATA
Upper Layer
Inform Interface that data is received Data received from remote node or multi-cast group
