REIHE INFORMATIK

1/93

MCAM: An Proto col for

R. Keller und W. E elsb erg

Universitat Mannheim

Seminargebaude A5 68131 Mannheim

MCAM: An Application Layer Proto col for

Movie Control, Access, and Management

 y

Ralf Keller and Wolfgang E elsb erg

Praktische Informatik IV

University of Mannheim, Germany

1 Intro duction

The aim of Op en System Interconnection OSI is to allow

the interconnection of heterogeneous and distributed com-

puter systems. The proto cols of layers 1-6 are now stan-

dardized, and several application layer proto cols have also

reached International Standard level, including X.400 for

electronic mail and FTAM for le transfer, access, and ma-

nagement [13]. What is still missing is a standard for the

control, access, and management of continuous media CM.

CM-streams suchasmovies have di erent requirements

than traditional discrete media e.g. text and graphics in

terms of bandwidth, delay, delay jitter, error control and

ow control. Every comp onent in a distributed multimedia

system has to guarantee these requirements. Considerable

work has to b e done to meet the challenge of multimedia

data streams. Examples of current research elds are mul-

Abstract

timedia le systems [23], op erating systems [2], synchroni-

zation [22], transmission proto cols [4], network supp ort [5],

Most of the recentwork on distributed multimedia sys-

and throughput improvement in upp er layers [9].

tems has concentrated on the transmission, synchronization

In this pap er we address the application layer layer 7

and op erating system supp ort for continuous media data st-

issues of continuous media data streams within the OSI fra-

reams. We consider the integrated control of remote multi-

mework. From our ongoing work on the XMovie pro ject [19]

media devices, such as cameras, sp eakers and microphones,

wehave gained exp erience in implementing CM-streams in

to b e an imp ortant part of a distributed multimedia system.

a network. Wehave learned from XMovie and other pro-

In this pap er we describ e MCAM, an application layer archi-

jects that low-level stream services can b e implemented on

tecture, service and proto col for Movie Control, Access, and

to day's computers successfully. Mo dern MAC proto cols for

Management in a computer network. The OSI Reference

high-sp eed networks, i.e. DQDB and ATM, allow iso chro-

Mo del is our framework. We present the proto col data units

nous transmission at high data rates [8]. Mo dern transp ort

and the Finite State Machine for our application proto col

proto cols employ rate-based ow control and forward er-

and outline the automatic generation of the implementation

ror correction in order to maintain the timing relationship

co de for layer 7 from our formal sp eci cation. MCAM al-

between sender and receiver [1], [26]. But application level

lows complete and integrated control of movie data streams

proto cols for CM streams are still missing.

and devices in a heterogeneous multimedia network.

Keywords: multimedia systems, digital movies, ISO/OSI,

CM streams have to b e enriched in layer7by supp ort ser-

application layer

vices. Wehave identi ed two such services: movie directory

and CM equipment control . Both services are absolutely



[email protected]

necessary for the realization of a multimedia service in a

y

[email protected]

distributed heterogeneous environment.

The movie directory is used as a rep ository for movie in-

Permission to copy without fee all or part of this material

formation, such as digital image format and storage lo cation.

is granted provided that the copies are not made or distri-

The equipment control service enables the user to control

buted for direct commercial advantage, the ACM copyright

CM equipment attached to remote computer systems, e.g.

notice and the title of the publicati on and its date app ear,

sp eakers, cameras, and microphones.

and notice is given that copying is by p ermission of the As-

In our mo del a user can access create, delete and select,

so ciation for Computing Machinery.To copy otherwise, or

manage query and mo dify attributes, and control play-

to republish, requires a fee and/or sp eci c p ermission.

back or record movies .Thus we call our proto col MCAM

c

1993 ACM

for Movie Control, Access and Management.

Two other approaches to multimedia control in distribu-

vironments are the Lancaster Architecture and Bellco-

ted en source sink source sink

re's Touring Machine. An overview of the two architectures

hitectures make use of a rep o-

can b e found in [25]. Both arc FILE

sitory/name service, and in the Lancaster Architecture it is

also p ossible to control CM equipment. But there is one ma-

jor distinction b etween these two architectures and MCAM:

FILE SHM

We separate the control proto col from the CM stream proto-

col and include the two new services in the control proto col.

Our assumption is that name services and device control ha-

e requirements radically di erent from those of continuous

v LIVE

media streams and should thus b e carried over a di erent

proto col stack. unication Sys-

In IBM's \Heidelb erg Multimedia Comm source sink

tem" equipment control and stream control are also avai-

lable but separated from each other [3].

Figure 1: An example of the three movie typ es

