Receiver-initiated communication with ST-II

Multimedia Systems (1994) 2:141-149 M u l t i m e d i a Sys tems �9 Springer-Verlag 1994

Receiver-initiated communication with ST-II Luca Delgrossi*, Ral f Guido Herrtwich**, Frank Oliver Hoffmann**, Sibylle Schaller**

IBM European Networking Center, Distributed Multimedia Solutions, Vangerowstrasse 18, D-69115 Heidelberg, Germany

Abstract. As part of its work on the Heidelberg Transport System (HeiTS) for multimedia communication, the IBM Eu- ropean Networking Center (ENC) has implemented the Exper- imental Internet Stream Protocol, Version 2 (ST-II). ST-II is a connection-oriented internetworking protocol for multiple- destination communication of real-time data such as digital audio and video. Although ST-II fits well into typical multimedia application scenarios, some functions are still missing No mechanisms are provided for receiver-initiated communication, allowing receivers to join streams, specify their quality of service (QOS) requirements, or initiate stream establishment and resource reservation. In this paper, we present some extensions to tile protocol that make it fulfill the receivers' needs move adequately. Our approach allows intermediate nodes to execute stream management functions on behalf of the sender. This way, the protocol scales better with the number of receivers per stream, as the origin does not need to track every target.

Key words: ST-II-multimedia communication -Receiver ini- tiation - Resource reservation - Multicasting-scalability

1 Introduct ion

In the last two years, we have developed and implemented the Heidelberg Transport System (HeiTS) [8, 9] as part of a distributed multimedia software platform for IBM's worksta- tions and personal systems. The goal of HeiTS is to transport digital audio and video over heterogeneous networks so that the real-time requirements of these media are met. The first IBM product to use HeiTS is the Ultimedia Server/6000, an RS/6000-based video server.

The core of HeiTS is Version 2 of the Experimental Internet Stream Protocol (ST-H) as described in the Intenet Request for Comment 1190 [15]. Our choice for ST-II as the main protocol in HeiTS was based on the following criteria:

- We wanted to have a protocol tuned to the needs of both transporting audiovisual data and supporting multimedia applications. ST-II, with its functions for sending

* e-mail: [email protected] ** e-mail: {rgh, hoffmann, schaller}@dhdibmip.bitnet Correspondence to: L. Delgrossi

data streams over multicast routing trees with underlying guaranteed-bandwidth channels, meets some of the main requirements.

- Most audiovisual applications that we had in mind send large chunks of data over a period of time. Because of this large amount of data, the protocol should allow for efficient data transport. Handling of data protocol data units (PDUs) in ST-II can indeed be very fast (although this is done at some expense to the quick-and-easy connection establishment).

- With Internet protocols (IPs) being the most prominent protocol family worldwide, any new protocol for multimedia communication should fit into it easily (e.g., should use the fa- miliar IP addressing schemes). ST-II fulfills this requirement.

- Finally, we simply found it a bad idea to start from scratch. A lot of effort has gone into the specification of ST-II (with more effort needed to correct mistakes and inconsisten- cies in the existing specification). We saw no reason to replicate this effort without having gained practical knowledge about which features are really needed, which can be omitted, and which are missing.

