AT&T Laboratories
Cambridge
|
|||||
|
|
AT&T Laboratories |
|
|
|
|
|||||
A stream is a unicast or multicast uni-directional flow of data between modules. An application is permitted to specify its communication requirements at start of day and to modify those requirements during the lifetime of the stream. Communication requirements may be specified in a media-specific manner (for example, picture size, frame-rate) and this specification is then mapped onto underlying transport parameters.
Modules are sub-classed as sources, sinks, agents, filters, switches, gates, etc. A module is a virtual processor much like a UNIX process, encapsulating host resources such as memory and CPU and providing an interface by which those resources may be controlled. A resource manager (not described further here) may be required to enable the user to control the allocation of resources between modules, each module being then required to communicate its resource requirements to the resource manager. A module is implemented as a CORBA object.
Stream end-points are called ports and modules contain one or more ports (sources and sinks contain a single port whereas other modules contain two or more ports). Ports that send data to the stream are called plugs and ports that receive data from the stream are called sockets. A port provides a control interface to permit management of communication resources (eg bandwidth, end-point identifiers), together with a stream interface for the transfer of data units called messages. The virtual concept of a stream is realised by the physical collection of two or more ports. A port is implemented as a CORBA object which may be statically or dynamically created by its enclosing module - depending on the nature of that module.
Modules are manufactured by factory objects which are running on distributed hosts, each of them running one or more factories. A factory is also implemented as a CORBA object run by a server process (eg UNIX or ATMos process) and modules created by a factory run within the context of the factory process. The mapping between modules and factories is flexible: multiple modules may be served by a single factory server, or modules may run stand-alone in their own server.
Streams may be composed into higher-level constructs such as ``stream pipes'' or ``stream bundles''. Each hop of a pipe, possibly with unique communication requirements, is considered a separate stream and the concatenation of streams in such a composition is called a \emph{pipeline}. Other stream compositions are possible.
In order to provide end-to-end service guarantees, an application may need to manipulate module control interfaces (to control host resources) as well as port control interfaces (to control network resources). This complexity is likely to be hidden by a library or a CORBA ``pipeline manager'' object.
Multimedia applications require different transport characteristics, like for instance reliable transport provided by TCP/IP where all the data that has been transmitted is received reliably. Reliablity in the transport layer involves the detection and recovery of corrupted data by the receiver and the detection and retransmission of lost packets. Other applications require low latency and totally unreliable transport characteristics such as those seen in UDP/IP.
However, an increasing number of multimedia applications have transport requirements that fall between the two extremes given above. Some applications do not mind data being lost but would like all the data being delivered to them by the transport layer to be free of corruption. Other applications would like all the data that has been received to be delivered, whether corrupted or not but lost packets should be recovered. This myriad of transport requirements which could be described as different qualities of service can be supported by using different protocol stacks. However, we feel that such an approach would lead to large, complex protocol layers. A better approach is to look at new transport protocols that can support different qualities of service.
For some time, we have been looking at new transport protocols that provide such functionality. We have been studying the XTP transfer protocol in some detail, especially the implementaion by Sandia National Laboratories called SandiaXTP. We are a Research Affiliate of XTP Forum.
The pros of using XTP is that it is a standard being supported by the XTP Forum, and if properly implemented it could go very fast. The real con is that to get performance we would have to do own our implementation. The second is that the protocol is not particularly suited to the connection-oriented ATM environment. We believe that it is worth looking at a new transport protocol that has most of the functionality of XTP but is better streamlined.
In that regard we have designed a new protocol using XTP as a starting point. Presently called A1 it has similar traffic parameters as XTP. Like XTP it supports both window and rate-based flow control but only uses selective retransmission only. It uses a defined network interface that allows connection-oriented (like ATM ) or connectionless subnetworks to be easily slotted in under it. A unique feature of A1 is its attempt to reduce latency at the transport layer or make applications aware of it. It attempts to reduce latency by demultiplexing data packets which are destined for the local side and transport control packets which has to do with data sent by the local size. It also attempts to make applications aware of latency due to flow control by not allowing users to queue data in the transport layer if the current window size is not large enough to send data. Automatically buffering this data at the transport layer will introduce latency which may be unnecessary. An application can choose to block until its window opens again thus experiencing network latency directly. A1 also takes a radical view to retransmission as retransmitted packets are explicitly marked as retransmitted and thus can be processed very quickly by the receiver. Finally A1 supports end-to-end flow control in which flow control mechanisms also take into account the speed at which data is being processed by the receiver and not just the number of bytes in transit between the protocol layers. A1 also is also attempting to support multicast and mobile environments.
The ability of an ATM network to deliver high bandwidth and low latency traffic has led to widespread deployment of distributed multimedia applications. However, audio and video traffic requires timely delivery and synchronised presentation for them to be useful. This leads to a need for a global timing service on an ATM network which will allow multimedia sources to do time stamping at source and multimedia sinks to do time synchronisation on received multimedia traffic.
A time synchronisation service is therefore implemented here on network end-points running the ATMos operating system. This time synchronisation service gets an accurate one-pulse-per-second signal from the Trimble Nav03 Global Positioning System (GPS) receiver. From the series of accurate GPS pulses, the service has the knowledge of accurate global time. Then, it distributes that global time to other clients through the RFC 1305 Network Time Protocol (NTP). NTP protocol is chosen so that the service is compatible with other time synchronisation services. However, the clock filtering, clock selection and clock combining algorithms have been optimised for the ATM network traffic. The current implementation managed to synchronise time on the ATM network with a standard deviation of 15ms which is reasonable because the timer resolution on the ATMos board itself is 10ms. For applications that need a higher clock accuracy, a additional timer board can be installed which has a resolution of 0.5us.
For comments, suggestions and further information please contact us.
Copyright © 2001 AT&T Laboratories Cambridge