The Information Superhighway needs network protocols that can carry multimedia around with the sorts of guarantees. At least that is what the communications companies say. In fact, if a network is provisioned at the right level (its lines are fast enough), it may not be necessary to impose any special protocols. Even with networks running close to capacity, the requirement is really merely for a way for routers and switches to distinguish different traffic types, and give them the appropriate forwarding priority.

The difference between different networks comes down (as do many in computer science) to when the binding is done between the flow of traffic and the state instantiated (together with resources) in a router to support the traffic class that this flow needs.

Two extreme examples of multiservice network architectures illustrate this:

In the Internet, the RSVP protocol can be used by a recipient to request a specified a quality of call for a flow that they require. This request is periodically resent, so there is no binding necessarily between the call and the route (i.e. rerouting can happen between 1 packet and the next). If no special quality is required, or else the routers already know about this traffic class and have capacity, then no RSVP is needed.

A source chooses a unique flow id for the traffic, which can be used by routers as a fast lookup for route and quality requirement for the traffic. In the absence of an entry for this flow in a router, the rest of the packet’s IP header can be consulted and the packet forwarded with some default quality anyhow. If the required quality varies, then it can simply be latched by the next RSVP refresh.

RSVP carries a flow specification and a filter specification. The flow specification is a list of parameters to do with throughput, delay and errors that will be needed to meet the flow’s requirements for reasonable delivery. The filter specification is a patter that is used to match the flow when it arrives at a router. A filter can be turned on and off without removing the flow specification, so that intermittent flows (e.g. video or voice in a floor controlled video conference) can be quickly turned on and off within the net. This is important for multicast.

RSVP interacts with the Routing protocol by possibly locking routes while any reservation is in progress to avoid looping. Filters can be wildcard, which is shared amongst all senders to a group, fixed or dynamic. Dynamic filters are sets of fixed flowspecs that can be chosen between on demand.

With an ATM network, before any packet can be sent, the call setup protocol (recently standardised as Q.2931 by the ITU), is invoked to setup path, call and resources needed. The binding of all these is needed up front. There isn’t yet any way of aggregating calls, as there is in RSVP through clever filters. Long term calls might be configured through network management to use PVCs, to deal with the intermittent bandwidth problem above (a PVC allows a receiver to control specification of a flow, counter-intuitively).

The ATM and Q.2931 specifications list a huge number of QoS parameters including:

The Internet Community has developed a standard protocol for audio and video and other image distribution applications to use to carry their data around and provide a common platform to express some of the timing and session information needed by real time applications.

This is RTP and its associated control protocol, RTCP. RTP is simply a framing protocol. It contains no comprex exchanges of messages (handshaking), but rather leaves any conference control matters to higher levels.

RTP packets contain media types and media specific timestamps. These are used in adapative playout buffer schemes. RTCP packets carry source and receiver reports that describe the users, and the reception quality.

RTP uis usually multicast (even when there is only one sender and recipient) using the User Datagram Protocol (UDP) over IP multicast.

An alternative to IP+RSVP, and under some active research by IBM amongst others, is the ST-II protocol. ST is like IP, but has two added functions, one subsumes RSVP (its called the ST Control Message Protocol, SCMP) and the other is t support multidestination calls.

ST is not yet widely available, but it is used on one very large network called the DSINet (Defense Simulation Internet), which runs all around the world and allows NATO countries to use videoconferncing and access remote computer warfare simulations, hence it is quite important.