Recently, interest in ST-II within the Internet community has grown after the protocol was chosen by the Berliner Kom- munikation (BERKOM) project, one of the most prominent multimedia teleservices projects in Europe [ 1], to become part of its transport platform. A recent survey lists 13 ST-II existing implementations, some of them still in the process of being completed [5]. The Internet Engineering Task Force (IETF) has set up a new working group to clarify the ST-II specification so that it can serve as a better reference point for these implementations. We have also been informed of activities studing the use of ST-II over Asynchronous Transfer Mode (ATM) networks within the research community, two of them being described in [7] and [12]. As new protocols like the Re- source ReSerVation Protocol (RSVP) [ 17] appear on the scene, it seems natural to compare them to ST-II. Some first results can be found in [31.

Our implementation runs on IBM RS/6000 machines with the AIX 3.2 operating system and on IBM PS/2 computers with OS/2 2.0. Ports of our implementation to the Macintosh and Windows are underway. Currently, the system runs on top of Token Ring and Ethernet networks. Support for the integrated services digital network (ISDN), B-ISDN, and fiber digital data interface (FDDI) is being worked on. Detailed

142

information about our implementation and ST-II can be found in [10] and [3].

This paper introduces ST-II extensions to provide receiver- initiated communication. The extensions enable receivers to join existing streams, to specify their needs in terms of quality of service (QOS), and to initiate stream establishment and the corresponding resource reservation, in addition to the tradi- tional ST-II approach of sender-oriented stream management. One important result is that ST-II stream management functions can be distributed better among the nodes, relieving the sender is of some of his tasks. This way, the protocol scales better with the number of receivers per stream.

The rest of this paper is structured as follows: Sect. 2 briefly describes stream management in ST-II as currently specified and shows the necessity for extensions. Section 3 introduces our solutions and focuses on security, QOS, stream management, and other communication aspects. Sections 4 and 5 provide a detailed design and implementation description of the variants for the ENC ST-II implementation. Finally, Sect. 6 gives a short summary and a plan of future work.

2 S t r e a m m a n a g e m e n t in ST-II

The ST-II communication philosophy is sender oriented. ST-II allows the establishment of data streams in the form of directed routing trees between an origin and one or more targets. To set up a stream and application must inform the ST agent at the origin. ST agents are entities running ST-II: they commu- nicate with each other via the ST Control Message Protocol (SCMP). The ST agent at the origin generates a CONNECT request message and sends it to the next links inthe direction of the targets. Links are referred to as hops in ST-II and are uniquely identified by hop identifiers (HIDs). HIDs are negotiated at connection set-up time between neighbor ST agents. The CONNECT message may be forwarded by several routers and is finally received by the targets.

An ST-II target is able either to accept or reject the connection request. The decision could be based on theflow specification (FlowSpec), which is transported in the CONNECT message and describes the resource requirements of a stream. FlowSpecs possibly include upper and lower values for end- to-end delay, rate, and jitter. (There seems to be no consensus yet on the format of the FlowSpec within the research community.) Targets reacting with a REJECT message to the connection request are excluded from the stream. If a target accepts, appropriate ACCEPT message is sent back to the origin and the stream is established.

All manipulations of the target set are initiated and controlled by the origin ST agent. For instance, adding a set of targets, removing a set of targets, and changing the FlowSpec can be initiated by the origin only. Targets are allowed to accept or refuse changes or can disconnect themselves from the stream, but they cannot change the stream's target set. The current protocol specification of ST-II does not offer functions to allow targets to inform the origin of a change request in the tree structure of a stream. These decisions in the design of ST-II make it a sender-oriented protocol.

Sender-oriented communication is appropriate if all receivers receive the same amount of data. A video distribution service in wich all receivers need to process the same video format is an example. We have implemented such a system distributing digital video interactive (DVI) videos. In this system, it is also important for the origin to keep track of the receivers as it is intended to base charging on the time a receiver is connected. We have also de conferencing systems in which the group of participants is known right from the start of a conference. It is easy for the source to establish communication channels with all receivers at startup time.

Receiver-oriented service is more desirable in some applications. Video on-demand applications are, per se, receiver controlled. If there is no need for the sender to be informed about all receivers tuned in to its stream, the sender should not be required to perform receiver administration. This is even more pertinent if all receivers have diverse QOS requirements. In this case, the receivers themselves can determine and select the amount of data they receive. This selection, however, requires the data format to be adjustable by the receiver without contributions from the source.

Typically, multimedia data can only be adjusted either at the source or the sink. In the argument for receiver-specified QOS it is often said that a low-bandwidth network link may be the reason for a target to consume less data [17]. Here the sink would not receive all the data to scale the stream down by itself. If, in this case, the sender is not asked to scale down a stream it is emitting, the scaling must be done within the network. This cannot be achieved unless the encoding format used for a stream is known. Scaling brings with it either the problem of format-dependent network protocols or the problem of nodes that need to execute user-provided filter code for scaling down a stream.

Obviously, in a sender-oriented system receiver-initiated communication can always be implemented with layering: in the original ST-II protocol, a new target (or a set of new targets) can be added to a given stream by sending a join request to the stream's origin. This approach has several drawbacks:

- Although this mode of operation is foreseen by the ST-II specifications, ST-II does not provide for the target the means of sending the join request to the origin. This means that the request must be delivered over a separate service, e.g., a User Datagram Protocol (UDP) datagramm.

- The origin must always handle the request itself. This causes an implosion at the origin in the presence of a large number of additional targets.

- It is not efficient to request the origin for everything, traversing the whole tree twice per request, backward (for the request) and then forward (for the connection establishment). A more efficient scheme allows intermediate nodes to intercept and serve the requests. This way, the load of stream management is distributed better among the nodes.

We believe that, depending on the application scenario, one should be able to choose between sender and receiver-initiated communication. It is, hence, desirable to have a protocol that can do both.

3 ST-H Extensions for receiver-oriented communicat ion

This section introduces extensions to ST-II for receiver- oriented communication. The services presented are integrated into the protocol in addition to the usual sender-oriented functions. They allow receivers to join existing streams, specify their needs in terms of QOS, and initiate resource reservation.

3.1 Connection establishment

Assume a target A intends to join an existing stream S. Three scenarios are possible depending on the location of stream and target:

1. The stream may already traverse the node on which target A is located, thus, the local ST agent owns the entire stream information.

2. The stream 5' does not flow through the target, but flows through the subnetwork to which the target is connected.

3. We have the general case where target A and stream S are located anywhere in the network with an arbitrary number of routers in between.

Within the scope of our work, to experiment with various solutions, we decided to realize two different versions of receiver-oriented connection establishment. They are described in the next subsections.

3.1.1 "Join stream at router"

The new target issues a request to join a given stream by sending an appropriate message, say JOIN REQUEST. The request is sent to the stream origin. Before the origin has been reached, it is possibly intercepted by an ST agent at a router that is traversed by the stream. The ST agent serves the request by sending a CONNECT message to the new target. This causes a new reserved path to be created downstream from the router to the target, just as in usual connection establishment. The only difference is that the CONNECT message was not gen- erated by the origin. (The router can be seen as the origin of a substream that has the form of a subtree.) The origin itself is optionally notified at the time the new target has joined the stream.

This scheme is efficient because, in general, the join request can be handled well before it gets to the origin, depending, of course, on the routing decisions, with the interaction of a smaller number of ST agents Thus the time to join a stream is minimized. Also, by freeing the origin from some stream management operations (i.e., "add a new target"), duties are distributed better among the ST agents, and the protocol scales well with respect to the number of receivers in a single stream. The detailed design for this scheme is presented in Sect. 4.1.

3.1.2 "Create path backwards"

The target creates an ST-II path to the router. It sends a PATH CREATE message to the origin, which contains a flow specification. The creation starts from the target and terminates when an ST agent traversed by the stream is met. This process

143

takes place backwards or upstream with respect to the direction of the data flow (which is the major difference to the first method).

During path creation, the corresponding resources for the communication are reserved. The resource reservation takes place as follows: 1. Local resources as buffers and CPU are reserved in the

usual way by the local agents. 2. The new target does not reserve any network resources;

the next router upstream reserves network resources on the downstream path to the target and so on. Note that, although the path is created in the reverse di-

rection, the data still flows from the origin to the target. This version has the advantage that the receiver may specify its QOS requirements because it actually creates the path itself. Also, this version is very efficient because, when a router is hit, data forwarding through the new path can start immediately.

3.2 Security

When allowing receivers to join a conversation, aspects of data security must be considered to avoid illegal access. In particular, cases where ST agents are entitled to connect new targets to a stream without the sender's knowledge must be considered. In ST-II, no mechanisms are defined to ensure stream security This was considered a task of the higher layers. However, as we have shown, with receiver-initiated communication, some- times the decision must be taken at the ST-II layer.

We propose using several authorization levels associated with the streams. A straightforward way of introducing authorization information is to include it in the FlowSpec. The FlowSpec provides a natural medium for distributing stream information to the ST agents. Since it is possible to modify the FlowSpec during the lifetime of a stream, changing the authorization level can be easily accomplished as well. Although, at this point, we use the FlowSpec only as a carrier, negotiat- ing the authorization level of a stream could take place during connection setup.

To avoid dealing with individual receivers at the network level (i.e., to dispose of administrative overhead in our scheme), we decided to allow for the four authorization levels illustrated in Table 1.

The four authorization levels are independent of the two versions of connection establishment already introduced. Both versions can be implemented with all four authorization levels.

Note that charging, although we have not dealt with it in our current system, can be implemented in a similar way. If the application wants to charge for its service, it requests notification.

3.3 Quality of service (QOS)

When joining an existing stream the QOS for the new target can be defined in several ways. The approach we have taken is the simplest: new targets must accept the current stream's QOS or a lower one. It is possible that the target knows about the QOS of the stream (usually the target collects information

144

Table 1. Authorization levels for ST-II streams

Level Name Description

0 Nobody

1 Ask application

2 Any with notification

3 Any without notification

Agents are not allowed to connect further targets. All requests are rejected. The application at the origin is asked whether the new target should be accepted. Agents are allowed to add targets. The origin is notified about the additional targets. Agents are allowed to add targets. The origin is not notified about the additional targets.

about the stream before joining, e.g., the stream's name. In this case, information on the current QOS could be collected at the same time). If this information is available, the target can create the path to the router by itself avoiding the problem of specifying a QOS that is not feasible for the stream. Otherwise, the target will receive information on the QOS in the FlowSpec as in normal connection establishment, and it will be given the choise of accepting or refusing the connection.

Schemes in which the new targets require a higher QOS than the stream's current QOS are more complicated and are left for further study. Note that once the target has joined the stream, it can always request a change in the stream's FlowSpec. However, one may assume that, in a receiver- oriented scenario, a source would always operate at its highest QOS level. Therefore, elaborate mechanisms to deal with this situation seem inappropriate.

3.4 Resource reservation

When reserving the network starting from the receiver, some differences can be expected, compared to the sender-oriented approach. If the FlowSpec of the stream is already known, the target may adjust his requirements to it. If the FlowSpec is not known, the danger is that a reserved path is created that does not fit into the stream's characteristics. For example, the new path could be set up to allow a 2 Mbits/s throughput with 32 messages of 16 kB wheraes the maximum message size for the stream is 4 kB only.

Receiver-initiated communication will only work well with reservations if the target has good information about the characteristics of the incoming stream. Obviously, a small set of encoding and data formats helps to solve the problem.

3.5 Stream management

Some of the schemes we have introduced allow the origin to be unaware of the presence of the new target. This means that ST agent that connected the target must take responsibility for it. This requires special target management actions. Special care has to be taken (a) when the properties of a stream change as an effect of a message from the origin and (b) when the target delivers a control message to the origin. In particular: - When a stream is deleted, the additional target must be

disconnected. Since a DISCONNECT message sent by the

origin will not have this effect, the router must take care of this case and send a DISCONNECT message to the additional target.

- The same applies whenever the properties of a stream change as an effect of a CHANGE message from the origin. The message needs to be forwarded to the additional targets as well.

- CHANGE REQUEST messages are used by targets or routers to request changes of a stream's FlowSpec and are always forwarded upstream. Since the new target is not known to the origin, the router must either filter the message and reject the request or issue a change request on behalf of the target.

- Suppose a router _R serves a target/3 and the new target A, and suppose target B now disconnects. As a consequence, router R should normally disconnect (from the origin's point of view). Since target A is still active, the connection is kept alive. Alternatively, router R disconnects target A and then leaves the stream as well. Note that the targets do not know (nor do they need to

know) whether the origin or an intermediate router manages the connection. The schemes we have presented transfer functions usually executed at the origin into the ST agents at the routers. It is essential that, as a consequence of this process, the routers do not become the new bottleneck. To implement stream management functions, the router only has to mantain information on the additonal targets. The abilities to disconnect a target, forward a change message, and issue a change request are already part of an ST router's capabilities. Thus, we feel that no significant additional complexity is introduced in the routers with our schemes.

3.6 Multicast group

When creating a path in the reverse way, HIDs (Sect. 2) must be negotiated carefully. The target proposes an HID, and the previous hop may accept or reject it. When the stream is hit, the previous hop already has an HID in use for the stream, so it must reject the target's proposal. It can use the FreeIDs parameter to suggest the use of the HID for the stream. If this HID is already in use at the target, the negotiation should proceed as described in the ST-II specification, but it is clear that it will be impossible to include the target in a previously established multicast group (identified by the current HID for

145

I sender application t I receiver application I

- . . .s t rea. .m ............. _=~ ' ' -

i access authority 0 : "nobody" i: "ask application" 2: "any with notify" 3: "any without notify"

notify (access denied) [0]

join_request [1] .11 connect [11

-- notify (new target) [21 connect [2,3]

r sender application I I receiver application I

" - . . . . . . s t:e.,m ............. " - " . . . . . .......

�9 11 path_create - access authority

0 : "nobody" i ~! "ask application"

"any with notify". 31 "any without notify"

notify (access denied)lO] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e r e .

4 notify (new target) [2]

_ notify (new target) [1]

notify (accept target) [1/,,.2, 3] disconnect [2, 3] ~_ notify (refuse target) [1.2, 3]

2

the stream). In this- case, the re negotiation of the multicast HID is required.

4 Detailed extensions design

Based on these considerations, we can now take a closer look at the algorithms of the two schemes introduced in Sect. 3.1.

4.1 "Join s t r eam at rou te r"

The "join stream at router" scheme is sketched in Fig. 1. In this scheme, we allow any ST agent to connect a receiver,

provided that the authorization level permits it. The receiver must know the n a m e of the stream it intends to join. A stream's name in ST-II is globally unique and contains the address of the stream's origin. The ST agent at the receiver checks if the stream already flows through the node. If not, it sends a JOIN REQUEST message towards the origin. When an ST agent traversed by the stream is hit, further actions depend on the authorization level:

Fig. 1. Join stream at router Fig. 2. Create path backwards

- Nobody. No targets are allowed to join this stream. A RE- JECT message is sent back to the target.

- A s k appl icat ion. The request is sent back to the origin, where the application (possibly the upper layer protocol) decides whether to authorize the new target. In case the target is allowed to join the stream, a CONNECT message is sent by the origin to the new target, just as in normal connection establishment.

- A n y wi th noti f ication. The router sends a CONNECT message to the new target. In other words, the router acts as the origin for the purpose of joining the new target to the stream. When the router receives the ACCEPT message from the target, it does not forward it. Instead, it sends a NOTIFY message to inform the origin of the stream extension.

- A n y w i thou t noti f ication. The behavior mirrors the previous case, but no notification message is delivered to the origin. The router is responsible for the new target from now on, as described in Sect. 3.5.

146

4.2 "Create path backwards"

The "create path backwards" scheme is sketched in Fig. 2 be- low. In this scheme a new path to the router is created as de- picted in Fig. 2. This implies that the new target A does not wait for a CONNECT message any longer. To set up the new path, the corresponding FlowSpec must be provided. As mentioned in Sect. 3.3, we allow for the following two cases:

- The actual FlowSpec of the appropriate stream is used. These values can be acquired from the sender itself or from a server where information about existing streams is stored. It will be easy to use this scheme for fixed QOS streams. Using the actual FlowSpec introduces a high probability that data transmission can start immediately after the new path hits the stream.

- The new target chooses values of the FlowSpec that define a lower QOS (possibly due to insufficient hardware capabilities or in the attempt to economize on the resources). In this case, the stream could be scaled, e.g., the new target is not serviced at the full rate. The approach of media scaling is part of our work on HeiTS. Media scaling in HeiTS is documented in [2].

After all reservations at the target are successfully completed, a PATH CREATE message is sent to the origin. (The ST-II protocol does not specify a routing algorithm. The routing decisions required to deliver the message back to the origin are outside the scope of this paper.) If the message is received by an ST agent that is not a member of the stream S (thus, becomes a router node in future), the agent must make the necessary reservation and reply with either HID APPROVE or HID REJECT.

HIDs are negotiated as usual between the previous and next hop, but with changed roles. Since the router did not belong to the stream, it is impossible for a multicast group (identified by a particular HID) to be present. The PATH CREATE message is then forwarded to the next ST agent. If an agent that is member of the stream is hit, it must check the authority level first to decide whether to connect this new target.

- Nobody. The new path is destroyed and a DISCONNECT message is sent to the target.

- Ask application. Although the new path is already established, no data can be forwarded to the target yet. Instead, a NOTIFY message is delivered upstream to ask the sender for permission to connect the new target. The sender's response is delivered via a NOTIFY messag too. A refusal to extend the stream causes a DISCONNECT message to be sent to the new target to remove the created path. Otherwise, the stream is set up and the data is forwarded to the new target.

- Any with notification. If the FlowSpec of the new path is the same as the stream's, data forwarding starts immediately. If not, two strategies can be implemented: (1) the data transmission does not start until a CHANGE message is successfully processed along the new path, and (2) the router node uses scaling techniques to adapt the existing stream to the new stream path. After the set-up is completed, the router sends a NOTIFY message upstream to inform the sender about the stream extension. On the way, all intermediate agents add the new targe

to their target list. The router that added the new target, now assumes that the target A is known to the entire stream, and therefore no special target management is done.

- A n y without notification. This is the same as "any with notification", except that the router takes the responsibility for the new target and manages the actions as described in Sect. 5.

5 Implementation within the ENC ST-H component

To implement the mechanism we have described, two new PDUS had to be introduced, some modifications had to be made to the FlowSpec, and the service interface of the implementation had to be changed.

5.1 New protocol data units (PDUs)

The connection request in "join stream at router" is based on a JOIN REQUEST PDU (Fig. 3), and on "create path backwards". A PATH CREATE PDU is used to construct the new path between the target and existing stream (Fig. 4). Both are very similar to a normal CONNECT PDU. An alternative so- lution would be to use CONNECT and one of its unused bits in the Options field, but we feel that having separate PDUs makes the protocol easier to understand.

OpCode Options

RVLID

TotalBytes

SVLI D

Reference LnkReference

SenderlPAddress

Checksum HID(=0)

DetectorlPAddress

NNI N NNN @ UserData

3

OpCode ] Options TotalBytes

