After about three years of being sold on the idea of ATM networking, we’re still waiting for it to arrive in earnest. The myth of what ATM will do eclipses the reality of what ATM is currently capable of doing.
Asynchronous transfer mode hardware still doesn’t support voice traffic, so the goal of data/voice network integration remains in the distance. And though MPEG has been emerging as a standard video- transmission format, the H.320 and JPEG video standards are still unsupported.
Scalability in network size is also not really available, outside of a choice between 155M-byte OC-3 and 100M-byte TAXI (Transparent Asynchronous Transceiver Interface). Investing in large-scale ATM switches is not practical until all of the ATM standards have stabilized.
There have been quite a few announcements of WAN-capable ATM switches, but vendors are waiting for ATM to become more available from the public carrier services. LAN ATM switches have also started to appear, with total sales of around 25,000 ports for all vendors.
Desktop ATM products have started appearing, as well, first in the Sun Microsystems Inc. SBus market. More recently, they have materialized for EISA and PCI systems, as proprietary, vendor-specific LES (LAN Emulation Service) products have become available.
PC Week Labs has started testing LAN ATM products, but all we have been able to test, to this point, is performance.
What’s not there
Why can’t we test the features that make ATM unique? Because none of them are available yet. We’ve posed the same query to every vendor: “How do we test quality of service?” The answer, right now, is that we can’t. In the first place, there is no standard API for writing ATM-aware applications. The ATM Forum isn’t even attempting to define one, deciding instead to develop a framework for ATM APIs. So the chances of a standardized API appearing in the near future are nil. Second, although LES is now availab le, the standards document isn’t expected from the ATM Forum until mid-1995. Currently, we’ve seen LES built into switches, running as a service on Windows NT, and as an NLM on NetWare.
LES itself is still not complete. It is possible to use an ATM switch, such as the Bay Networks Inc. LattisCell/EtherCell combination, which can support 12 virtual networks in the ATM switch (an individual network on each of the 12 Ethernet ports on the EtherCell). Unfortunately, one piece that isn’t in place yet would let you support multiple LAN-emulation servers on the same network, so it’s not yet possible to actually use this solution.
The ATM Forum recently decided how to handle congestion control on the network, which has also been a major stumbling block for ATM deployment. Over the last year or so, a religious war erupted between the proponents of two defining technologies–rate-based and credit-based congestion control. After much debate, the Forum voted to make the standard congestion-control methodology rate-based (see sidebar at left). This argument alone was probably responsible for a large part of the delay in introducing ATM products to the market.
Battle of the bandwidth
One of ATM’s most advantageous features is the use of SVCs (Switched Virtual Circuits). ATM offers two circuit types, SVC and PVC (Permanent Virtual Circuit). SVC’s strong suit is that a network’s bandwidth needs are negotiated before the circuit is established, then the bandwidth is released when the circuit is no longer necessary.
Right now, SVCs are not available except, in some cases, within switches being sold by the same vendor. All other ATM circuits use PVCs. When SVCs are available, there is little interoperability between switches from different vendors. For example, Bay Networks’ LattisCell products support SVCs based on the UNI (User-Network Interface) Specification 3.0; the Cisco Systems Inc. Lightstream 2020 also supports SVCs, but uses the Q.93B signaling standard; and the 3Com Corp. CellPlex 7000 supports SVCs using th e Q.2931 signaling standard. Three major vendors, three different implementations. Just to continue the confusion, the UNI 3.0 standard has been supplanted by the UNI 3.1 specification. Most vendors expect to default to supporting both.
The ongoing status of network-interface standards has also made significant headway. The UNI for both public and private networks was updated to Version 3.1 and defines services for both virtual path and virtual channel connections. The NNI (Network-Network Interface) public network standard was released in August 1993, but the private- standard NNI is still incomplete. Version 1.1 of B-ICI (Broadband-InterCarrier Interface) was released in October 1994 and supported only PVCs, with SVC support due in the n ear future.
The ATM Forum has also agreed to define the ABR (Available Bit Rate) service type, with a definition due in August. ABR is one of the missing links in AAL (ATM Adaptation Layer) 5. It specifies the support for variable-bit-rate traffic with flow control, and defines the minimum guaranteed data-transmission rate and specific performance parameters. A well-defined ABR specification is necessary to enable common LAN protocols to operate correctly.
ATM-based network interface cards and LAN switches are available for purchase (or will be in the immediate future) at three data rates, the 155M-bps OC-3 SONET standard, 100M-bps TAXI, and 25.6M bps over UTP/CAT3. The latter is the most interesting implementation, as it was voted down by the ATM Forum when originally proposed by IBM, but was successfully resurrected by IBM and a group calling itself the Desktop ATM25 Alliance.
IBM donated its 25M-bps ATM research to the Forum, and the standard is due to come up for a vote again. It is likely to pass, along with other pending standards primarily related to European and Japanese sites. Additional future standard sets also include the 622M-bps SONET STS-12 technology.