None of these pro jects provides a formal description of

the control proto col, whichwe consider to b e an imp ortant

step towards standardization.

Directory System. We use the ISO/CCITT directory

This pap er is organized as follows. In Section 2, we pre-

service and proto col to store and access distributed movie in-

sent the mo del of the movie service. Section 3 describ es

formation [11]. The X.500 directory standard distingui shes

the service de nition. The proto col sp eci cation and use

twotyp es of entities: directory user agents DUAs and di-

of underlying services is outlined in Section 4. Section 5

rectory system agents DSAs. Arbitrary information can

concludes the pap er.

b e stored in the entries of an X.500 directory. Therefore its

use for digital movie services is straightforward.

A user interacts with the directory system via a DUA.

2 Mo del of the Movie Service

The directory information is stored by the DSAs. They

co op erate to guarantee the consistency of distributed data,

2.1 Streams and Movies

and to answer remote and distributed queries.

The directory entry for a movie contains at least the fol-

Amultimedia application has to handle streams of conti-

lowing attributes: a unique name, lo cation a host, typ e

nuous media data, e.g. video and/or stereo audio streams.

FILE, SHM, or LIVE, format audio or video format, and

In this pap er we concentrate on digital movies. Three typ es

compression metho d.

of movies can b e distinguish ed: FILE , SHM , and LIVE .At

A user can query the directory system using the MCAM

the b eginning of its lifetime a movie will b e pro duced bya

service. He can request information ab out a sp eci c movie

source, e.g. a camera LIVE movie. After this it can b e

or search for movies of a sp ecial typ e or format. If he has

stored on disk for later use FILE movie, transmitted as

the authorization he can create, mo dify or delete a movie

a data stream through a network or pip ed through shared

entry.

memory SHM movie. The last step of its career will b e