RVLID SVLID

Reference LnkReference

SenderlPAddress

Checksum I HID

Detectorl PAddress

UserData I

Fig. 3. JOIN REQUEST PDU Fig. 4. PATH CREATE PDU

The first 11 fields (OpCode to DetetectorlPAddress) are the same as in the CONNECT message and represent the stan- dard SCMP header. Usage and meaning of the various fields are described in the ST-II specifications. The Name parameter specifies to which stream the new potential target wishes to be connected. The new target is described by the Target parameter. User data can be sent to the application optionally.

In contrast to the JOIN REQUEST PDU, the PATH CRE- ATE PDU (Fig. 4) transports the FlowSpec for the new path. The HID field contains a valid value, which can be negotiated between the next hop and the previous hop.

5.2 Changes in existing PDUs or parameters

All existing PDUs remain unchanged; thus, a full backward compatibility to the normal ST-II version is given. To transport the information of the authorization level, the FlowSpec had to be changed. Because different versions of FlowSpecs can be distinguished by their version numbers, no drawbacks caused by this extension for the backward compatibility can occur. Note also that FIowSpecs of different versions can usually be mapped onto one another. FlowSpec was changed so that we use the padding byte after the version number authorization level.

5.3 Service interface

The ST-II upper interface needs some changes to allow for the new services that we introduced. Our ST-II implementation has a native interface derived from the one proposed in [15], the original protocol specification. The following changes to our native interface were required:

- T o create a new stream, the STopenO function must be used. We added a parameter to this function, so that the name of the stream is returned when a new stream is created.

- To issue a join stream rpquest, a new function has been introduced: ST join request(). This function has the effect of sending a JOIN REQUEST message:

ST_join-request(name, target, userdata, userdataJength)

- To creat a new path, a new function has been introduced: ST path_create(). This function has the effect of sending a PATH CREATE message:

ST_path create(name, target, flowspec, userdata, userdata_ length)

- In some cases, the application at the origin has the choice of accepting or refusing a target's join request. The following two functions serve for this purpose:

ST_join_refuse (connection_id, target, reason)

ST_join_accept (connection_id, target)

We found these new service primitives easy to use in multimedia applications.

147

6 F i r s t r e s u l t s

Although ST-II was originally designed as a sender-oriented protocol, our experience showed that it is also well-suited to receiver-oriented communication. In particular, the modifications to the routers code were minimal. The main reason for this is that SCMP is a hop-to-hop (as opposed to end-to-end) protocol, so that routers already have most of the appropriate functions. As an example, a router receiving a CONNECT message from the ORIGIN (sender oriented) or a JOIN-REQUEST from a target (receiver oriented), will perform exactly the same action, i.e., issue a CONNECT message downstream.

A second consideration is that there is a trade-off between protocol scalability and protocol functions. Maximum scalability is achieved when the origin is unaware of the receivers. The limitation in this case is that it is impossible for the origin to perform certain functions, such as dropping a given target. Stream global functions are still possible, such as dropping all the targets. If the origin is aware of all the receivers, it has more control, and it can perform all kinds of functions, but the protocol does not scale well.

