ctively deliver multimedia applications over LANs and WANs.
Multimedia traffic has one distinguishing characteristic: It's time-sensitive. Different data types, especially voice, must arrive at their destination at the right time or the multimedia application loses its effectiveness. For example, if the audio portion of a video
conference is out of sync with the video components, you get "dubs disease," the illness that afflicts foreign actors when a producer decides to use dubbing instead of subtitles.
Vendors are addressing the problem of synchronization by assigning a quality of service (QoS) to a multimedia application. QoS identifies an application as time-sensitive and requiring priority over other, less time-sensitive ones. But where is the best place to handle QoS? The network (i.e., routers, hubs, and switches)? The OS? Or some combination of hardware and OS working together?
Leveraging Today's Infrastructure
If you already have an Ethernet LAN, it's impractical and expensive to replace it. Instead, you need an economical method of extending your network to accommodate multimedia applications. Enter isochronous Ethernet (aka IEEE 802.9a, ISLAN-16T, or isoEthernet).
The premise behind isochronous Ethernet is that voice--not audio or video--is the critical component in multimedia comm
unications. During a conversation, even the slightest delay creates a major disruption. Echoes caused by delays can confuse even the most articulate speakers. A split-second delay can disrupt a simple two-way conversation by causing one participant to repeat a question, only to interrupt the other's answer. If you've ever experienced a telephone conversation via a round-trip satellite link, you know the annoyance of delay.
Isochronous Ethernet adds multirate ISDN to standard Ethernet. The marriage of Ethernet and ISDN guarantees QoS for voice in networked multimedia applications. In addition, isochronous Ethernet works with H.320, T.120, and MPEG videoconferencing, document conferencing, and video-distribution standards.
A network is isochronous when it operates in real time, with
time
defined by the worldwide-standard 8-kHz clock used for nearly all voice communications. Today's Ethernet networks are asynchronous and do not provide the 8-kHz clocking signal that the voice component of
a multimedia application--delivered through an H.320 codec, for instance--requires.
The IEEE 802.9a standard is the only LAN technology that extends 8-kHz clocking to the desktop. All others, including 25-Mbps asynchronous transfer mode (ATM), require buffering to smooth out traffic bursts and adaptation techniques to transmit and receive synchronous traffic, such as H.320 voice and video.
Isochronous Ethernet is a hybrid network that integrates standard 10-Mbps Ethernet (IEEE 802.3 10Base-T) LAN technology with 6.144 Mbps of isochronous (ISDN) bandwidth, for a total of 16 Mbps available to any user (hence the IEEE designation of Integrated Services Local Area Network, or ISLAN 16-T). Isochronous Ethernet uses an encoding scheme, called 4B:5B, that enables the total bandwidth to be 16 Mbps using the same 20-MHz clock that provides only 10 Mbps with the Manchester encoding scheme of traditional Ethernet (see the figure
"Ethernet + ISDN = IsoEthernet"
).
Isochronous Ethe
rnet provides 96 64-Kbps ISDN B channels over the same ubiquitous Category 3, unshielded-twist-ed-pair wire that 10Base-T uses. That's enough bandwidth for a multipoint videoconference with six participants, each using 384-Kbps speeds, with room to spare for interactive whiteboarding and presentation graphics. And there's still enough bandwidth left over for the participants to receive Group 4 fax, E-mail, and voice-mail messages over separate channels.
If isochronous Ethernet is a power user's dream come true, it's an MIS manager's delight. It's also one of the most attractive and affordable multimedia network solutions currently available. For starters, it's easy to integrate into an existing 10Base-T environment: All you have to do is put an isochronous Ethernet hub into your wiring closet. Multimedia workstations, outfitted with isochronous Ethernet adapter cards, connect to the hub. An attachment unit interface (AUI) provides connectivity between the isochronous Ethernet hub and existing 10Base-T
hubs.
According to the Isochronous Network Communication Alliance (or incAlliance), a loosely organized group of vendors that promotes the adoption and use of isochronous network technologies and products, about two dozen companies offer products that take advantage of isochronous Ethernet. National Semiconductor, the original developer of isochronous Ethernet, provides chip-level components and board-level subsystems for inclusion in products from such companies as Ascom Nexion, Ericsson Business Networks, Incite, and Luxcom.
A Proprietary Solution
3Com offers an alternative solution for networking multimedia applications over existing Ethernet networks. The company's Priority Access Control Enabled (PACE) technology is simple and inexpensive to implement: You just add a workgroup switch to connect the workstations running multimedia applications. You don't need to make any changes to existing cabling or Ethernet adapters, nor do you need to have any knowledge about any tec
hnology except Ethernet. Among the companies supporting PACE are Apple, Dell, Novell, Oracle, Silicon Graphics, Starlight Networks, and Sun Microsystems.
While isochronous Ethernet adds a timed channel to Ethernet, PACE addresses Ethernet's delivery timing and priority. To produce integrated, high-quality graphics and sound, multimedia applications need regular, predictable data delivery. But Ethernet delivery timing is unpredictable; under a full load, it experiences latency and jitter.
Latency
is the delay between the time transmission and reception of data.
Jitter
is the uncertainty in the arrival time of a packet.
PACE overcomes excess packet delay by using star-wired switching configurations and enhancements to Ethernet--which are all backward-compatible with existing Ethernet adapters. The technology uses traffic-control algorithms that enable each Ethernet segment to operate at more than 98 percent efficiency. These algorithms provide predictable LAN transmission by regu
lating the flow of traffic, thereby minimizing jitter. Best of all, because IEEE 802.3 Ethernet is essentially speed independent, the same enhancements work at Fast Ethernet speed (i.e., 100Base-T), which allows you to migrate from 10 Mbps to 100 Mbps.
Currently, however, PACE stops short of applying true QoS to multimedia traffic. In other words, Ethernet isn't perfect for multimedia transmission because it offers no priority-access scheme. All traffic must contend for access on a best-effort basis, which can cause delays in getting data onto the network in the first place.
PACE defines a method of prioritizing traffic over Ethernet to deliver true QoS. Although this technology is already built into a 3Com workgroup switch--the LinkSwitch 1000--as this article went to press, it was not yet in use. By the time you read this, 3Com should be implementing PACE, but it won't include a standard prioritization method.
The IEEE 802.1 working group has only recently agreed to begin addressing QoS
issues--specifically, the handling of prioritization in bridges--and it isn't expected to have anything for another 12 to 18 months. Meanwhile, 3Com will use--and publish--its own prioritization scheme, which offers two levels of service: high and low.
Multimedia over the Internet
Isochronous Ethernet and PACE deal with plumbing. That's fine if you have control over the hardware. But what if you don't? What if you're dealing with all sorts of physical media located all over the globe? In other words, what if you're dealing with multimedia applications running on the Internet, where the only thing you know for sure is TCP/IP?
One stumbling block for running multimedia applications over TCP/IP is the problem of delay. IP doesn't allocate a specific path or amount of bandwidth to a particular session. The resulting delay can vary wildly and unpredictably, wreaking havoc with real-time applications.
There are several proposed solutions to perform resource-setup functions
similar to that of Q.93x signaling in a circuit-switched network. The most promising of these is the Resource Reservation Protocol, or RSVP, developed by the Internet Engineering Task Force (IETF).
RSVP runs on top of IP to provide receiver-initiated setup of resource reservations on behalf of an application data stream. In other words, when an application requests a specific QoS for its data stream, RSVP delivers the request to each router along the path(s) of the data stream and maintains router and host states to support the requested level of service. In sum, RSVP essentially allows a router-based network to mimic a circuit-switched network on a best-effort basis. It even provides transparent operation through routers that do not support it.
At each router, the RSVP program applies a local decision procedure, called
admission control
, to determine if it can supply the requested QoS. If it can, the RSVP program in each router passes incoming data packets to a packet classifier that
determines the route and QoS class for each packet. The router then queues the packets in a packet scheduler that allocates resources for transmission on the link. If admission control fails at any node, the RSVP program returns an error to the application that originated the request.
The advantage of RSVP is that it works with
any
physical network architecture. It runs over Ethernet, token ring, ARCnet, or Fiber Distributed Data Interface (FDDI), as long as IP is the underlying network protocol. This makes RSVP suitable for use with companywide networks as well as for the Internet.
RSVP meshes well with IPv6 (previously known as IPng), so users can set up end-to-end connections with a specified amount of flow control for a given time. Time-sensitive services, such as real-time video and voice, get the special handling they require along the route path. How? IPv6 can label packets in traffic patterns, so applications can identify packets that belong to particular traffic flows for which
the sender requests special handling.
Although IPv6 standards are nearing completion, it could take a few years for the technology to be widely implemented throughout the Internet. Major networking vendors, including Bay Networks, Cisco, and 3Com, have indicated they will add support for IPv6 to their products in the third or fourth quarter of this year.
zz
Finally: ATM
Although all the resource management and flow-control techniques discussed thus far are implemented on a best-effort basis, if widely deployed they tie up lots of network bandwidth. In other words, we need more bandwidth. Enter ATM.
ATM uses 53-byte cells to carry voice, data, and video signals. By using a standard cell size, it can switch data via hardware, which is more efficient and less expensive than using software, the way X.25 and frame relay do. Hardware-based switching is also faster: ATM speeds are scalable and can exceed 2.5 Gbps over fiber.
In addition, ATM provides the features nece
ssary for successful multimedia applications. Specifically, it has the ability to define different traffic types, with each traffic type delivering a different QoS.
The traffic type that supports multimedia applications (see the table
"ATM's Touch of Class"
) is called constant bit rate (CBR) service. CBR supplies a fixed-bandwidth virtual circuit that addresses the special handling needs of delay-sensitive multimedia applications--those that contain real-time video and voice, for example. In ideal circumstances, the application negotiates QoS with the network. Applications do the negotiation through native ATM interfaces. If an application can't do this, interfaces such as ATM LAN emulation and classic IP over ATM (RFC 1577) do it instead.
QoS guarantees a certain level of performance: maximum cell rate, available cell rate, cell-transfer delay, or cell-loss ratio. The network reserves the full bandwidth that the application requested. There are no data-rate limits for CBR
connections, nor is there a limit on how long a connection can transmit at the maximum cell rate (technically called the
peak cell rate
, or PCR). The PCR is the maximum data rate the connection can support without risking data loss. Any traffic above the specified rate risks being dropped.
These and other advantages of ATM--including low latency, high throughput, and scalability--will one day make it the network of choice for supporting new, high-bandwidth multimedia applications, as well as legacy LAN and TCP/IP traffic. This realization has vendors and standards bodies looking to support upward migration to ATM networks.
National Semiconductor, for example, already offers an on-board segmentation and reassembly (SAR) component for isochronous Ethernet cards to support traffic over ATM links. 3Com plans to offer ATM connectivity through high-speed backbone switches--its own, or those of other vendors. However, when PACE traffic hits an ATM network, the advantages of PACE are left behin
d, leaving just ordinary Ethernet.
Multimedia OS?
With ATM looming as the dominant network architecture in the not-too-distant future, the next logical step is to develop an OS that allows applications to take full advantage of it. This is what First Virtual Corp. (Santa Clara, CA) is advocating.
FVC's Multimedia Operating Software is middleware that enables Windows applications to run over ATM. MOS runs invisibly under the application layer and above the network layer (see the figure
"Middleware Simplifies Networked Multimedia"
), bridging the gap between ATM and Microsoft Windows. Unlike other ATM solutions, which rely solely on LAN emulation, MOS brings ATM QoS directly to applications (resulting in high-quality voice, video, text, and images on the desktop) while leveraging the inherent management, security, and authentication features of the existing network OS (NOS).
Users running ATM-attached PCs still run the same applications and access
the LAN server as before, except they can also run network multimedia. MOS automatically handles QoS, based on the type of traffic. MOS has predetermined delay and bandwidth parameters for applications according to their bandwidth and delay needs. For example, MPEG traffic gets 1.5 Mbps of bandwidth, while an audio file gets 5 Mbps. H.320-based videoconferencing gets 384 Kbps, with a delay of 200 to 300 ms. All these services--including applications running over TCP/IP, IPX, and NetBIOS--can be delivered with guaranteed end-to-end quality using the existing desktop wiring infrastructure.
To implement videoconferencing, each PC must be equipped with a 25-Mbps ATM adapter with a direct connection to an H.320-based codec interface board. FVC's H.320-compliant Media Gateway Server (MGS) connects local ATM workgroups to remote sites via ISDN for videoconferencing across the WAN.
MGS is an integrated hardware and software package that upgrades a PC to an ATM/ISDN gateway with Basic Rate Interface (BR
I) or Primary Rate Interface (PRI) connections. You make your ISDN connection via MGS, which initiates external calls over the WAN through ISDN's Q.931 call-setup and management-signaling protocol.
Videoconferencing PCs communicate with each other or with the gateway via a 25-Mbps ATM connection to FVC's Media Switch. The ATM adapter and MOS provide ISDN redirection, setting up calls from one computer to another for videoconferencing.
The portion of MOS that resides on the PC sits between the applications and the LAN-emulation software, where it sets up real-time calls for voice, video, and audio. The software redirects Windows applications' real-time data streams from the local drive to a destination across the ATM network. In essence, this redirection spoofs applications into thinking they're executing locally.
When a DOS or Windows program requests a file, MOS consults a map to determine whether the file is stored on the LAN server or on the media server. If it's stored on the LAN serv
er, the request goes through the appropriate protocol stack normally. The LAN-emulation software on the adapter sets up an ATM call to the LAN server and segments the IP or IPX packets into 53-byte cells and sends them off. At the other end of the connection, the ATM-to-Ethernet adapter located at the remote port of the switch performs cell-to-packet resassembly and then passes the packets on to the local LAN server.
When the client requests a file that's stored on the media server, MOS sets up an ATM call and passes the request along to it. A component of MOS also resides on the media server, where its primary function is to handle client requests and retrieve data. At the core of this MOS component is a real-time kernel called the ATMOS, which performs call scheduling. This function enables the server to support up to 80 users simultaneously.
Do We Go to ATM from Here?
With the technologies, standards, and products for delivering multimedia solutions rapidly falling into p
lace, ATM looks like the long-term winner. Technologies such as isochronous Ethernet and PACE are viable solutions designed to fulfill emerging requirements for the isochronous bandwidth required by multimedia applications without forcing too much change to existing networks. However, the extent to which ATM is finally accepted--and within what time frame--are topics of continuing debate.
While many industry analysts have pegged the time frame for widespread deployment of ATM at 3 to 5 years, Mike Sodergren, National Semiconductor's director of strategic marketing, offers a contrary view. Although he is highly supportive of the technology, based on the present course of events, he projects a 10-year scenario for ATM deployment.
According to Sodergren, ATM appears to be technology-focused instead of application-focused, with vendors offering various upgrades of voice, video, and data networks on a stand-alone basis. There doesn't seem to be a concerted effort in the industry to address QoS issues
and the convergence of voice and data or to extend the massive investment in existing infrastructure.
"Until these things occur," says Sodergren, "lots of money will be spent without delivering to end users anything tangible in the networked enterprise. This accounts for the emphasis on isoEthernet, which blends wide bandwidth--Nx56/64-Kbps ISDN and Ethernet--in their native forms and offers future support for ATM for an integrated voice/data solution."
Sridhar Krishnaswamy, a senior architect at MCI's Intelligent Network Group, notes that there are no new requirements that carriers have to meet for isochronous Ethernet. According to Krishnaswamy, "The carriers already support ISDN for high-quality isochronous transmission over digital circuits and employ Q.931 signaling for fast call setup. ATM, on the other hand, requires that major changes and additions be made to the network infrastructure. When it comes to developing and deploying multimedia applications, it would seem that isochronous-Eth
ernet-based solutions would be easier than those that require ATM end-to-end."
Two other developments support these views. The ATM Forum recently abandoned its plan to develop an API for ATM, making it unlikely that a single, commonly accepted interface for ATM applications will emerge anytime soon. In addition, the IEEE 802.9 working group will be asked in March to take up the development of a standard for a 100-Mbps version of isochronous Ethernet. This would not only elevate isochronous Ethernet into the "long-term solutions" category for multimedia applications but could put a choke-hold on ATM.
As you can see, ATM will not be the ultimate solution that satisfies the needs of every organization or situation. In a way, that could be beneficial. It means there's no need to hold off deployment of multimedia applications until something like ATM becomes more widely available.
Of course, it also means that since ATM is not the nirvana that will satisfy all multimedia-delivery problems, man
agers will still have to use a combination of technologies to ensure the timely delivery of multimedia data streams over their corporate networks.
Fortunately, the combination of data-link and network-layer technologies, such as isochronous Ethernet and PACE, combined with OSes that take advantage of higher-layer services (like the QoS offered with ATM and ISDN), should give most companies enough leeway to
design a total system
for carrying their multimedia traffic.
WHERE TO FIND
First Virtual Corp.
Santa Clara, CA
Phone: (408) 988-7070
Fax: (408) 988-7077
3Com Corp.
Santa Clara, CA
Phone: (800) 638-3266 or (408) 764-5000
Fax: (408) 764-5001
Internet:
http://www.3com.c
om
Multimedia Over the Network