amovie consumer, e.g. a graphic display { a window from

Equipment Control System. Most of the CM equip-

the user p oint of view LIVE movie. We will see later that

ment attached to a computer will supp ort more op erations

the three typ es have di erent functions and requirements;

than play, pause, resume and stop basic stream op erations.

for example live sources cannot b e played backwards.

It may b e p ossible to turn, zo om and fo cus a camera, or to

The reason whyweintro duce the SHM typ e is for multi-

increase or to decrease the volume of a sp eaker. Therefore

cast distribution or lters. We can connect a movie source

we consider remote equipment control to b e an imp ortant

to a shared memory bu er SHM which in turn can b e

part of a distributed multimedia system.

connected to multiple sinks, implementing an application -

Our mo del provides an interface to device op erations.

controlled multicast. The SHM can also b e used for ltering,

MCAM transmits the user requests to an equipment user

compression, etc. An example is shown in Figure 1.

agent EUA. The requested op eration is p erformed byan

We call an entity reading from an input device and pro-

equipment control agent ECA, which is directly connec-

ducing a stream on a network a source of a movie and an

1

ted to the CM equipment . All ECAs form the equipment

entity consuming a stream by writing on an output device

control system ECS, which provides a lo cation-transparent

a sink ofamovie. Sources and sinks can b e of either of the

access to CM-equipment.

three movie typ es FILE, SHM or LIVE.

Stream Provider System. The stream provider system

2.2 Functional Mo del

SPS provides to MCAM a plain stream service. Such st-

ream services have b een prop osed in the literature e.g. [4],

The functional mo del of our system is shown in Figure 2. It

1

consists of four parts: Directory System, Equipment Control

MCAM can use the directory service to determine the lo ca-

tion of each ECA. System ECS, Stream Provider System SPS, and MCAM. 2 local system remote system

DSA X.500 DSA X.500 Directory DSA DSA DSA DSA level

MCAM MCAM MCAM User MCA DUA MCAM MCA DUA application SUA EUA SUA EUA protocol level

SPS CM stream CM stream SPA SPA protocol level SPS SPA

ECS ECA ECA equipment level ECA ECA ECS

DUA: Directory User Agent MCA: Movie Control Agent DSA: Directory System Agent MCAM: Movie Control Access Management

SUA: Stream User Agent EUA: Equipment User Agent SPA: Stream Provider Agent ECA: Equipment Control Agent

SPS: Stream Provider System ECS: Equipment Control System

Figure 2: MCAM functional mo del

[7], [19], and several research pro jects rep ort successful im-

Parameter Typ e of source

plementations. The SPS provides

SHM LIVE FILE

 a connection service b etween stream provider agents

Reliabil i ty   

SPAs and

Sp eed  

Mo de  

 a stream data interface with the op erations play, stop,

Quality 

pause, and resume.

Section 

One of the connected SPAs acts as the source and the

Direction 

other as the sink of the stream. The role of each of the SPAs

is determined at connection establishment time and cannot

be changed until connection release, i.e. the direction of the

Table 1: Movie parameters

stream is xed.

Every play op eration creates a play context , and a stop

releases it. A play context determines which op erations are

archive for pro duction-qual i tymovies, or if medical data is

allowed and how they are p erformed on a sink. On a LIVE

involved, the movie transmission mighthave to b e error-free.

or SHM sink new data can only b e app ended, whereas on a

The default dep ends on the typ e of the source. The reliabi-

FILE sink new data can b e inserted or app ended, and old

lity parameter controls the error correction scheme used on

data can b e replaced or erased. The play context also car-

the CM data stream.

ries information ab out the currentvalue of the parameters

Eachmovie has a default data rate, called the real-time

for reliability , speed , mode , quality , section and direction .

rate. The initiator can request a speed presentation rate

Some of them can b e mo di ed by the user, others are xed

higher, lower, or equal to the real-time rate. E.g. an NTSC

see Table 1; a missing  indicates that the corresp onding

video has a real-time rate of 30 frames/second; if the initia-

parameter is xed.

tor requests a presentation rate of 15, the movie is played

With the parameter reliability the initiator declares whe-

at half sp eed.

ther he demands error-free service or whether he accepts

transmission errors. Most of to day's multimedia applica- Scienti c and commercial application s often use slowor

tions do not require 100 reliable transmission b ecause the fast motion mode  for sp ecial e ects. Whether this para-

errors are often not recognizable to human end users e.g. meter will haveany e ect dep ends on the typ e of source.

pixel errors in a video . But if the sink is a disk A FILE movie must b e recorded with 50 frames/second to 3

allow a 50 slow motion. Fast motion is easier b ecause The initiator and the resp onder b oth are Multiple Asso cia-

uniform skipping is sucient to create the desired e ect. tion Control Functions MACFs within layer 7. They cont-

rol an MCAM service element, a directory service element,

The ability to use the quality parameter dep ends on the

a stream control service element, and an equipment control

kind of source. Its main purp ose is to control the data com-

service element.

pression algorithms. The requested quality in uences the

Amovie transmission and management service is in many

resulting amount of data e.g. the quantization factor of

resp ects similar to a le transfer and management service.

JPEG [27].

Therefore our MCAM service follows closely the FTAM ser-

If the source is a FILE then the initiator can request trans-

vice already standardized by ISO [13]. Similar to FTAM,

mission of only a section of the stream. The default value

the movie service is sub divided into regimes. Three typ es of

for this parameter is the whole movie. It is also p ossible

movie service regimes are de ned:

to cho ose b etween two directions ; the movie can b e trans-

mitted in the default direction forward or in the reverse

 the MCAM regime which exists while the application

direction backwards.

asso ciation is used for the MCAM proto col, and

If the resp onder cannot guarantee either reliabli tyor

 the movie connection regime during which one sink and

sp eed at connection establishment the request is rejected.

one source are asso ciated with the MCAM regime

In contrast, if the guarantees are violated during op eration

 the movie control regime.

the resp onder can react in one of twoways: he can send

a noti cation to the initiator and continue or he can stop

The MCAM service provides for a sequence of movie

and issue a \provider stop". This option can b e selected at

connection regimes within a MCAM regime and a sequence

connection establishment time.

of movie control regimes within a movie connection regime.

Let us consider an example. A lab oratory assistantwants

Termination of a regime implies termination of all regimes

to observe a dangerous exp eriment with a remote camera.

nested within that regime. The nesting of MCAM regimes is

He uses his MCAM user agent to establish a connection

shown in Figure 3. The notion of regimes follows the FTAM

between the SPA of the remotely controllable camera LIVE

standard.

source and one of his windows on his screen LIVE sink,

and starts the movie. If he wants to see the details of the

3.2 MCAM Service Primitives

exp eriment, he can turn and zo om the camera to the desired

p osition, using his mouse and the MCAM control proto col

This section provides a short description of the MCAM ser-

over the network.

vice primitives. For each service, the user of the service

i.e. the application service element that invokes the service

primitive is stated.

Movie Control, Access, and Management. All the

services provided by MCAM can b e accessed at the service

MCAM Regime Control. Three services are asso ciated

access p oint SAP of the MCAM layer. The movie control

with MCAM regime control. The MCAM regime establish-

agent MCA uses the directory, ECS, and SPS to provide

ment service M-INITIALIZE is used by the initiator to

the MCAM service to the initiator. MCAM itself uses the

create and bind a MCAM regime to the application asso cia-

directory service to obtain information. For example, let

tion linking the twomovie service users. It also establishes

us assume that a client requests to connect movie source A

MCAM sp eci c information such as authorization and ac-

with movie sink B . If MCAM has no cached information

counting data. The orderly MCAM regime termination ser-

ab out A or B , it sends a query to its DUA and uses the

vice M-TERMINATE is used by the initiator to dissolve

information received to ll in the parameters for the SPS

the MCAM regime and unbind it from the application asso-

call.

ciation b etween the movie service user and the movie service

provider. The abrupt MCAM regime termination service is

used by either one of the service users M-U-ABORT or

3 Service De nition

the service provider M-P-ABORT to dissolve the MCAM

regime and its binding to the application uncondition all y.

3.1 Movie Service Provider and Movie

Service User

CM Equipment control. The M-EQUIPMENT-CON-

TROL service primitive allows the integrated handling of

In order to provide remote connections b etween sources and

remote devices, e.g. to p erform a camera zo om, or to adjust sinks in a heterogeneous environment, the MCAM comp o-

the volume of sp eakers. This service is visible in every regi-

nent uses a well-de ned service and proto col.

me. It interfaces to the user on the initiator side and to the

Our MCAM service de nition uses the abstract mo del

ECS on the resp onder side.

and terminology de ned in the OSI Basic Reference Mo del

[12] and the OSI Upp er Layer Architecture [10 ]. Our mo-

del describ es the interactions b etween the twomovie service

Movie Management. The movie management primi-

users and the movie service provider. Information is passed

tives create and delete movie sources and sinks. With the

between a movie service user and the movie service provider

create sink service M-CREATE-SINK the initiator can

bymovie service primitives whichmay carry parameters.

create a new sink e.g. a new le for the storage of a mo-

vie or a movie window on his screen or select an existing One of the movie service users is de ned as the initiator

one e.g. a sp eaker at a workstation and register this new or the user side and the other is de ned as the responder . 4 MCAM regime

movie connection regime

movie control regime

M-PLAY M-U-STOP M-RESUME M-PAUSE M-P-STOP M-MOVIE-PARAMETER M-EQUIPMENT-CONTROL

M-EQUIPMENT-CONTROL M-MOVIE-PARAMETER M-P-ERROR M-CONNECT M-DISCONNECT

M-CREATE-SINK M-CREATE-SOURCE M-DELETE-SINK M-DELETE-SOURCE M-EQUIPMENT-CONTROL M-MOVIE-ATTRIB

M-INITIALIZE M-TERMINATE M-U-ABORT

M-P-ABORT

Figure 3: Nesting of movie service regimes

sink with the MCAM server and the directory service. The each of the parameters describ ed in Section 2.2. This ser-

create source service M-CREATE-SOURCE creates a new vice is visible in b oth movie connection and movie control

source or selects an existing one and registers it with the regime.

MCAM server and the directory service. Dep ending on the

lifetime parameter of the create source or create sink service,

Movie Control Regime. In order to control movies,

the movie ob ject will exist only for the duration of the asso-

MCAM de nes ve services. The play service M-PLAY

ciation or until an explicit delete is p erformed. The delete

is used by the initiator to start a stream; the source starts

source service M-DELETE-SOURCE enables the initiator

sending and the sink b egins to receiveinaway determined

to release the binding b etween the MCAM service and the

by the kind of source and sink. Also the play context is

sp eci ed sink in either of twoways: the sink ceases to exist

established. The pause service M-PAUSE enables the ini-

or only the registration of the sink at the MCAM service

tiator to stop the movie; the play context is preserved. The

is removed. In its functionality the delete sink service M-

resume service M-RESUME restarts a movie whichwas

DELETE-SINK corresp onds to the delete source service.

stopp ed by the pause service. With the user stop service

Both services remove the resp ective directory entry. If the

M-U-STOP the initiator can stop the movie and release

initiator wants to interrogate or to mo dify the attributes of

the play context. The provider stop service M-P-STOP is

the sp eci ed movie source/sink he can use the movie attri-

used by the provider to signal the initiator that the end of

bute service M-MOVIE-ATTRIB.

the movie has b een reached or that an unrecoverable error

has o ccurred and the movie has b een stopp ed.

Connection Regime. With the movie connect service

M-CONNECT the initiator can connect one movie source

Provider Error. The provider error service M-P-ER-

to one movie sink. This de nes the direction of the data

ROR is used by the resp onder or by the provider to signal

ow and establishes access rights for movie control. The

the initiator that an error o ccurred, without stopping the

disconnect service M-DISCONNECT enables the initiator

movie. This can happ en if the reliabil ity or sp eed parame-

to release the sp eci ed connection.

ters cannot b e met at runtime, and the initiator had stated

at connection establishment time that he wants the movie

to continue in such cases.

Movie Parameters. The adjustmentofmovie parame-

ters is p erformed by a single service: M-MOVIE-PARAME- Obviously, most of the services describ ed ab ove require

TER. The initiator can interrogate and mo dify the value of access control, e.g. a remote microphone can only b e turned 5

Service primitive MPDU Carried by Service primitive MPDU Carried by

M-INITIALIZEreq INIRQ A-ASSOCIATE M-CREATE-SINKreq CSIRQ P-DATA

M-INITIALIZEresp INIRP A-ASSOCIATE M-CREATE-SINKresp CSIRP P-DATA

M-TERMINATEreq TERRQ A-RELEASE M-CREATE-SOURCEreq CSORQ P-DATA

M-TERMINATEresp TERRP A-RELEASE M-CREATE-SOURCEresp CSORP P-DATA

M-U-ABORTreq UABRQ A-ABORT M-DELETE-SINKreq DSIRQ P-DATA

M-P-ABORTind UABRQ A-ABORT M-DELETE-SINKresp DSIRQ P-DATA

M-DELETE-SOURCEreq DSORQ P-DATA

M-DELETE-SOURCEresp DSORQ P-DATA

M-EQUIPMENT-CONTRO Lreq ECORQ P-DATA

Table 2: MCAM proto col data units { regime establishment

M-EQUIPMENT-CONTRO Lresp ECORP P-DATA

M-MOVIE-ATTRIBreq MATRQ P-DATA

M-MOVIE-ATTRIBresp MATRP P-DATA

on by authorized users. The details of the access control

M-CONNECTreq CONRQ P-DATA

and authenti cation mechanisms are b eyond the scop e of

M-CONNECTresp CONRP P-DATA

M-DISCONNECTreq DISRQ P-DATA

this pap er.

M-DISCONNECTresp DISRP P-DATA

M-MOVIE-PARAMETERreq PARRQ P-DATA

M-MOVIE-PARAMETERresp PARRP P-DATA

4 Proto col Sp eci cation

M-PLAYreq PLYRQ P-DATA

M-PLAYresp PLYRP P-DATA

The MCAM service is distributed in nature. In order to

M-PAUSEreq PAURQ P-DATA

op erate in a heterogeneous environment, wehave to de ne

M-PAUSEresp PAURP P-DATA

M-U-STOPreq USTRQ P-DATA

the MCAM proto col precisely.

M-U-STOPresp USTRP P-DATA

We are convinced that the new generation of high-sp eed

M-P-STOPreq PSTRQ P-DATA

networks, and in particular ATM, provides the technical

M-RESUMEreq RESRQ P-DATA

foundation for the transmission of digital movies in worldwi-

M-RESUMEresp RESRP P-DATA

de networks. But equipment is heterogeneous, and will pro-

M-P-ERRORreq PERRQ P-EXPEDI-

bably always b e so. In order to enable movie transmission

TED-DATA

in a heterogeneous network the standardization ofamovie

transmission and control proto col is of ma jor imp ortance.

Table 3: MCAM proto col data units { control, access, and

We therefore provide a formal de nition of our MCAM pro-

management

to col, using the widely accepted OSI conventions.

In this section we describ e each of the MCAM proto col

data units PDUs, their mappings to underlying services,

Presentation Service Mappings. All remaining MCAM

and give an example for a state/transition diagram for cor-

proto col data units are mapp ed to the OSI Presentation

rect sequencing.

Service [15]. Only one presentation context is active when

the MCAM regime is established. Rememb er that MCAM

handles only the interchange of control information b etween

4.1 MCAM Proto col Data Units

twomovie service users. No CM data are transferred on an

ISO has de ned a data description language for application

MCAM asso ciation. The transfer of MCAM PDUs has no

layer PDUs called ASN.1 Abstract Syntax Notation One

real-time or high-bandwid th requirements, and thus no sp e-

[16]. We are currently in the pro cess of de ning all MCAM

cial presentation context is needed. The mapping of MCAM

PDUs in ASN.1. This allows us to generate C/C++ da-

application PDUs to the Presentation Services is shown in

ta structures for our implementation automatically. The

Table 3.

ASN.1 sp eci cation can also b e used to automatically crea-

te an enco der/deco der for MCAM PDUs for our runtime

4.2 State Transition Diagram

implementation . ASN.1 to ols are now provided with many

ISO/OSI communication software packages; a well-known

In addition to de ning the exact PDU formats in ASN.1 and

example is ISODE [24]. The PDUs of MCAM Regime Cont-

their mapping to lower layer services, a proto col sp eci ca-

rol are mapp ed to the ACSE service primitives, all others

tion must state the allowable sequences of events. We use

are mapp ed directly to the service.

a conventional state/transition diagram to sp ecify the dy-

namic b ehavior of the MCAM proto col. Since the diagrams

of the MCAM regime and the movie connection regime are

ACSE Mappings. The application asso ciation and rela-

relatively simple, only the more interesting diagram of the

ted application context for the movie proto col are establi-

movie control regime is presented in Figure 4.

shed by the Asso ciation Control Service ElementACSE

[14]. The service primitives used for initiali zi ng and ter-

minating the instance of the MCAM regime carry the pa-

4.3 Example

rameters of the asso ciation context and authorization and

A simple example of the usage of the movie service and the accounting information. The mapping of the MCAM ap-

corresp onding proto col ow is shown in Figure 5 in the form plication PDUs MPDUs to the ACSE service is shown in

of a time sequence diagram. An initiator establishes an asso- Table 2. 6 Connected

1 3 8 6

Outgoing Incoming Outgoing Incoming Play Play U-Stop U-Stop 22 21 Pending Pending Pending Pending 21 22

2 4 5 7 5 7

Outgoing Pause Outgoing Outgoing 17 Pending 18 EquipControl EquipControl 9 10 Pending Pending 18 Incoming 17 19 Playing Pause Pause 20 Incoming 11 12 Incoming Pending EquipControl 20 19 EquipControl Pending Pending 23 14 13 24 25 Outgoing 26 Outgoing 24 Incoming Resume 25 23 Regulate 26 Regulate 16 Pending 15 Pending Pending Incoming Outgoing 27 Regulate 27 Regulate Incoming Pending Pending Resume 28 28 Pending

1 M-PLAY request / PLYRQ 15 RESRQ / M-RESUME indication 2 PLYRP / M-PLAY confirm 16 M-RESUME response / RESRP 3 PLYRQ / M-PLAY indication 17 M-EQUIPMENT-CONTROL request / ECORQ 4 M-PLAY response / PLYRP 18 ECORP / M-EQUIPMENT-CONTROL confirm 5 M-U-STOP request / USTRQ 19 ECORQ / M-EQUIPMENT-CONTROL indication 6 USTRP / M-U-STOP confirm 20 M-EQUIPMENT-CONTROL response / ECORP 7 USTRQ / M-U-STOP indication 21 M-P-STOP request / PSTRQ 8 M-U-STOP response / USTRP 22 PSTRQ / M-P-STOP request 9 M-PAUSE request / PAURQ 23 M-MOVIE-PARAMETER request / PARRQ 10 PAURP / M-PAUSE confirm 24 PARRP / M-MOVIE-PARAMETER confirm 11 PAURQ / M-PAUSE indication 25 PARRQ / M-MOVIE-PARAMETER indication 12 M-PAUSE response / PAURP 26 M-MOVIE-PARAMETER response / PARRP 13 M-RESUME request / RESRQ 27 M-P-ERROR request / PERRQ

14 RESRP / M-RESUME confirm 28 PERRQ / M-P-ERROR indication

Figure 4: State transition diagram of the movie control regime 7

Extended Finite State Machine EFSM mo del. Compared

Initiator Responder to hand-written co de, an EFSM sp eci cation is more natural

M-INITIALIZE request

and easier to understand for the develop er. Using an FDT

y advantages: M-INITIALIZE indication sp eci cation and a co de generator has man

M-INITIALIZE response

 the co de generated from an FDT has fewer bugs than

M-INITIALIZE confirm hand-written co de

M-CONNECT request

 the co de is well structured and easy to understand

proto col machine asp ects are nicely separated from

M-CONNECT indication 

unication system no de, suchas

M-CONNECT response other asp ects of a comm

bu er management, timer management, le I/O, etc.

M-CONNECT confirm and

M-PLAY request

 the co de is more p ortable than hand-written co de.

M-PLAY indication t

M-PLAY response It is often claimed that generated co de is less ecien

than hand-written co de. We do not see a go o d reason for

ent ineciency in generated co de provided that the

M-PLAY confirm M-P-STOP request inher

co de generator is well implemented. In another pro ject our

M-P-STOP indication

research group is investigating p ossible p erformance enhan-

M-DISCONNECT request

cements by parallel execution. The overall sp eedup gained

y parallel execution is much higher than a p ossible sp eedup

M-DISCONNECT indication b

y manual co de optimization [9]. The parallel co de runs on

M-DISCONNECT response b OSF/1, and is also generated automatically from the same

M-DISCONNECT confirm Estelle sp eci cation [6].

ork is also in progress to re ne and improve our own CM

M-TERMINATE request W

stream proto col MTP [20] to provide the following services:

M-TERMINATE indication reliable and unreliable stream service using an adjus-

M-TERMINATE response 

table forward error correction mechanism

M-TERMINATE confirm

 supp ort for several uncompressed and compressed for-

2

mats for movies and

Figure 5: Time sequence diagram of a movie control example

 rate-based ow control for iso chronous transmission.

The improved Movie Transmission Proto col MTP and

other parts of the XMovie pro ject form the basis of our

ciation and connects a FILE source and a LIVE sink. Then

SPS implementation at the University of Mannheim. The

he issues a play command. When the end of the FILE source

XMovie prototyp e currently allows the transmission of digi-

is reached, the movie automatically stops, and the resp onder

tal movies b etween RISC workstations from DEC, Sun and

sends a provider stop signal to the initiator. The initiator

IBM at up to 25 frames/s. The movies are displayed in an X

then disconnects the sink and the source and terminates the

window, using our own extension to the X Window System

asso ciation.

[18].

Wehave conducted initial exp eriments with QUIPU, the

5 Summary, Status and Outlo ok

X.500 implementation of ISODE, as a basis for our movie

directory service. Our movie directory prototyp e is not yet

Wehaveintro duced MCAM, a new OSI Application Layer

completed.

Services Element for the access, control, and managementof

In a joint pro ject with IBM's Europ ean Networking Cen-

digital movies in op en networks. The movie control service

ter in Heidelb erg wehave also develop ed a remote camera

is enriched by supp ort services for the storage and retrie-

control system. The camera op erator uses his mouse, scroll

val of movie information and the control of CM equipment

bars and push buttons on his window surface to control a

attached to multimedia computer systems. The functional

remote video camera [3].

mo del of MCAM was presented, and the main comp onents

As a nal goal, weenvision several SPAs, ECAs, and

and their interworking were describ ed.

MCAM entities in an ATM network to provide a digital

The formal MCAM service de nition and proto col sp eci-

movie service in a heterogeneous environment using stan-

cation were outlined. These formal de nitions can b e used

dardized transmission and control proto cols.

to derive an implementation automatically.

We are currently writing a complete formal description

2

With the exception of MPEG [21], no international or de fac-

of the MCAM proto col in Estelle, and an abstract syntax

to standard for the format of stored digital CM streams exists.

for the movie service using ASN.1. Estelle [17] is one of

Therefore wehave develop ed our own format to store sequences

three international ly standardized sp eci cation techniques

of audio samples or video frames in a great variety of b oth com-

pressed and uncompressed formats. Formal Description Techniques: FDTs. It is based on the 8

[12] Information pro cessing systems { Op en Systems In- Acknowledgement

terconnection { Basic Reference Mo del. International

Wewould like to thank Bernd Lamparter for his invaluable

Standard ISO 7498, 1984.

and ongoing contributions to the XMovie pro ject. The re-

[13] Information pro cessing systems { Op en Systems Inter-

mote camera control system would not have b een p ossible

connection { File Transfer, Acces and Management. In-

without the help of our colleagues at IBM ENC Heidelb erg,

ternational Standard ISO 8571, Decemb er 1988.

in particular Ralf Steinmetz.

[14] Information pro cessing systems { Op en Systems Inter-

connection { Service De nition and Proto col Sp eci ca-

References

tion for the Asso ciation Control Service Element. In-

ternational Standard ISO 8649/50, 1988.

[1] Ernst W. Biersack. Performance Evaluation of Forward

[15] Information pro cessing systems { Op en Systems Inter-

Error Correction in ATM Networks. Computer Com-

connection { Connection Oriented Presentation Servi-

munication Review, 224:248{257, Oktob er 1992.

ce De nition and Proto col Sp eci cation. International

[2] Dick C.A. Bulterman and Rob ert van Liere. Multime-

Standard ISO 8822/23, 1987.

dia Synchronisati on and UNIX. In Network and Opera-

[16] Information pro cessing systems { Op en Systems Inter-

ting System Support for Digital Audio and Video, 2nd

connection { ASN.1 and its Enco ding Rules. Interna-

International Workshop, Heidelberg, Germany, Novem-

tional Standard ISO 8824/25, 1988.

ber 1991, pages 108{119. Lecture Notes in Computer

Science 614, Springer-Verlag, Heidelb erg, 1992.

[17] Information pro cessing systems { Op en Systems Inter-

connection { Estelle: A formal description technique

[3] Andreas Cramer et al. The Heidelb erg Multimedia

based on an extended state transition mo del. Interna-

Communication System: Multicast, Rate Enforcement

tional Standard ISO 9074, 1989.

and Performance on Single User Workstations. Techni-

cal Rep ort 43.9212, IBM Europ ean Networking Center,

[18] Ralf Keller, Bernd Lamparter, and Wolfgang E els-

Heidelb erg, 1992.

b erg. Erweiterung vonXfur digitale Filme. PIK {

Praxis der Informationsverarbeitung und Kommunika-

[4] Bert J. Dempsey, W. Timothy Strayer, and Alfred C.

tion in German, 154:196{204, Octob er 1992.

Weaver. Adaptive Error Control for Multimedia Da-

ta Transfers. In International Workshop on Advanced

[19] Bernd Lamparter and Wolfgang E elsb erg. X-MOVIE:

Communication and Applications for High Speed Net-

Transmission and Presentation of Digital Movies un-

works, pages 279{288, Munich, Germany, March 1992.

der X. In Network and Operating System Support for

Digital Audio and Video, 2nd International Workshop,

[5] Domenico Ferrari, Anindo Banerjea, and Hui Zhang.

Heidelberg, Germany, November 1991, Lecture Notes in

Network Supp ort for Multimedia . Technical Rep ort

Computer Science 614, pages 328{339. Springer-Verlag,

TR-92-072, International Computer Science Institute,

Heidelb erg, 1992.

Berkeley, CA, Novemb er 1992.

[20] Bernd Lamparter, Wolfgang E elsb erg, and Norman [6] Stefan Fischer. Generierung paralleler Systeme aus

Michl. MTP: A Movie Transmission Proto col for Mul-

Estelle-Sp ezi kati one n. Master's thesis, Lehrstuhl fur 

timedia Application s. Computer Communication Re-

Praktische Informatik IV, Universitat Mannheim in

view, 223:71{72, July 1992. German, 1992.

[21] Didier Le Gall. MPEG: A Video Compression Standard

[7] Simon Gibbs. Comp osite Multimedia and Active Ob-

for Multimedia Applications . Communications of the

jects. ACM SIGPLAN Notices, 2611:97{112, Novem-

ACM, 344:46{58, April 1991. b er 1991.

[22] Tom D.C. Little, Arif Ghafo or, C.Y.R. Chen, C.S.

[8] Rainer Handler and Manfred N. Hub er. Intergrated

Chang, and P.B. Berra. Multimedia Synchronisation . Broadband Networks: An Introduction to ATM-Based

IEEE Data Engineering, 143:26{35, Septemb er 1991. Networks. Addison-Wesley Publishing Company,Wo-

kingham, England, 1991.

[23] P.Venkat Rangan and Harrick M. Vin. Designing File

Systems for Digital Video and Audio. ACM Operating [9] Bernd Hofmann, Wolfgang E elsb erg, Thomas Held,

System Review, 255:81{94, Octob er 1991. and Hartmut Konig. On the Parallel Implementation

of OSI Proto cols. In Proceedings IEEE Workshop on the

[24] Marshall T. Rose. The Open Book: APractical

Architecture and Implementation of High Performance

Perspective on OSI. Prentice Hall, Englewo o d Cli s,

Communication Subsystems HPSC'92,Tuscon, Ari-

1990.

zona, USA, February 1992.

[25] Lillian Ruston, Gordon Blair, Geo Coulson, and Ni-

[10] Information pro cessing systems { Op en Systems Inter-

gel Davies. Integrating Computing and Telecommu-

connection { Application Layer Structure. Internatio-

nications: A Tale of two Architectures. In Network

nal Standard ISO 9545.

and Operating System Support for Digital Audio and

Video, 2nd International Workshop, Heidelberg, Ger- [11] Information pro cessing systems { Op en Systems Inter-

many, November 1991, pages 57{68. Lecture Notes connection { The Directory { Overview of Concepts,

in Computer Science 614, Springer-Verlag, Heidelb erg, Mo dels, and Service. International Standard ISO 9594-

1992. 1, Decemb er 1988. 9

[26] W. Timothy Strayer, Bert J. Dempsey, and Alfred C.

Weaver. XTP: The Xpress Transfer Protocol. Addison-

Wesley Publishin g Company, 1992.

[27] Gregory K. Wallace. The JPEG Stillpic ture Compres-

sion Standard. Communications of the ACM, 344:30{

44, April 1991. 10