Finally, the most effective way of using sender- and receiver-oriented schemes is to combine them. How this can be done depends on the applications and also on the network topology. Let us consider, for instance, a video conference among three remote sites, say New York, Los Angeles, and San Francisco. At each site, 20 people may dynamically join and leave the conference. An effective way to exploit this situation is first to build the ST-II streams that connect the main sites by using the usual sender-oriented approach, then to let people spontaneously join and leave the conference with the receiver-oriented schemes. This flexibility allows ST-II to perform very well both with dense and sparse groups of receivers.

7 S u m m a r y a n d f u t u r e w o r k

To validate our design approaches and to test the improved scalability of the extended ST-II protocol, we have added the two schemes "join stream at router" and "create path backwards" with the four authorization levels to our ST-II implementation. Performance measurements are on the way. The first results indicate that joining a stream at an intermediate router can be very efficient and, if an agreement on the QOS is easily made, the data flow can start immediately. Large streams with a very large number of receivers can be built in two steps, by first setting up a basic ST-II tree, and then adding receivers without letting the origin know. The authorization schemes that we presented preclude interferences by external hosts.

Some areas are still open for future work. For instance, it is possible that, due to the topology of the network, many receivers will connect to the same intermediate ST agent, thus creating a new bottleneck similar to that of the origin. In this case, a load balancing scheme that attempts to distribute stream management overhead better could be envisioned.

