• IP Multicast
• MIME
• RTP
• ST-2
• RFC 741
• Xv and mvex

Name: IP Multicast

Reference: RFC 1112

Version: August 1992

Sponsoring body: IETF Network Working Group

Status: Internet standard

Brief description: The extensions required to a host implementation of the Internet Protocol (IP) to support multicasting.

Detailed description: IP multicasting is the transmission of an IP datagram to a host group, which is a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of a destination host group. The membership of the host group is dynamic. A host group may be transient or permanent.

Multicasting of this nature is essential to optimise bandwidth usage for multiparty conferencing applications.

Internetwork forwarding of IP multicast datagrams is handled by multicast routers. The special routing requirements of multicast IP can be met in several different ways. There are extensions to the OSPF and BGP routing methods, and there is a new routing method (CBT - Core Based Trees). At the time of writing, it seems that CBT is likely to be adopted as the appropriate method of routing multicast IP.

Products: vat, nv, ivs, NEVOT, sd and other remote conferencing tools use IP multicast. Multicast support is available as kernel patches for SunOS 4.x.x, and is built in to SunOS 5.

Further information: There are mailing lists concerned with IP Multicast backbone operations at the following addresses:

mbone-uk@nosc.ja.net (GB)

mbone-eu@sics.se (Europe)

mbone-oz@internode.com.au (Australia)

mbone@isi.edu (US and World)

Patches to various UNIX system kernels to provide multicast support are available from: gregorio.stanford.edu:/vmtp-ip.

Date of entry: 15 December 1992

Name: MIME

Reference: RFC 1341

Version:

Sponsoring body: Internet Architecture Board

Status: Proposed Internet Standard

Brief description: Multipurpose Internet Mail Extensions

Detailed description: MIME supports not only several pre-defined types of non-textual message contents, such as 8-bit 8000Hz-sampled u-LAW audio, GIF image files, and PostScript programs, but also permits you to define your own types of message parts. A typical MIME mail reader might:

Display GIF, JPEG and PBM encoded images, using eg 'xv' in X windows.

Display PostScript parts (eg something that prints to a PostScript printer, or that invokes GhostScript on an X windows display, or that uses Display PostScript.)

Obtain external parts via Internet FTP or via mail server.

Play audio parts on workstations that support digital audio.

RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. RFC1341 redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, RFC 1341 is largely orthogonal to (rather than a revision of) RFC 822.

MIME is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by co-operating mail agents.

An associated document, RFC1342, extends Internet mail header fields to permit other than US-ASCII text data.

Products: Many mailers which support MIME are now available.

Further information: The specification is available as RFC 1341: "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", N. Borenstein & N. Freed.

Other associated RFCs are:

RFC 1342: "Representation of non-ASCII text in Internet message headers", K. Moore, June 1992

RFC 1343: "User agent configuration mechanism for multimedia mail format information", N. Borenstein, June 1992

Edward Vielmetti (emv@msen.com) is preparing a FAQ on MIME. See also the newsgroup comp.mail.mime.

Date of entry: 21 December 1992

Reference:

Version: October 27,1992

Sponsoring body: IETF Audio/Video Transport Working Group

Status: Internet Draft (expires 1st April 1993)

Brief description: A Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications

Detailed description: Services typically required by multimedia conferences are playout synchronisation, demultiplexing, media identification and active-party identification. RTP is not restricted to multimedia conferences, however, and other real-time services such as data acquisition and control may use its services.

RTP uses the services of an end-to-end transport protocol such as UDP, TCP, OSI TPx, ST-2 or the like. The services used are: end-to-end delivery, framing, demutliplexing and multicast. The network is not assumed to be reliable and is expected to lose, corrupt, delay and reorder packets.

RTP is supported by a real-time control protocol (RTCP). Conferences encompassing several media are managed by a reliable conference protocol not discussed in the RTP draft.

The draft summarises some discussions by the AVT (audio/video transport) working group. The draft builds on the operational experience with Van Jacobson's and Steve McCanne's vat audio conferencing tool as well as implementation experience with Henning Schulzrinne's NEVOT network voice terminal.

Other protocols and standards referred to are:

NVP - Network Voice Protocol RFC741

G.764 and G.765 - CCITT recommendations for packet voice

The design goals of RTP are:

media flexibility

extensible

independent of lower-layer protocols

gateway compatible

bandwidth efficient

international

processing efficient

implementable

Services provided are:

framing

demultiplexing by conference/association

demultiplexing by media source

demultiplexing by media encoding

synchronisation between source(s) and destination(s)

error detection

encryption

quality-of-service monitoring

RTP consists primarily of protocol header for real-time data packets. In the typical case, the RTP header is just 8 octets long and composed of the following fields:

protocol version (2 bits, value 1)

flow identifier (6 bits)

option present bit

synchronisation bit (marks end of synchronisation unit)

content type index (6 bits)

packet sequence number (16 bits)

timestamp, middle 32 bits of NTP-format timestamp

Products: vat, NEVOT

Further information: This draft is available by anonymous FTP from: ftp.ripe.net:/pub/internet-drafts/ in the files:

draft-ietf-avt-rtp-00.txt

draft-ietf-avt-encoding-00.txt

draft-ietf-avt-profile-00.txt

draft-ietf-avt-issues-00.ps, .txt

Date of entry: 15 December 1992

Name: ST-2

Reference: RFC 1190

Version: 2

Sponsoring body: Internet Network Working Group

Status: Internet Standard

Brief description: This memo defines the Internet Stream Protocol, Version 2 (ST-2), an IP-layer protocol that provides end-to-end guaranteed service across an internet.

Detailed description: This specification obsoletes IEN-119 "ST - A Proposed Internet Stream Protocol". ST-2 is not compatible with Version 1.

ST-2 is an internet protocol at the same layer as IP. It differs from IP in that it requires routers to maintain state information describing the streams of packets flowing through them.

ST incorporates the concept of streams across an internet. Every intervening ST entity maintains state information for each stream that passes through it. The stream state includes fowarding information, including multicast support for efficiency (required for multiparticipant conferencing) and resource information which allows network or link bandwidth and queues to be assigned to a specific stream. This pre-allocation allows data packets to be forwarded with low delay, low overhead and low probability of loss due to congestion. This allows ST-2 to give a real-time application the guaranteed and predictable communication characteristics it requires.

The data stream in an ST-2 connection is essentially one-way, except that there is a reverse-direction channel for control messages.

Transport protocols above ST-2 of interest to multimedia applications include Packet Video Protocol (PVP) and the Network Voice Protocol (NVP), which are end-to-end protocols used directly by applications.

Products: Implementations by SICS (SE) and BBN (US) exist.

Further information: "An Implementation of the Revised Internet Stream Protocol (ST-2)", C. Partridge and S. Pink, Journal of Internetworking: Research and Experience, March 1992.

Date of entry: 15 December 1992

Description: Network Voice Protocol

Description: X extensions to incorporate video. Xv is implemented in DEC's XMedia toolkit. See the XMovie entry in the Research section for another alternative.