1. A Framework for Distributed Multimedia Applications. based on CORBA and ... services networks such as Asynchronous Transfer Mode (ATM) networks and ...
A Framework for Distributed Multimedia Applications based on CORBA and Integrated Services Networks Ph.D. Project Author:
Frank Siqueira, M.Sc.
Supervisor: Vinny Cahill, Ph.D. Institution:
Distributed Systems Group Department of Computer Science Trinity College Dublin
1. Introduction This report describes the main issues arising in the design of a distributed multimedia framework offering high-level abstractions for dealing with continuous media in open systems. As a result of this preliminary investigation we have defined the main characteristics of a framework that deals with the main problems found in distributed multimedia systems concerning synchronisation and quality of service (QoS) constraints. Our preliminary studies have resulted in the definition of a distributed multimedia framework based on a set of widely accepted standards for distributed object computing. The proposed framework adopts the Common Object Request Broker Architecture (CORBA) [OMG 96] and its system services as a basis for the transmission of control and media data. At application level, the framework will allow the specification of endto-end QoS requirements, translating the associated high-level QoS requirements into network-level configuration parameters. In the definition of the distributed multimedia framework, we consider the advances in network technology provided by integrated services networks such as Asynchronous Transfer Mode (ATM) networks and the new generation of Internet protocols, which offer support for multipoint communication and control and management of network resources. The remaining of this report is structured as follows. Section 2 presents the main requirements of distributed multimedia applications. The current technology suitable for distributed multimedia is described in section 3. In section 4, the framework for distributed multimedia is introduced, and section 5 gives examples of use of the proposed framework to build multimedia applications. Section 6 presents other proposals of frameworks and architectures for distributed multimedia, and section 7 compares these proposals with the distributed multimedia framework described by this document. The conclusions are drawn in section 8, together with the description of the work to be developed during the continuity of this project.
2. Requirements of Distributed Multimedia Applications Distributed multimedia applications have well-defined requirements based on the characteristics of the kind of media that is to be transmitted. Guaranteeing that these requirements will be met demands the reservation of computational and network resources. In the following sections we describe the requirements of different kinds of 1
media and the impact on the system caused by the deployment of distributed multimedia applications, ranging from the abstractions necessary at the application programmers’ level to the required lower-level network services. 2.1 Continuous Media Requirements Interactions between computers and other processor-based equipment are based on the exchange of data represented by electrical signals. This data follows a well-defined encoding scheme that represents some kind of information (e.g. an electronic mail message encoded using the ASCII character set or an image encoded according to the JPEG standard). The primary kind of information exchanged between processor-based machines is encoded computational data. The required bandwidth depends on the nature of the task to be accomplished, ranging from a couple of bits per second in case of simple sensors, to quite large volumes of data if we consider a world-wide banking system or a massively distributed file system. The acceptable delay is also related to the application, being for example very low in manufacturing and control systems and relaxed in an airline reservation system or an FTP session. The traffic is usually in bursts and the timing relation does not normally need to be reconstructed at the destination. The reliability of data is generally a critical factor in all these systems. However, with the increasing interest on the use of other kinds of media in computing devices, the usual transmission mechanisms adopted for data transmission have been shown to be unsuitable. The unsuitability derives from the distinct characteristics of this new category of media, known as continuous media. Continuous media can be defined as information that is continuously flowing after the establishment of a connection between a source and a destination. Continuous media have an implied rate of exhibition that has to be followed otherwise the integrity of the media is destroyed, i.e. the information which was intended to be presented can be lost or misunderstood. This contrasts with the usual approach adopted for computational data in which the information is usually retrieved and delivered upon request. This kind of media does not have an implicit temporal dimension, and is also called discrete media. The main requirements of different kinds of continuous media can be classified according to the following parameters: •
Bandwidth required;
•
Acceptable end-to-end transmission delay and delay variation (jitter);
•
Transmission reliability (data loss);
•
Distribution of traffic during time (burstiness or bit-rate distribution);
•
Importance of keeping the original timing relation during reproduction of media.
In the following paragraphs we analyse different classes of media according to these parameters. Audio. Audio is usually encoded as a constant bit-rate (CBR) signal in the communication systems currently available. However, digital techniques have been adopted to allow compression of audio with very low loss of quality, resulting in variable bit-rate (VBR) traffic. Compression techniques based on predictability are 2
difficult to apply for audio, so that compression algorithms usually have a lower efficiency if compared with video. The reproduction of audio with reasonable quality is basically related to the sampling rate and the number of bits used to represent the signal in a digital stream. The frequency range is limited by the capacity of the human ear. Furthermore, the original timing relationship observed during the generation of the sound must be reproduced at the destination. Voice. The human voice requires low bandwidth when compared with real audio because of its limited frequency range and the low sampling rate necessary for its transmission. In addition, voice media is sensitive to delay and delay variations, but a delayed sample may be discarded without serious loss for the comprehension of the listener. Besides the lower bandwidth necessary, the traffic characteristics are very similar to the audio signal. Voice can also be encoded as CBR or VBR signals, and compression is usually more efficient than for audio because of the presence of silence periods. Video. A video signal can be transmitted in analogue form with constant bit rate or digitally, possibly compressed, resulting in a variable bit rate flow. The bandwidth required is very high if compared with other sorts of media, and increases considerably when slightly better quality is desired. If we consider the capacity of the human eye, a rate of 30 frames per second is sufficient to allow a comfortable sensation of movement. The loss of one frame in a long sequence usually is not perceptible, and delayed frames need not be exhibited. A low delay variation is tolerable, and the reconstruction of source time during rendering must be taken into account. Table 1 provides a comparison of the bandwidth required by typical encoding schemes of different classes of continuous media. Media Description Bandwidth (in bits per second) Voice Phone quality (4 bits/sample; 8 kHz sample freq.) 32 Kbps High quality (8 bits/sample; 8 kHz sample freq.) 64 Kbps Audio CD quality (16 bits/sample; 44.1 kHz sample freq.) 1.4 Mbps MPEG audio with aprox. CD quality 200 to 300 Kbps Video VHS quality (352x240pix;24bits/pix; 30fr/s) 60 Mbps MPEG video with aprox. VHS quality 1.5 to 2 Mbps Pal/Secam quality (544x480pix; 24bits/pix; 30fr/s) 188 Mbps MPEG video with aprox. Pal/Secam quality 4 to 6 Mbps HDTV quality (~1200 lines; 24bits/pix; 30fr/s) 1 Gbps MPEG video with aprox. HTDV quality 20 to 60 Mbps
Table 1 - Typical Bandwidth of Different Classes of Continuous Media 2.2 Architectural (Middleware) Issues A large set of requirements has to be addressed by the middleware in order to support applications that use continuous media. The deployment of a distributed computing environment above a network with sufficient bandwidth does not guarantee that an application will behave as expected. The services available at the network level have to be fine-tuneable at the application level in order to allow specific requirements to be addressed by the system. This does not mean that network-level details have to be accessible at application level, introducing more complexity to be dealt with by the programmer. Instead, we consider that new abstractions and services will be provided to allow applications to easily control and manage the use of network resources, allowing 3
the guarantee of availability of bandwidth and limited communication delays, for example. High-Level Abstractions for Continuous Media Support. It is important to notice that currently available distributed computing architectures do not have abstractions to represent a continuous flow of data between two or more elements. The usual approach to interaction between distributed objects through synchronous method calls is not suitable for representing continuous media. The possible approaches – represent it as a single call or as a sequence of invocations – cannot be adopted because of implicit temporal requirements that are not handled. A continuous flow of data (e.g. the output of a media device) cannot be represented by a single method invocation because of its unbounded nature. On the other hand, it is neither easy nor natural from the programmer's point of view to associate QoS and temporal requirements to sequences of invocations. The introduction of stream abstractions in the communication model is the usual approach to allow the definition of continuous flows with associated QoS requirements. The following approaches have been adopted in the literature to introduce the stream abstraction in distributed environments: •
the extension of languages to support a new stream type; or
•
the introduction of a new abstraction in the environment to encapsulate the media stream.
In addition, the adaptation of the communication service is conceivable through the adoption of one of the following solutions: •
the extension of communication framework to allow the definition of media streams; or
•
the adoption of an independent protocol to transfer continuous media.
The possible solutions will be considered in the definition of the distributed multimedia framework presented in Section 4. Synchronisation Mechanisms. Three different kinds of synchronisation can be identified as necessary in distributed multimedia systems: •
Intra-media synchronisation: related to the constraints present in the exhibition of one specific media respecting the timing relationship imposed to this flow, and regarding the relation between the exhibition of the same media in different receivers.
•
Inter-media synchronisation: considers the temporal relations between different media exhibited simultaneously in the same receiver or in different media clients.
•
Event synchronisation: concerned with events generated by the system that influence the exhibition of media in some way.
An event notification service is an example of a suitable mechanism for implementing synchronisation in distributed object computing systems, if provided a mapping between intra- and inter-media synchronisation requirements and events visible through the event notification service. The issued events can be used by media clients and supervisors to control the exhibition of continuous media in distributed multimedia applications. 4
Specification of Quality of Service. The provision of mechanisms to specify quality of service requirements and map them to network-level mechanisms is a key necessity in a distributed multimedia environment. The desired behaviour of the exhibition of media at application level must reflect on a limited set of parameters which have to influence the communication environment without imposing limitations on the use of the available network resources. The specification of quality of service relies on a subsystem service responsible for providing and controlling the corresponding resources. The management of these resources implies interaction with distributed network hardware. Guarantees must be provided both in sender and receiver machines as well as in switches and intermediary networks linking them. A way to map high-level requirements to the reservation of network resources also has to be defined. This topic will be discussed in section 2.3. Group Communication. Most multimedia applications have a group of users involved instead of a single user. The less expensive and more efficient way to implement group communications consists in using multicast mechanisms, which are sometimes supported at network level but are not available to the application because of the inadequacy of the middleware software. An efficient framework for distributed multimedia applications must provide support for group communication, allowing operations to establish multiple connections, join and leave media sessions, and supervise the flow of data in the multiple receivers of media. 2.3 Network (Low-Level) Issues It is necessary to provide a mapping for the requirements described above at network level. Most of these requirements can be only addressed by recent proposals in the field of computer networks. Control and Management of Connections or Flows of Packets. The natural way to support streams associated to QoS requirements by a higher level architecture is to use network connections or flows of packets directly at the network level. The creation and destruction of streams has to result at network level on the establishment of a connection in connection-oriented networks or the definition of flows of packets in connectionless networks. Other operations for control and management of streams have to be mapped at network level as operations for dealing with connections and flows of packets. Control of QoS Requirements. Quality of service requirements are usually specified at network level during the connection establishment in connection-oriented networks, or during the definition of a flow of packets in connectionless networks. A way to map application level requirements to the corresponding channel parameters must be provided by any framework for multimedia applications. The mapping cannot be directly tied to a network architecture. Instead, it has to provide support for the available protocols and for other alternatives that may be proposed in the future. The architecture must also provide a way to use the currently available best-effort networks during a transitory period without guarantee of QoS, but with verification of the fulfilment of delays on the network and consequent reporting of undesired behaviour to the application. 5
Multicast Support at Network Level. Support for multicast connections should be provided at network level to allow communication with groups of objects. In the case of networks without multicast support, an efficient way to map groups of objects onto multiple point-to-point connections must be provided, without implying side effects on QoS control and specification.
3. Current Technology In the next items the technology currently available for the construction of multimedia applications is described. Several state-of-the-art solutions are depicted, ranging from the new proposals for network service to the standards for distributed multimedia. 3.1 Broadband Networks The increasing complexity of network applications, ranging from real-time audio and video transmission to conferencing systems, is driving constant improvement in the bandwidth supported by local and wide area networks. The heavy investment in broadband networks, which has been observed in the last ten years, resulted in the adoption of proprietary solutions, since the technology is not completely standardised. The definition and adoption of an international standard is an urgent necessity to allow the continuous growth of available bandwidth without the spread of incompatible technologies. ATM. Asynchronous Transfer Mode (no, neither automated teller machines nor another terrible mistake!) is a communications standard proposed by the Telecommunication Standardisation Section of the International Telecommunications Union (ITU-T) as the transport mode for the Broadband Integrated Services Digital Network (B-ISDN). The standardisation of ATM networks is being carried out by the ITU-T in parallel with the ATM Forum. The ITU (formerly called CCITT) comprises standardisation agencies from more than 180 countries. New standards are evaluated each four years, and approved only if unanimity is achieved. On the other hand, the ATM Forum is an organisation composed of more than 800 companies representing all sectors of the communications and computer industries, as well as a number of government agencies, research institutes and end-users. Its main objective is to accelerate the use of ATM through a rapid convergence of interoperability specifications, establishing solutions to be adopted by member companies while existing standards are absent, incomplete, or considered inappropriate. ATM networks [Black 95] [Goralski 95] [Onvural 95] aim to integrate traffic with different flow characteristics and service requirements. The type of traffic to be supported by ATM networks ranges from real-time data such as voice and highresolution video, which can tolerate loss of data but not delay, to non-real-time traffic such as computer data and file transfer, which can tolerate delay but not loss of information. The flow can vary from constant bit rate (CBR) as required by non-compressed audio or video, to the bursts of data typical of computer systems where the average arrival time between bursts may be quite large and randomly distributed. The main idea behind ATM is to transmit small data packets (ATM cells) asynchronously without error recovery at the network level. Each ATM cell consists of 6
53 bytes of data, of which 5 bytes are used by the ATM header. The adoption of an asynchronous approach allows better performance in the presence of bursts of data with low latency. Error correction and data recovery can be implemented at higher levels if necessary, according to the characteristics of the data being transmitted.
Plane Management Layer Management Control Plane User Plane High-Level Layers High-Level Layers ATM Adaptation Layer ATM Adaptation Layer ATM Layer Physical Layer Figure 1 – The ATM Architecture The transmission of data is completely connection-oriented. ATM channels are identified by a channel number specified in the ATM header, and composed of a Virtual Channel Identifier (VCI) and a Virtual Path Identifier (VPI). During the connection establishment process, the application can specify the desired QoS based on parameters such as maximum number of cells per second, statistical variation of the volume of data being transmitted, maximum end-to-end delay, and maximum jitter allowed. A connection is refused when the network cannot support the required QoS level. ATM supports point-to-multipoint and multipoint-to-multipoint connections in addition to point-to-point communications. Members – senders or receivers – can be added dynamically to multipoint connections using the signalling protocol. It is important to notice that communication is always unidirectional in multicast connections (i.e., data flows from senders to receivers only), and traffic characteristics and service requirements (QoS) must be the same for every member. Some manufacturers of ATM equipment do not provide full support for multipoint communication. There is no defined mapping between ATM and the 7-layered OSI Reference Model. The ATM Reference Model goes beyond the OSI model introducing the concept of planes subdivided in layers in a 3-dimensional structure. The use of planes allows the representation of features such as control and management in parallel with the data transfer. The structure of the ATM model is shown in Figure 1 and described below. The three planes defined by the ATM Reference Model are: •
User Plane: for transporting user information.
•
Control Plane: deals with channel control, connection control, and signalling information.
•
Management Plane: implements layer management and plane management.
The layers are divided as follows: •
Physical Layer: performs bit-level functions, adapting the cell-based approach to the transmission medium. Subdivided into : 7
•
•
•
Physical Medium (PM): contains only the medium dependent functions. It provides bit transmission and alignment, performs line coding and also electrical/optical conversion when necessary. PM layers for optical fibre, and coaxial and twisted pair cables are defined in the reference model. This layer also includes bit-timing functions such as insertion and extraction of timing information.
•
Transmission Convergence (TC): takes care of generation, recovery and adaptation of transmission frames, adapting the cell flow according to the transmission system. TC also performs the cell delineation function, enabling the receiver to recover the cell boundaries, and calculates and verifies the header checksum (HEC), allowing correction of header errors. TC also inserts idle cells in the medium in order to adapt the rate of the ATM cells to the capacity of the transmission system, and suppresses all idle cells received.
ATM Layer: is the core of the ATM network architecture. This layer performs the following functions: •
Cell header generation/extraction: adds the appropriate ATM cell header (except for the HEC value) to the cell received from the ATM adaptation layer (AAL) in the transmit direction, and does the opposite (i.e., removes the cell header) in the receive direction. Only cell data fields are passed to the AAL.
•
Cell multiplexing and demultiplexing: multiplexes cells from individual virtual paths (VPs) and virtual channels (VCs) into a single cell stream in the transmit direction. It divides the arriving cell stream into individual cell flows (VC or VP) in the receive direction.
•
VPI and VCI translation: performed at the ATM switching and/or cross-connect nodes. The values of VPI and VCI fields of each incoming cell are translated into new VPI and VCI values in the outgoing cell according to the characteristics and the state of the ATM switch.
•
Generic Flow Control (GFC): supports control of the ATM traffic flow in a customer network. This is defined only at the UNI (user-to-network interface); GFC does not exist in the NNI (network-to-network interface) cell.
ATM Adaptation Layer (AAL): performs the adaptation of higher layer protocols. AAL is divided into two sub-layers: •
Segmentation and Reassembly (SAR): performs segmentation of the higher layer packets of data into a suitable form for the payload of the ATM cells of a virtual connection; at the receive side, it reassembles the contents of the cells of a virtual connection into data units to be delivered to the higher layers.
•
Convergence Sublayer (CS): performs message identification and time/clock recovery. This layer is further divided into a Common Part Convergence Sublayer (CPCS) and a Service Specific Convergence Sublayer (SSCS).
Four classes of service (namely A, B, C and D) were originally identified by the ITU-T, each one providing a data flow appropriate to a different set of applications with similar traffic characteristics. For each class of service a corresponding adaptation layer (AAL1 for class A traffic, AAL2 for class B, and so on) was defined. Table 1 summarises the original relationship between classes and AAL types. 8
Class of Service A B C D Original AAL AAL1 AAL2 AAL3 AAL4 Timing Relation Preserved Not Preserved Bit Rate Constant Variable Connection Mode Connection Oriented Connectionless Original Circuit emulation, Compressed Virtual circuit Datagram service, Target non-compressed audio and services (X.25, IP over ATM, Applications audio and video. video. Frame Relay, etc.). LAN emulation.
Table 2 - Original ATM Classes of Service and Adaptation Layers However, during the specification process it was recognised that this approach needed to be modified, and new AAL types and classes of traffic were defined, and different combinations between them were allowed when appropriate. AAL 3 and 4 were merged because of their similarities, giving rise to AAL3/4. Nevertheless, the 4-byte per cell overhead required by the headers and trailers necessary to provide connectionless service multiplexed over a single ATM channel constrained AAL3/4 adoption to class D services, and AAL5 was created to provide a more efficient interface for class C services. AAL5 is also used by the ATM signalling protocol (ITU-T Q.2931) and by a new class Y, known as available bit-rate (ABR), which is suitable for delay-tolerant applications. A class X, or unassigned bit-rate (UBR), was also introduced for provision of cell-relay service for applications with minimum QoS requirements, i.e., delay-tolerant and subject to cell loss. Class X employs a null AAL (also known as AAL0) to access the cell-relay service provided by the ATM layer. Class B service is not currently available, because there is no standard or vendorspecific proposal for AAL2. Class A B C Y Q.2931 X D AAL AAL1 AAL2 AAL5 AAL0 AAL3/4 Time Preserved Not Preserved Bit Rate Constant Variable Conn. Mode Connection Oriented Conn-less Examples of Circuit Compressed Conn-orient Available Conn-less Signalling Cell-relay Application emulation audio/video services Bit Rate services
Table 3 - Resulting ATM Classes of Service and Adaptation Layers ATM is a technology under development. Despite not being completely standardised, this technology is evolving rapidly and being widely accepted in the computer networks market, with applications in both local and wide area networks. A large number of vendors are providing ATM hardware, with a reasonable degree of interoperability between equipment from different vendors. 3.2 Internet Protocols The next version of the Internet suite of protocols, known as Internet Next Generation, provides resource reservation and guarantees end-to-end QoS at application level. The work currently being carried out by the IETF (Internet Engineering Task Force) is orthogonal to the subnetwork-specific solutions for broadband integrated services networks (such as ATM) because it targets the logical network. 9
APPLICATIONS
Application Level
RTSP
Transport Level
TCP
Network Level
ST-II
RTP
UDP IP
RSVP
SUB-NETWORK
Sub-Network Level
Figure 2 - Internet Next Generation Protocols All this effort to adapt the Internet to a new communication framework is being developed in parallel with the new version of the IP network protocol, known as IPng (next generation) or IPv6 (version 6) [Deering 95] [Hinden 95] [Conta 95]. IPng is designed to support a larger set of addresses (128 bits instead of 32) while maintaining compatibility with the current version. Additionally, IPng has the following characteristics: •
IP packets can be associated to a flow through the use of a field in the IP header;
•
multicast communication is improved through the addition of a scope definition field in the IP header, limiting the geographical amplitude of multicast messages;
•
a new communication paradigm, called anycast, is introduced; anycast supports groups of receivers to which messages are sent only to the nearest member of the group;
•
packet options are implemented in a more flexible and extensible way, using multiple option fields outside the area of the IP header; and
•
support for authentication and QoS specification is allowed through the definition of traffic flows with particular requirements and characteristics.
The new suite of Internet protocols being developed by the IETF is illustrated by Figure 2. At the network layer, the IETF has two parallel activities underway. The first is addressing the provision of a Stream Transport Protocol (ST-II). The alternative activity is based on a Resource Reservation Protocol (RSVP) running over IP. Both solutions support multicast communication, resource reservation, bandwidth management and QoS specification, but the approach adopted in their design differs in several fundamental points. ST-II [Delgrossi 95] is a connection-oriented network protocol, designed to coexist with IP, which allows resource reservation started by the origin of the flow. New receivers interested in participating in an ongoing connection have to contact the origin to request their inclusion. An associated control message protocol, SCMP, is responsible for initiating and modifying connections, allowing resource specifications to be changed to fulfil the requirements of a specific receiver. The main disadvantage of the approach adopted by ST-II is related to the bottleneck imposed by the excess of tasks assigned to the source of the media, which constrains the scaling of receiver groups.
10
On the other hand, RSVP [Braden 96] is based on the establishment of flows over a connectionless network service (IP version 4 or 6), allowing reservation of resources for a specific flow when necessary. The multipoint communication service is designed to scale to very large groups through the use of flow specifications defined by receivers. Each receiver interested in a communication flow enters the corresponding multipoint group and waits for a path message that describes the composition of the flow. The receiver then decides in which part of the flow it is interested (e.g. only the black and white component of a coloured video flow) and generates a filter. A flow specification (flowspec) describing the required characteristics of the flow is also generated by the receiver. It then arranges both the filter and the flowspec in a reservation message, which is propagated periodically in the direction of each individual origin of the flow. The constant refreshing of the reservation messages results in soft state information being stored by the routers along the path, what is more appropriate to the original stateless characteristics of the Internet. At transport level, the usual Internet transport layers, TCP and UDP, are being adapted to take advantage of the new characteristics of IPng. Furthermore, a new protocol called Real-Time Protocol (RTP) has been proposed. RTP [Schulzrinne 96] provides higher level services such as framing, multiplexing and demultiplexing, encoding, synchronisation, error detection and encryption. RTP can make use of the other transport protocols (TCP or UDP) or access directly the network layer (IP or ST-II). A transport control protocol named RTCP is responsible for group management, connection control, and QoS monitoring. An application protocol developed by Netscape Corporation and Progressive Networks was accepted by IETF as a draft standard. The Real-Time Streaming Protocol (RTSP) [Rao 96] offers a “WWW-based and HTTP-friendly” interface to allow on-demand delivery of real-time media over the Internet. RTSP is built on top of the currently available transport protocols (RTP, TCP and UDP). The protocol provides mechanisms to request delivery of real-time data, specify the transport layer to be used and the destination for the delivery, request information about the encoding format, control the flow of data through the stream, and to access portions of data when applicable (i.e., in case of recorded media). With the introduction of the described protocols, the IETF intends to provide a complete suite of mechanisms for the transmission of continuous media and real-time data through the Internet. 3.3 Distributed Object Computing In the last few years the development of software, which was typically based on the use of structured design and procedural languages, is rapidly migrating to the adoption of object-oriented design and programming techniques. The adoption of object-based approaches in distributed computing systems was a natural evolution, and was reinforced by the availability of standards proposed by the Object Management Group (OMG), a consortium created by software vendors, developers and end-users to promote object technology for the development of distributed computing systems. In this section work we describe the set of standards for distributed object computing defined by OMG in its Object Management Architecture [OMG 92].
11
Client
IDL Stubs
Dynamic Invocation Interface
Object Implementation
IDL Skeletons
ORB Interface
Dynamic Skeletons
Object Adapter
ORB Core Figure 3 – The CORBA Architecture CORBA. The Common Object Request Broker Architecture [OMG 96] is a framework of standards and concepts for open systems. In this architecture, methods of remote objects can be invoked transparently in a distributed and heterogeneous environment through an ORB (Object Request Broker). The CORBA specification establishes the role of each ORB component in the environment and defines its interfaces. CORBA interfaces are specified as a layer masking differences between distinct lower-level systems. The CORBA components are shown in Figure 3. In the CORBA environment, each object implementation has its interface specified in IDL (Interface Definition Language). Remote method invocations are issued by clients calling methods in local stub objects that are generated by the IDL compiler and have the same interface as the corresponding remote objects. Alternatively, the client can build the request using the Dynamic Invocation Interface (DII). The ORB Core transmits the request and transfers the control to the object implementation (i.e., the server) using an IDL skeleton and the corresponding object adapter. The object implementation is unaware of the kind of CORBA interface used by the client to issue the request. Dynamic skeletons allow servers to receive invocations on any object, even if this object was not defined at compile time. The dynamic skeleton interface (DSI) is usually adopted to build gateways. When the client and the object implementation are located in ORBs that use different protocols for remote communication, a communication protocol called IIOP (Internet Inter-ORB Protocol) is used to allow interoperability. The ORB Interface offers some general-purpose services to CORBA objects through a well-defined interface. Object implementations can also use services provided by their corresponding object adapters. OMG specifies the interfaces of a general-purpose Basic Object Adapter (BOA) which covers the requisites of a wide range of object systems. CORBAservices. The CORBA Services Specification [OMG 95] intends to provide the CORBA architecture with a set of standard mechanisms that are often necessary in a distributed environment. In particular, the following major services of vital importance to distributed systems were proposed by OMG: •
a Naming Service;
•
a Life Cycle Service; 12
•
an Event Service;
•
a Transaction Service; and
•
a Security Service.
A naming service allows components to discover other components in the distributed environment with which they can interact and execute cooperative tasks. It is basically a location service that associates identifiers to handlers that provide a way to contact the desired component in the distributed system. The CORBA Naming Service binds names, inserted into hierarchically organised name contexts, to CORBA objects. A life cycle service is basically a configuration service. It defines services and conventions for creating, deleting, copying and moving components in a distributed system. The CORBA Life Cycle Service defines the interface to a Factory object that allows the creation of objects using factories, as well as a LifeCycleObject interface with remove, copy, and move operations. An event service implements a decoupled communication model, based on the publish/subscribe paradigm. In this communication model, one or more publishers (or suppliers) can send messages related to a specific topic, while a group of subscribers (or consumers) receive the messages asynchronously. Through this mechanism, suppliers can generate events without knowing the identities of consumers, and consumers can receive events without knowing who supplied them. In the CORBA Event Service there are two approaches for initiating communication between consumers and suppliers: •
In the Push Model, the supplier takes the initiative of starting the communication;
•
In the Pull Model, the consumer requests event data from the supplier.
In addition, one of two different approaches may be adopted: •
In the Generic approach, a generic data structure carries the information related to events; communication is provided through a generic interface that supports push and pull operations.
•
In the Typed approach, IDL parameters carry the event data; communication is via CORBA IDL operations.
The CORBA Event Service provides an alternative to the traditional invocation mechanism based on method calls implemented by CORBA objects. A transaction service organises interactions between distributed objects establishing commitment points and delimiting transactions. The CORBA transaction service supports multiple transaction models and allows interoperability between different network architectures and programming models. A security service controls identification of principals (humans or software components) in order to verify that they have authorisation to execute a requested action. The CORBA security service allows identification and authentication of distributed objects and implements access control, verifying if specific principals have authorisation for calling a particular operation (method) of an object. Furthermore, it allows secure 13
communication over insecure network links, with protection of the integrity and confidentiality of messages transferred between objects. In fact, a complete set of services useful in some specific applications was defined by OMG. The remaining services are: •
Time Service: supplies time information and allows the definition of periodic calls.
•
Licensing Service: controls the utilisation of specific objects in the distributed system, inhibiting improper use of intellectual property.
•
Properties Service: provides the ability to dynamically associate properties (any IDL value) with objects.
•
Relationship Service: allows the definition of the role performed by CORBA objects in a relationship.
•
Query Service: allows users and objects to invoke query operations on collections of objects.
•
Persistency Service: provides mechanisms used for retaining and maintaining the state of persistent objects.
•
Concurrency Control: allows the co-ordination of multiple access to shared resources through the provision of several lock modes, and permits flexible resolution of access conflicts.
•
Externalisation Service: defines conventions and protocols for representing state information related to an object in the form of a stream of data, allowing this information to be stored or transferred to other locations.
3.4 Distributed Multimedia There is currently a major research effort being carried out on the development of distributed multimedia systems and platforms. Unfortunately, some projects do not adopt compatible solutions allowing them to deal with media in open systems. Standards for distributed multimedia, such as the proposals being developed by the International Multimedia Association (IMA) and by the Multimedia and Hypermedia Experts Group (MHEG) of the International Standardisation Organisation (ISO), have as their main purpose support for interaction in open environments, allowing co-operating components to generate and render multimedia sessions, using real-time and/or prerecorded media, and optimising the use of network and processing resources. However, the concepts behind these proposals of standards are completely distinct, and the target applications are also different. MSS. MSS [IMA 94] provides a set of recommended practices to facilitate crossplatform compatibility of multimedia data and applications. The MSS specification is being developed by the IMA. IMA members include the main software and hardware suppliers and consumers around the world. The proposed architecture provides an infrastructure for building interactive multimedia applications in distributed and heterogeneous computer systems, dealing with synchronisation and quality of service requirements. MSS is structured using an objectoriented approach, based on an underlying infrastructure built on top of CORBA and CORBAservices together with an independent Multimedia Stream Protocol, which supports the streaming of time-critical data. 14
Client Group Stream
Virtual Channel Virtual Device Stream
Stream Format Port
Virtual Device Format
Media Stream Protocol
Stream
Port
Figure 4 - Multimedia System Services Figure 4 shows the components present in the MSS architecture. The interfaces of these components are being standardised by the IMA, as is the Multimedia Stream Protocol. Every client in a MSS environment establishes a data flow through two virtual devices bound by a virtual connection. These components may be running local 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. Stream objects control the media position and the flow of data from/to the device. They can also provide an interface for controlling the synchronisation 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. The flow of media through the connection is controlled by a stream object. 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. 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. The MSS architecture defines a set of predefined classes of objects that are organised in an interface inheritance hierarchy. These classes, in addition to user-defined classes, may be used to build distributed multimedia applications. User-defined classes may be added to the architecture by inheriting the interface of MSS classes. MSS, as a reference model for design and programming of distributed multimedia applications, is targeted at complex, scaleable, extendible and interoperable applications running in an open environment.
15
MHEG. MHEG [Meyer-Boudnik 95] [Joseph 95] is a set of standards being developed by the ISO Multimedia and Hypermedia Experts Group to support the description of multimedia documents and distribution of interactive multimedia applications across heterogeneous platforms. MHEG aims to define the syntax and semantics for coding multimedia and hypermedia objects, using a set of object classes to build multimedia applications across minimalresource platforms. The applications are intended to reside on servers and be downloaded to clients when necessary. The applications consist mainly of declarative code, allowing MHEG applications to run on any MHEG-compliant platform. The client needs a runtime environment to interpret the code and execute the application. MHEG is not a multimedia document-processing format. Instead, it provides rules for the structure of multimedia objects, which permits the media objects themselves to be represented in any convenient form. MHEG objects, which may be textual information, graphics, video, audio, etc, may be classified in four types: •
Input object (i.e., a user control such as a button or menu)
•
Output object (e.g., graphics, audio visual display, text)
•
Interactive object (both input and output characteristics)
•
Hyperobject (input and output with links between them).
MHEG supports various synchronisation modes for presenting media objects, allowing the description of relationships between them. MHEG is targeted at interactive multimedia and hypermedia applications such as lowquality video on demand, news on demand, navigation, interactive home shopping, online textbooks and encyclopaedia. It is also suited for many of the interactive multimedia applications currently available on CD-ROM. MHEG can also be used as the data structuring standard for home entertainment interactive multimedia appliances.
4. A Framework for Distributed Multimedia Applications In this section we describe the main characteristics of a framework for the development and execution of distributed multimedia applications. The design process is based on the main requirements identified previously and using the state-of-the-art technology available. We define a main core for the framework and propose additional services and improvements to provide the desired environment for distributed multimedia. 4.1 Analysis of the Available Technology for Distributed Multimedia Section 2 described the requirements of distributed multimedia applications, while section 3 presented the technology currently available in the areas of integrated services networks, distributed object computing, and distributed multimedia systems. In this section we analyse how this technology can be used (and improved when necessary) to fulfil the requirements of a distributed multimedia environment.
16
Multimedia Application Control Data
Stream Data
Middleware Middleware TCP
RTP, etc.
IP Sub-Network
IPNG with RSVP, etc. Integrated Services Network
Figure 5 – Available Technology for Distributed Multimedia Applications First, we have to consider that two distinct kinds of data will be involved in a distributed multimedia application. The control information, which can tolerate some delay but has to be reliable, is considered non-real-time (or best-effort) data. This behaviour can be provided by using best-effort logical networks such as TCP/IP directly, or by adopting middleware for distributed computing implemented over TCP/IP. On the other hand, the encoded media, which is subject to different QoS requirements, is called real-time data. Logical networks based on TCP/IP are not suitable for the transmission of real-time stream data. This category of data delivery is available only through experimental or not completely standardised solutions at sub-network (ATM) or at logical network level (IPng with RSVP, RTP, etc.). Because of their short existence, these network protocols are not often supported by currently available middleware. Figure 5 shows a generic multimedia application with control and stream data, which can be structured according to one of the application models described in section 3.4. The remote communication in an application like this may use the network protocols available at the sub-layers directly, or may adopt a middleware platform that allows transparency regarding issues like remote communication and physical location of the partners. The figure shows that there is no support for stream data in the currently available middleware platforms. 4.2 The Adopted Core The two main guidelines considered during the first stages of the design of the framework for distributed multimedia applications are: •
the adoption of object-oriented programming techniques to support an efficient application development process; and
•
transparency from the programmer’s point of view, concerning the intrinsic distribution and heterogeneity of the target system.
To achieve these goals, distributed object-oriented middleware is considered the most suitable component to be used as the core of the framework being designed. In particular, we adopt the CORBA architecture to play the central role in the multimedia framework because of its efficiency as a programming architecture and execution environment, its high availability, and its wide acceptance as the standard for distributed object computing. The main communication paradigm in the CORBA architecture consists of a clientserver interaction model. This kind of interaction is not appropriate for every kind of application. 17
Stream Control
Partner 1 Input Device 1
Partner 2
Output Device 2
Output Device 1
Input Device 2
O Stream Adapter
R
Stream Adapter
B
Figure 6 – The Stream-Based Communication Mechanism Aiming to solve this limitation, OMG is incorporating new interaction models into the architecture. The ones of special interest for distributed multimedia are the notification service and the stream-based communication mechanism. 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 multimedia 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 besteffort data, and on the other hand expose 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 highlevel 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 [OMG 96b]. The streaming mechanism defines a group of abstractions to deal with stream data in multimedia systems, as illustrated by Figure 6. The abstractions are called multimedia devices, stream adapters, and stream control. Multimedia devices are software components that abstract multimedia hardware. A stream adapter transfers stream data through the network, getting data from and delivering data to multimedia 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 multimedia devices. The stream control is a normal CORBA object accessible remotely through the clientserver invocation scheme. It can be a remote object or can be located in the same address space as one of the multimedia 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. 18
The characteristics of a stream are described in IDL. Streams are composed of one or more flows of data, corresponding to IDL operations. The data frame associated with a flow is defined like a typed IDL parameter, and can go from the creator of a stream (the ‘A’ side) to the other side (the ‘B’ side) if it is an ‘in’ parameter. The frame is transferred in the opposite direction if it is declared as an ‘out’ parameter. A binding operation establishes a stream between two multimedia devices, defining the QoS parameters associated to the stream. Two binding semantics are allowed. The simple local binding uses the multimedia device and returns a stream control object. Besides, in the third party binding mechanism, a stream control object can bind two remote multimedia devices and keep the control over the data flow. With the introduction of the stream mechanism, the CORBA architecture becomes suitable for the provision of the communication services necessary for multimedia applications, and can be adopted as the common middleware for control and transfer of media as described in the item 4.1. The Notification Service. The notification service [OMG 97] is an extension to the CORBA event service that aims to provide a more flexible and efficient way to allow the notification of events occurring in the system, including the definition of delivery constraints for certain events. This novel mechanism, together with the event service, can be employed to implement, at application, level mechanisms to impose inter-stream synchronisation constraints. 4.3 Improvements and Additional Services In addition to the adoption of the CORBA architecture as the core of the proposed multimedia framework, we propose some improvements in the current implementations and additional services to allow the framework to provide the desired functionality for distributed multimedia applications. The proposed improvements and additions to the adopted core are the following: •
the implementation of the CORBA stream mechanism on several novel networklevel protocols with resource reservation capabilities and evaluation of their adequacy to different multimedia applications;
•
the definition of sets of application QoS parameters for different categories of multimedia applications as well as an algebra for translating application QoS parameters to network-level QoS parameters or resource reservat ion messages when applicable; and
•
the provision of a multimedia component hierarchy to facilitate the construction of distributed multimedia applications using the framework described previously.
These additions to the core architecture, including the stream mechanism, are totally feasible at application level. This fact assures that eventual modifications in the standard and in the support are unnecessary. It also assures that interoperation and backward compatibility will not be affected. Although, a multimedia application has to be executed on a platform (support and network) which provides the features requested by the distributed multimedia framework to present the desired behaviour at run-time.
19
4.4 Fulfilment of Requirements With the adoption of the CORBA architecture provided with the client-server and the stream interaction models as the core of the distributed multimedia framework, we give applications the ability to handle control data and stream data uniformly using 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.). The synchronisation mechanisms necessary in a multimedia system can be implemented at application level using: •
information carried in-band together with the stream data (i.e. timestamps) that allow the reconstruction of a media sequence by the receiver of the stream data (intra-stream synchronisation); and
•
events issued by the CORBA event service or by the notification service to establish synchronisation points between distinct video streams (inter-stream synchronisation and event synchronisation).
The application code is responsible for handling this information and rendering the media according to the related synchronisation requirements. The synchronisation cannot be executed at support level because the differences between the processing and rendering times of different media at application level have to be taken into account. The framework allows the provision of QoS requirements specified as application level parameters through the translation of these parameters into network QoS parameters or resource reservation messages, according to the underlying network protocol. Besides, the adoption of the CORBA stream mechanism together with network protocols with multicast capabilities allows transparent and efficient group communication. 4.5 Building Multimedia Applications with the Framework The development of multimedia applications is simplified by the adoption of the distributed framework described in the beginning of this section. The adoption of common middleware allows the exchange of control and media data transparently through the network. The application programmer does not have to deal with details related to the kind of network protocol being used, the location of sources and destinations of data, or even the QoS requirements at network level. Instead, the programmer uses high-level abstractions that hide the complexity, although allowing manipulation of their behaviour because of their application-level nature. The framework allows the programmer to construct a multimedia application using built-in classes of virtual devices and configuring them as necessary to provide the desired output quality (application QoS). These classes of virtual devices have to be implemented according to the target system and can be extensions to the classes provided by the framework. Implementations of the middleware platform over several different network protocols with QoS specification or resource reservation are provided in a way to make the framework adequate to a wide range of application QoS requirements. In addition, the framework provides means to allow the implementation of any level of synchronisation constraint necessary in a distributed application, through the use of the CORBA event and notification services. 20
Media Source
Media Sink
Stream Control Input Device Stream Adapter
Output Device Stream
Stream Adapter
Figure 7 - Video Broadcast
5. Examples of Applications of the Multimedia Architecture In the following sections several examples of applications of the framework for distributed multimedia are described. 5.1 Media Broadcast One of the situations frequently discussed in distributed multimedia is the broadcast of media, usually audio or video. Figure 7 illustrates the use of the multimedia framework presented previously to implement a broadcast application. In this application we show a media source broadcasting a video signal through the network, and one of the possible receivers (i.e. media sinks). In a broadcast session the quality of the broadcast is derived primarily from the media source. The source defines the maximum quality of audio or video that will be possible through the transmission, and the quality of the receiver device will specify within the limits imposed by the source the quality of the presentation of the corresponding media. In a similar way, the flow of media is imposed by the source. The destination cannot influence the flow of media (e.g. stop or pause the broadcasted signal). To be added to the stream and receive the broadcasted signal, the user has to get a reference to the stream control object in the source and use this reference to call a bind operation. The analogy between this situation and a TV or radio broadcast is applicable. In both cases the quality of the broadcasted signal depends only on the source, but the quality of the rendered audio or video can be degraded according to the characteristics of the receiver equipment. In addition, the signal is continuously broadcasted, independently of factors such as the number or receivers connected to it. One example of IDL interface for this stream is: interface VideoStream { void VideoFlow ( in Frame frm ); }
21
Media Source
Media Sink Stream Control Output Device
Input Device Stream Adapter
Stream
Stream Adapter
Figure 8 - On-Demand Video 5.2 On-Demand Media Another category of media session that can be identified in multimedia systems is the transmission of media on-demand. In this case the receiver requests the media that he wants to receive from the source. The receiver should be able to impose the QoS of the transmission, directly influencing the source of the media. The imposed quality of service may influence the billing of the service provided by the media source, in case of a private service subject to copyright. The receiver is also likely to be able to control the flow of data (e.g. stop or pause the flow) in the same way he does with a locally stored media such as a videotape or an audio CD. In this category of application, the media sink creates a stream between the input and output devices. The corresponding stream control object, located at the sink, is used to specify the required QoS for the transmission and to control the flow of data. Figure 8 shows the transmission of video on-demand from a media source (a video server). The same IDL interface of the video broadcast example can be used for ondemand video. 5.3 Videoconference Applications The names ‘media flow’ and ‘media sink’ are relative. A component of a multimedia application can be source and sink at the same time, when more than one flow is being transferred through the network. The most common example of this category of application is the videoconference. In this situation, each partner has the components necessary to send and receive media (usually audio and video). Each user locally controls the quality of the signal being transmitted, and can also degrade the received signal during the rendering process. One particular case of videoconference is one in which only two partners are involved, called digital video telephony. Figure 9 shows a video telephony system designed according to the proposed distributed multimedia framework. 22
Partner 1
Input Device 1
Partner 2
Output Device 2
Output Device 1
Stream Adapter
Stream Control
Input Device 2
Stream Adapter
Flow 1 Flow 2
Figure 9 – Video Telephony The control over the stream is held by the partner that requests the video telephone call – ‘Partner 1’ in this example. This is justifiable if we consider the analogy with a telephone call. The caller controls the connection and disconnection, even because he is paying for the call. In our particular case, the caller also controls and is charged according to the QoS requirements associated to the call. The privacy of the called partner is preserved because he has total control over his local devices, and can choose not to answer the call or to redirect it to a media recording device that behaves like an answer machine (or audio/video mail). The corresponding IDL interface is: interface VideoTelephoneStream { void VideoFlow1 ( in Frame frm ); void VideoFlow2 ( out Frame frm ); }
This solution does not evolve to a multi-party conference system because new flows cannot be added to the stream dynamically. Two different solutions are applicable for videoconference systems: a shared stream with access control via token, or a stream for each participant of the conference. The first solution consists of a shared stream, like the stream described for on-demand video and broadcast. A partner with an input device connected to the stream has to get a token to be able to transfer media. The partners connect their output devices to the stream to be able to get the media data. In this case, an active partner will be at the same time source and sink of the stream, while passive partners (‘voyeurs’) can connect their output devices to the stream and only watch the conference. The stream control object in this case has to implement the token mechanism with a policy to regulate the possession of the token, and stop all the input flows from the input devices but the one with the token. The second solution consists of one stream for each active partner in the conference, created and controlled by him. A partner creates an output device for each active partner in the conference that he wants to listen to, and attaches this device to the corresponding 23
stream. An external element is necessary to act as the conference information manager, keeping the partners informed about the ongoing media sessions related to the corresponding conference. A partner can choice the media that he wants to receive based on the information provided by the conference manager. 5.4 Media Session with Synchronisation In a complex application, in which multiple flows of media related to each other are being received by one particular destination, synchronisation between the media during the exhibition may be necessary. In this situation, we introduce an abstraction called a synchronisation control object, directly connected to the stream control object. The synchronisation control object receives the events raised by multimedia devices and controls the exhibition of media to allow the desired synchronisation. One common situation in which synchronisation of media is necessary is the composition of multimedia documents with media received from different sources.
Recorded Video
Video Output
Video Source
Media Sink Video Stream Control
Video Input Device
Video Output Device
Video Stream Adapter
Video Stream
events
Audio Stream Adapter
Video Stream Adapter
Synchronisation Control
Audio Stream
events
Audio Stream Adapter Audio Output Device
Audio Input Device
Audio Stream Control
Audio Source
Audio Output
Figure 10 - Multimedia Document with Synchronisation
24
Figure 10 shows a situation in which a movie is retrieved from a server. The image and the soundtrack are stored separately to allow the receiver to select the language spoken, but without the unnecessary duplication of the video. However, encoding video and audio separately obligates the receiver to execute the synchronisation between the audio and the video signals received from different sources possibly with different generation and transmission timings. As occurred in the examples of on-demand video, the flow of data in the multimedia document is controlled by the media sink, through the video and audio stream control objects. These objects interact locally with the output device and remotely with the input device for the corresponding media. The video and audio stream objects can have the following IDL interfaces: interface { void } interface { void }
VideoStream NewVideoFrame ( in VideoFrame vfrm ); AudioStream NewAudioFrame ( in AudioFrame afrm );
6. Related Work In the following sections we describe research projects related to the use of CORBA and similar distributed computing environments to support the development of multimedia applications in open systems using broadband networks. 6.1 ReTINA Project (ACTS) Real-Time TINA [Bosco 96] [Dang Tran 96] is a cooperative project being carried out by Chorus Systems, Alcatel, Siemens, HP, CSELT, France Telecom, British Telecom, Telenor, APM, O2 Technology and Broadcom. The project is sponsored by the European ACTS program. The main goal of the ReTINA project is the development of a distributed processing environment with support for interactive real-time and multimedia services, following standards such as CORBA and ODP, and keeping compatibility with the TINA architecture. The support for real-time and multimedia traffic is achieved through the encapsulation of multiple communication protocols within an ORB, providing flexible bindings and interaction models, and with fine-grained control of resources to meet QoS guarantees. ReTINA adopts a generic binding protocol based on the ODP reference model. The protocol introduces binding factory objects responsible for the provision of binding models appropriate to real-time and multimedia applications, such as third-party binding, multiple binding, and specification of QoS. In the last example, the resources necessary to achieve the desired QoS must be reserved for use of the ‘ODP capsule’ (address space) of the corresponding object. In addition, extensions to the IDL language to incorporate the stream abstraction are proposed. Stream interfaces have operations responsible for transferri ng frames of media. The operations do not have return values or argument directionality specification. Arguments specify the format of the frames transmitted through the 25
stream. Stream interfaces are referenced via CORBA references that may be passed by operation invocation or stored by the name service as normal CORBA references. The ReTINA environment will consist of a multi-platform ORB, with a real-time ‘profile’ running over the Chorus micro-kernel and with a non-real-time ‘profile’ over generic operating systems. Furthermore, the environment comprises a set of generic services, including configuration and management tools. 6.2 MMN Project (BT-URI) The Management of Multiservice Networks (MMN) project [Waddington 96] is a British Telecom University Research Initiative (BT-URI) which comprises a five year plan for six research institutions, focusing on the development of a set of management tools to perform management functions in a multi-domain environment using integrated services networks (basically ATM). The institutions involved in this project are: •
Computer Science Department, University College London;
•
Computer Lab, University of Cambridge;
•
Department of Computing, Imperial College;
•
Computing Department, University of Lancaster;
•
High Speed Networks Group, Loughborough University; and
•
School of Computing and Mathematical Sciences, Oxford Brookes University.
The main topics of MMN include features such as: •
Configuration Management;
•
Traffic Management, Monitoring and Measurement;
•
QoS Management; and
•
Network Security.
Configuration management is concerned with defining, constructing, and maintaining complex systems, which are viewed as interconnected instances of components (or objects). Components may be primitive or constructed from other components. A set of graphical tools, textual notations and design methods for configuring systems was proposed for the management of the network system, network services, and distributed applications. The configuration management tools aim to simplify the specification of distributed services in terms of the required instances of components, bindings between interfaces, and the allocation of components to nodes. Dynamic configuration permits change of components and recovery from component failures. The use of the domain concept provides the means of grouping objects and partitioning configuration management responsibility. QoS issues are intended to be supported through a CORBA based object model with continuous media streams. This involves the development of QoS extensions to CORBA and the development of a set of QoS mechanisms within an enhanced object model [Coulson 96].
26
An object-oriented framework for building communication protocol software from reusable components is also part or the MMN project. In this framework, protocol layers can be added to or removed dynamically from the stack during the lifetime of the communication session, allowing the software to react to changing QoS levels provided by the network and the operating system. Network-level issues, such as control and monitoring of traffic in integrated services networks as well as network management and security, are also being addressed in this research initiative. At the highest level of abstraction, a Component Definition Language (CDL) is used to define the overall composition and configuration of objects within a session. CDL encapsulates the IDL interfaces and incorporates the features introduced by MMN, as QoS specifications and streams. The experiments are being performed using a number of different distributed programming platforms, including Darwin/Regis, AnsaWare, Xerox Parc ILU and Orbix. The final objective of MMN is to fully integrate all the proposed features into a CORBA compatible architecture. 6.3 SUMO (MPG-Lancaster) The SUMO Project (SUpport for Multimedia in Operating systems) [Coulson 94] [Coulson 95], developed by the Distributed Multimedia Group at Lancaster University and by CNET at France Telecom, concerns a microkernel-based system which aims to provide facilities to support distributed real-time and multimedia applications in ODPbased platforms. The SUMO project provides the application programmer with a QoS-driven API with facilities for monitoring and controlling QoS levels, and a connection-oriented communication system with connection-dedicated resources. A set of key architectural principles was adopted in the design of SUMO. They are: •
upcall-driven application structuring, whereby communications events are system rather than application initiated;
•
split-level system structuring, which means that key system functions are carried out co-operatively between kernel and user level components; and
•
decoupling of control transfer and data transfer, i.e. the transfer of control is carried out asynchronously with respect to the transfer of data.
The Chorus microkernel was used as a vehicle for providing the operating system level services as well as rudimentary real-time support. The design of the SUMO distributed real-time/multimedia support system was implemented partly in kernel space and partly as a user level library to be linked with native Chorus applications. In parallel with the development of SUMO over Chorus, the same research group investigated the necessary requirements to support synchronisation of continuous media in open distributed processing environments. A sophisticated support for synchronisation is proposed as a result of this work. The co-ordination of multimedia presentations, and the maintenance of timing relationships between distinct data transmissions and of event-based synchronisation points is allowed through the cooperation of invocation mechanisms with new services introduced at system level, 27
called streams and synchronisation managers. These services allow the verification of synchronisation constraints imposed on the exhibition of distributed media. Other research initiatives related to multimedia and group communication, as well as end-to-end QoS over integrated services networks, are also being addressed by the Distributed Multimedia Group at Lancaster University. 6.4 Xbind (CTR-Columbia) The Xbind project [Lazar 96] is basically a conceptual framework for creation, deployment and management of multimedia services on ATM networks which allows the specification and control of end-to-end QoS. The designers of Xbind, from the COMET research group at Columbia University, adopted an open signalling concept called “hardware independent signalling”. The main idea consists in creating a separation between switching software and hardware. This allows, for example, the installation of signalling software on an ATM switching platform from a third party vendor, simplifying the service creation, deployment and management. The CORBA architecture was adopted as the lower level for a “binding architecture” that presents the service provider with a set of open binding interfaces. The Binding Interface Base (BIB) allows an easy integration of control (connection establishment and resource allocation), network management and service management. The implementation of Xbind was built on top of a large set of operating systems, ATM switches and adapters. Interoperation between platforms is provided by using Iona's Orbix. 6.5 DIMMA (APM-ANSA) The DIMMA (Distributed Interactive MultiMedia Architecture) project [Otway 95] proposes to extend the currently adopted distributed computing architectures to incorporate real-time and multimedia capabilities. This research project is being conducted by the APM-ANSA Laboratories. The main objectives of the DIMMA project are: •
extending distributed computing object models such as CORBA to support real-time and interactive multimedia applications.
•
incorporating support for new paradigms of communication in distributed systems best suited for multimedia and real-time systems such as streams (e.g. audio/video communication) and signals (real-time processing).
•
identify extensions needed to support distributed services management, fine-grained control and monitoring of resource usage and management (e.g. explicit binding).
•
defining an architecture for QoS negotiation, management and control.
•
investigation of the interworking of distributed object models (e.g. CORBA vs. ODP) at the computational level (e.g. IDL translations) and at the engineering level (e.g. transport protocols).
The adopted approach consists in using a large set of distributed computing environments (ANSAware, DCE, and various ORBs) and operating systems (ranging 28
from desktop to real-time operating systems) as a basis for constructing a higher-level API. The design of DIMMA adopts an object model that incorporates features appropriate to real-time and multimedia environments. The interaction model adds the concept of streams and group communication to the traditional client-server model. Invocation can be based on RPC mechanisms in message passing. The control model considers both synchronous and asynchronous programming. Implicit and explicit binding are provided through the adoption of binding managers at both client and server sides. A QoS model addresses the requirements present in multimedia and real-time environments, allowing specification and control of end-to-end quality of service. And a scheduling model provides resource separation, priority scheduling mechanisms and deadline control. The implementation phase includes the development of a stub generator toolset that enables the support of several kinds of IDLs and the generation of client and server stubs for multiple DIMMA-supported engineering platforms (e.g. ODP, CORBA). The toolset is built around the Abstract Syntax Tree concept (AST), as a syntax-free way to capture the semantics of interfaces. The stubs generated are, where possible, independent from the engineering details such as transport used, marshalling and unmarshalling algorithms. The AST also serves as a data interchange format between the tools and services in the DIMMA development and runtime environment (type and scope checker, interface repository, and trader). The AMBER project [Kramer 96], also carried out at APM-ANSA Laboratories, intends to apply solutions proposed by APM in the DIMMA project and also from TINA and ODP to allow distributed multimedia over CORBA, incorporating the concept of stream interfaces in IDL and extending object adapters to support streams. The main goal of this project is to provide a CORBA-compliant environment suitable for distributed multimedia and telecommunication applications. 6.6 Shiva (Washington University at St. Louis) The Shiva project intends to optimise the performance of CORBA implementations for high-speed networks and performance-sensitive applications. Earlier studies and performance measurements [Schmidt 96] identified severe bottlenecks in the currently available CORBA implementations, which limit their utilisation for building applications with real-time requirements. To allow the development of a CORBA-compliant platform suitable for this kind of application, several changes in the way that the ORB processes method requests were proposed. The proposed approach to solve the observed performance problems introduces modifications at protocol level, including scheduling queues for processing requests, and optimisation in data copying, marshalling operations, and in the multiplexing of requests over communication links. Performance requirements are specified through a QoS specification language, which together with the corresponding IDL description is used to generate customised stubs and skeletons. A prototype ORB implementation, which is under development, will incorporate the proposed features and will be adopted as a platform for the development of applications with QoS requirements.
29
6.7 DAVE (Sandia Labs) Distributed Audio Video Environment (DAVE) [Friesen 95] [Mines 94], developed by researchers at Sandia Laboratories, is a model that combines object-oriented techniques, distributed computing and multimedia technologies giving rise to a heterogeneous, distributed multimedia development environment. DAVE provides network-based desktop audio and video conferencing capabilities and access to shared devices such as cameras, microphones, and video recorders used for the storage and playback of media. The DAVE model emulates the physical environment through the use of software abstractions. The model is composed of a device class hierarchy, a connection manager, an object manager, and an application programming interface (API). Media devices – sources or sinks of media – are represented through distributed objects organised as a device class hierarchy. Application developers can add new devices and data encoding formats by inheriting from the predefined classes. The object manager handles all real-time activities, manages device objects, and interfaces to the connection manager. The connection manager is responsible for all non-real-time activities, such as resource allocation, state information, exception handling, and authorisation control. DAVE API calls are used by application developers to create and connect the device components necessary for their applications. The first prototype of DAVE was implemented using standard UNIX workstations and traditional IP networking for inter-host communications on a local FDDI ring. The prototype is being migrated to a wide area gigabit network based on ATM technology and enhanced to provide resource allocation and security.
7. Comparison of the Proposed Distributed Multimedia Framework with Other Approaches The multimedia framework described in this document has as its main attribute the provision of a common middleware for the implementation of control and transfer of media in distributed multimedia applications. However, several other proposals aim to achieve the same results adopting different approaches. The ReTINA project has basically the same goals of our proposal, but the adoption of a binding model inherited from ODP introduces a new level of complexity that has to be handled by the application programmer. Our approach maintains the simplicity and transparency of the CORBA binding model, incorporating a binding paradigm appropriate for multimedia applications through the introduction of a stream abstraction, which allows connections with associated QoS specifications and multi-party connections. Furthermore, ReTINA proposes extensions to the CORBA IDL for the introduction of stream interfaces. Major changes in the IDL are not likely to be accepted by the OMG and by the CORBA community. The multimedia architecture described by this document maintains the compatibility with the current specification of IDL, using CORBA interfaces and operations for the provision of media streams. This approach allows the implementation of the same interface described in IDL using an ORB with 30
the stream mechanism or using a non-multimedia capable ORB with the currently available best-effort communication protocols. In other words, the introduction of the new features does not affect backward compatibility. The same considerations apply for DIMMA and Amber, projects developed by APM that had a strong influence on the ReTINA project. The Xbind project is a proposal of a framework for provision of multimedia services with QoS specification together with an appropriate binding architecture built upon CORBA. However, Xbind does not address features as synchronisation and the provision of stream abstractions. The MMN project proposes the provision of streams, QoS, and synchronisation through the use of other description languages besides the CORBA IDL. Our approach allows similar functionality for the transfer of media, binding, and synchronisation, without the introduction of more complexity at the programmer’s level. Several features that are addressed by MMN, such as management and security, are delegated to additional CORBA services in our project. The Shiva project proposes optimisations on the communication support to improve the performance achieved in method calls between clients and servers. Despite recognising that a better performance has to be provided by the CORBA communication protocols, we consider that this is not sufficient for the provision of transfer of media data. Several other projects in the field of distributed multimedia, such as SUMO and DAVE, do not adopt an approach based on standards for distributed object computing, constraining their utilisation in open systems and limiting their acceptance by the computer software market. On the other hand, the multimedia framework presented previously adopts standard solutions to provide and environment for development and execution of multimedia applications.
8. Conclusions and Future Work This investigation will have continuity with the detailed design, specification and development of the improvements necessary to the adopted core of the distributed multimedia framework as described in the item 4.3 of this report. We also intend to validate the proposed multimedia framework through the implementation of multimedia applications built upon the support provided.
9. References [Babaoglu 94]
O. Babaoglu and A. Schiper “On Group Communication in LargeScale Distributed Systems”, Broadcast (ESPRIT Basic Research Project 6360) Technical Report No. 57, 1994.
[Beadle 95]
H.W.P. Beadle “Experiments in Multipoint Multimedia Telecommunication”, IEEE Multimedia, Vol. 2 No. 2, Summer 1995.
[Black 95]
U. Black “ATM: Foundation for Broadband Networks”, Prentice Hall, 1995.
31
[Bosco 96]
P.G. Bosco (CSELT), E. Dahle (Telenor), M. Gien (Chorus), A. Grace (British Telecom), N. Mercouroff, N. Perdigues (Alcatel Alshtom Recherche), J.B. Stefani (France Telecom) “The ReTINA Project: An Overview”, ReTINA Technical Report 96-15, May 1996.
[Braden 96]
R. Braden, I. Zhang, S. Berson, S. Herzog, and S.Jamin “Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification”, Internet Draft, October 1996.
[CNET 96]
CNET – France Télécom R&D Center “Requirements for a Realtime ORB”, ReTINA Technical Report 96-08, June 1996.
[Conta 95]
A. Conta and S. Deering “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, IETF RFC 1885, December 1995.
[Coulson 94]
G. Coulson, and G.S. Blair, “Meeting the Real-time Synchronisation Requirements of Multimedia in Open Distributed Systems”, Distributed Systems Engineering Journal (DSEJ), Vol. 1, No 1, pp. 135-144, 1994.
[Coulson 95]
G. Coulson, G.S. Blair, J.B. Stefani, F. Horn, and L. Hazard “Supporting the Real-time Requirements of Continuous Media in Open Distributed Processing”, Computer Networks and ISDN Systems, Vol. 27, No. 8, July 1995.
[Coulson 96]
G. Coulson and D. Waddington “A CORBA Compliant Real-Time Multimedia Platform for Broadband Networks”, Workshop “Trend in Distributed Systems”, Aachen, Germany, October 1996.
[Dang Tran 96]
F. Dang Tran, V. Perevaskine, J.B. Stefani, B. Crawford, A. Kramer, D. Otway “Binding and Streams: The ReTINA Approach”, ReTINA Technical Report 96-16, May 1996.
[Deering 95]
S. Deering and R. Hinden “Internet Protocol, Version 6 (IPv6) Specification”, IETF RFC 1883, December 1995.
[Delgrossi 95]
L. Delgrossi and L. Berger “Internet Stream Protocol Version 2 (ST2) Protocol Specification – Version ST2+”, IETF RFC 1819, August 1995.
[Doar 93]
J.M.S. Doar “Multicast in the Asynchronous Transfer Mode Environment”, PhD Dissertation, St. John’s College, University of Cambridge, January 1993.
[Friesen 95]
J. A. Friesen, C. L. Yang, and R. E. Cline, Jr. “DAVE: A Plug-andPlay Model for Distributed Multimedia Application Development”, IEEE Parallel and Distributed Technology, Summer 1995.
[Fuhrt 94]
“Multimedia Systems – An Overview”, IEEE Multimedia, Vol. 1 No. 1, Spring 1994.
[Goralski 95]
W. J. Goralski “Introduction to ATM Networking”, McGraw-Hill, 1995.
32
[Hinden 95]
Robert M. Hinden “IP Next Generation Overview” http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html, May 1995.
[IMA 94]
IMA – Interactive Multimedia Association “IMA Recommended Practice – Multimedia Systems Service”, Second Draft, September 1994.
[Iona 96]
Iona Technologies Ltd. “Orbix 2.1 Programming Guide” and “Orbix 2.1 Reference Guide”, October 1996.
[Iona 96b]
Iona Technologies Ltd. “OrbixTalk White Paper”, April 1996.
[Joseph 95]
R. Joseph “MHEG-5: An Overview”, http://www.fokus.gmd.de/ovma/mheg/rd1206.html, December 1995
[Kramer 96]
A. Kramer “ANSAworks: Multi-Media Streams and CORBA”, ANSA Tech. Report APM.1757.01, April 1996.
[Lazar 96]
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, No. 7, pp. 1214-1227, September 1996.
[Little 94]
“Prospects for Interactive Video on Demand” IEEE Multimedia, Vol. 1 No. 3, Fall 1994.
[Meyer-Boudnik 95] T. Meyer-Boudnik and W. Effelsberg “MHEG Explained”, Multimedia, Vol. 2 No. 1, Spring 1995.
IEEE
[Mines 94]
R. F. Mines, J. A. Friesen, and C. L. Yang “DAVE: A Plug and Play Model for Distributed Multimedia Application Development”, Proceedings of the ACM Multimedia 94 Conference (also Sandia Report SAND94-8233, July 1994), ACM Press, pp. 59-66, New York, 1994.
[OMG 92]
Object Management Group “The Object Management Architecture Guide”, OMG Technical Document 92-11-1, September 1992.
[OMG 95]
Object Management Group “CORBAservices: Common Object Services Specification”, OMG Technical Document, March 1995 (Revised in November 1996).
[OMG 96]
Object Management Group “CORBA 2.0 Specification”, OMG Technical Document PTC/96-03-04, USA, March 1996.
[OMG 96b]
Object Management Group “Control and Management of A/V Streams: Request for Proposal”, OMG Technical Document Telecom/96-08-01, USA, August 1996.
[OMG 97]
Object Management Group “Noticiation Service: Request for Proposal”, OMG Technical Document Telecom/97-01-03, USA, January 1997.
[Onvural 95]
R. O. Onvural “Asynchronous Transfer Mode Networks Performance Issues”, Artech House, Second Edition, 1995.
33
[Otway 95]
D. Otway "DIMMA Overview", ANSA Tech. Report APM.1439.02, April 1995.
[Panzeri 95]
F. Panzieri and M. Rocetti “Reliable Synchronization Support and Group-Membership Services for Distributed Multimedia Applications”, Broadcast (ESPRIT Basic Research Project 6360) Technical Report No. 90, 1995.
[Rao 96]
A. Rao and R. Lanphier “Real-Time Streaming Protocol (RTSP)”, Internet Draft, November 1996.
[Rooholamini 95]
R. Rooholamini and V. Cherkassky “ATM-Based Multimedia Servers”, IEEE Multimedia, Vol. 2 No. 1, Spring 1995.
[Schmidt 96]
D. C. Schmidt and A. Gokhale "The Performance of the CORBA Dynamic Invocation Interface and Dynamic Skeleton Interface over High-Speed ATM Networks", IEEE Globecom'96 Conference, London, England, November 1996.
[Schulzrinne 96]
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson “RTP: A Transport Protocol for Real-Time Applications”, IETF RFC 1889, January 1996.
[Steinmentz 95]
R. Steinmentz “Analyzing the Multimedia Operating System”, IEEE Multimedia, Vol. 2 No. 1, Spring 1995.
[Stuttgen 95]
H.J. Stuttgen “Network Evolution and Multimedia Communication”, IEEE Multimedia, Vol. 2 No. 3, Fall 1995.
[Vogel 95]
A. Vogel, B. Kerherve, G. von Bachmannn, and J. Gecsei “Distributed Multimedia and QoS: A Survey”, IEEE Multimedia, Vol. 2 No. 2, Summer 1995.
[Waddington 96]
D. Waddington, G. Coulson and D. Hutchinson, "Specifying QoS for Multimedia Communications within a Distributed Programming Environment", Distributed Multimedia Research Group, Tech. Report MPG-2-08-96
[Zinky 97]
John A. Zinky, David E. Bakken, Richard E. Schantz “Architectural Support for Quality of Service for CORBA Objects”, Theory and Practice of Object Systems, Vol. 3 No. 1, January 1997.
34