Acknowledgements. The project framework in which our ST-II implementation was conceived are the HeiProjects, which are concerned

148

with providing distributed multimedia solutions on heterogeneous platforms. We would like to thank all project members for their support. In particular, we are grateful to Carsten Vogt and Lars Wolf, who implemented the resource management functions, which are tightly coupled with ST-II, and to Barbara Twachtmann and Kurt Reinhardt, who provided the link functions on top of which ST-II runs.

R e f e r e n c e s

1. Delgrossi L, et al. (1992) The BERKOM-II multimedia transport system. BERKOM Working Document, October 1992

2. Delgrossi L, Halstrick C, Hehmann D, Herrtwich RG, Krone O, Sandvoss J, Vogt C (1993) Media Scaling with HeiTS. ACM Multimedia 93, Anaheim, Calif.

3. Delgrossi L, Herrtwich RG, Vogt C, WolfL (I 993 ) Reservation protocols for internetworks: comparison of ST-II and RSVP. Fourth International Workshop on Network and Operating System Sup- port for Digital Audio and Video, Lancaster, pp 199-207

4. Delgrossi L, Herrtwich RG, Hoffmann FO (1994) An implementation of ST-II for the Heidelberg transport system. Technical Report 43.9303, IBM European Networking Center, Heidelberg, 1993. Internetworking - Research and Experience (to appear)

5. Elliot C, Lynn C (1994) ST-II in Practice (to appear) 6. Ferrari D (1990) Client requirements for real-time communica-

tion service. Technical Report 90-007, International Computer Science Institute, Berkeley, Calif.

7. Hagsand O, Pink S (1993) ATM as a link in an ST-2 intemet. Fourth International Workshop on Network and Operating System Sup- port for Digital Audio and Video, Lancaster, pp 189-198

8. Hehmann D, Herrtwich RG, Steinmetz R (1991) Creating HeiTS - objectives of the Heidelberg high-speed transport system. Telekommunikation und multimediale Anwendungen der Infor- matik, 21. Jahrestagung der Gesellschaft ftir Informatik, Darm- stadt, F&E Projekt-Berichte

9. Hehmann D, Herrtwich RG, Schulz W, SchtRt T, Steinmetz R (1992) Implementing HeiTS: Architecture and Implementation Strategy of the Heidelberg High-Speed Transport System. Sec- ond International Workshop on Network and Operating System Support for Digital Audio and Videog, Heidelberg, November 1991, Lecture Notes in Computer Science 614, Springer, Berlin Heidelberg New York

10. Hoffman FO, Delgrossi L (1993) A detailed tour of ST-II for the Heidelberg transport system. Technical Report 43.9302, IBM European Networking Center, Heidelberg

11. Nagarajan R, Vogt C (1992) Guaranteed-performance transport of multimedia traffic over the Token Ring. Technical Report 43.9201, IBM European Networking Center, Heidelberg

12. Oechsle R, Graf M (1993 ) The internet protocol family over ATM. Technical Report 43.9301, IBM European Networking Center, Heidelberg

13. Partridge C (1992) A proposal flow specification. Internet RFC 1363

14. Partridge C, Pink S (1992) Implementation of the revised internet stream protocol (ST-2). Internetworking - Research and Experi- ence 3:27-54

15. Topolic C (1990) Exerimental Internet stream protocol, Version 2 (ST-II). Internet RFC 1190

16. Vogt C, Herrtwich RG, Nagaraj an R (1993 ) HeiRAT- the Heidel- berg resource administration technique: design philosophy and goals. Kommunikation in verteilten Systemen, Miinchen, Infor- matik aktuell, Springer, Berlin Heidelberg New York

17. Zhang L, Deering S, Estrin D, Shenker S, Zappala D (1993) RSVP: a new resource ReSerVation protocol. IEEE Network 7:8-18

LUCA DELGROSSI received his diploma in computer science from the Uni- versity of Milan in 1986. After working for Olivetti and UC Berkeley, he became a team leader of the Com- munications and Platform Group at the Distributed Multimedia Solutions Department of the IBM European Networking Center in Heidelberg, Germany. He is one of the principal designers of the Heidelberg Trans- port System (HeiTS) for real-time multimedia conununication and has supervised the development of the

multimedia transport system in the German BERKOM project -both systems use the ST-II protocol. He currently co chairs the new IETF ST-II working group.

RALF GUIDO HERRTWtCH leads the Distributed Multimedia Solutions De- partment of the IBM European Net- working Center in Heidelberg, Ger- many. He has a diploma and doctorate in computer science from the Tech- nical University of Berlin. He has been involved in multimedia research and development since a sabbatical leave spent at the International Com- puter Science Institute at University of California at Berkeley in 1989/90. In the past three years at IBM, he has worked on making a $15000 RS/6000

compete with a $150 CD player and a $1000 TV set. Ralf is one of the three main editors of the ACM/Springer journal Multimedia Sys- tems. He can be reached at: rgh @dhdibmip.bitnet.

FRANK HOFFMANN completed his studies on computer science at the BA in Stuttgart, Germany, in 1991. After receiving his diploma, he held a guest-scientist position at the IBM European Networking Center (ENC) in Heidelberg. During this time he implemented the ST-II protocol as part of the Heidelberg Transport Sys- tem (HeiTS). Since October 1993, has been working for SAP, Germany. His current interests include distributed applications.

149

SIBYLLE SCHALLER was born in Ra- thenow, Germany, in 1959. She stud- ied computer science at the Technical University of Dresden and received a diploma degree in May, 1993. Since then she has been working at the IBM European Networking Center in Heidelberg, Germany. Ms Schaller works in the multimedia communi- cations area. Her interests include reservation protocols, and she is one of the main developers of the Hei- delberg Transport System (HeiTS).

Documents

Receiver-initiated communication with ST-II