IPX, NetBEUI, and TCP/IP running on ATM networks; and the recently developed IP over ATM specification (outlined in RFC 1577 and RFC 1483) adapts TCP/IP for ATM networks.
Of course, you can eschew standards and marry your code to a particular hardware vendor's network adapter design--each vendor offers a proprietary interface that your software can use. But in a rapidly changing technology segment like ATM, you'd better be sure you've found true love before you tie the knot.
ATM Advantages
There are a number of advantages for applications that truly speak ATM. First, programmers can write applications that mix voice, text, and video together as needed. ATM-enabled applicatio
ns can run without any delays caused by concurrent network traffic. A new generation of software will use ATM to let computers share data without the pretense of mapped phantom drive letters, phantom folders, and phantom file systems.
Why do we need a new generation of software to handle ATM? Because ATM is a connection-oriented protocol that contains a connection identifier in every cell header (see the figure
"Why ATM Is a Challenge for Programmers"
). ATM establishes a link between two computers to transfer data. Traditional networks, including Ethernet, are connectionless: Systems communicate over a network bus rather than via direct connections. The connection identifier explicitly associates a cell with a given virtual channel on a physical link. The connection identifier consists of two subfields, the virtual channel identifier (VCI) and the virtual path identifier (VPI). The VCI and VPI allow ATM hardware to multiplex, demultiplex, and switch cells throughout a network. VCIs
and VPIs are connection handles, not addresses. ATM assigns them at each segment (the link between ATM nodes) when an application creates a connection, and the VCI and VPI exist for the duration of the connection. ATM can asynchronously interleave (multiplex) cells from multiple connections by keeping track of VCIs and VPIs.
At present, transport protocols such as IPX, NetBEUI, and TCP/IP and their APIs do not understand VCIs and VPIs. Applications have no way to tell the underlying network the priority of the message or the bandwidth needed to send it. Network-operating-system (NOS) vendors are working on these issues. Both Microsoft and Novell have announced plans for connection-oriented abstraction layers that are likely to broadcast routing information and service advertising packets more frugally over ATM and to optimize packet sizes for ATM's cell-oriented architecture. Both efforts should make ATM-aware programming easier in the future. Until then, WinSock 2.0, LANE, and IP over ATM are the best
choices.
WinSock 2.0
Microsoft and Intel codeveloped WinSock 2.0, the new 32-bit edition of the popular WinSock interface. For compatibility with version 1.1, WinSock 2.0 includes the standard WinSock calls that let you create communications links, send and receive data over those links, and take down the links at the end of a session. To support ATM, WinSock 2.0 accommodates quality of service, which lets applications negotiate required service levels for bandwidth and latency as well as use socket grouping and prioritization. Version 2.0 also permits protocol-independent multicast and multipoint message transmission.
In WinSock 2, the
bind()
and
WSPBind()
functions use a
sockaddr_atm
data structure to register a Service Access Point (SAP). A SAP is a software connection point that behaves in many ways like a socket. The data structure contains information about incoming connection requests. SAP registration lets WinSock match an incoming connection
request SAP to the SAP of a listening socket. For point-to-point connections, the
sockaddr_atm
data structure also lets you specify the destination SAP for calls your program makes to the
connect()
,
WSAConnect()
, and
WSPConnect()
functions. For point-to-multipoint connections, you use the same data structure in calls to
WSAJoinLeaf()
and
WSPJoinLeaf()
. The WinSock 2 specification natively supports ATM point-to-point and point-to-multipoint connection setup and teardown.
To handle ATM, WinSock 2 introduces the notion of a socket group as a means for an application (or cooperating set of applications) to tell an underlying service provider (i.e., a dynamic library or device driver) that all sockets in a particular set are related and that the resulting socket group has certain common ATM attributes. These ATM attributes include relative priorities of the individual sockets within the group, as well as a group quality of service specification. For examp
le, applications running on different ATM nodes that want to exchange streams of multimedia data can give an audio stream a higher priority than a video stream.
You use the
WSASocket()
and
WSAAccept()
functions to explicitly create or join a socket group, and you can use
getsockopt()
to retrieve socket-group IDs.
WinSock is a relatively easy specification for programming. However, we probably won't see a final specification until early next year. Even then, WinSock will work only for Windows, so if cross-platform applications are important for you, you need to find another API.
LAN Emulation
While WinSock 2.0 offers a new ATM-aware API, LANE focuses on making existing applications run on ATM. LANE is particularly suited for helping ATM act as a LAN backbone for Ethernet or token-ring hubs, bridges, switching hubs, and routers. LANE specifies ways for LAN traffic to flow between client computers and an ATM-attached file server without the need for
a separate router. To do this, the specification hides ATM from the LAN nodes, so that each client and server uses a non-ATM-specific protocol stack.
LANE doesn't replace routers or routing: It provides a complementary MAC-level service. This service works with the MAC-layer switching that occurs in the hubs and wire closets of large LANs. The MAC-layer service also provides interoperability between current applications and ATM networks. It also lets you use existing drivers and popular LAN communications protocol APIs, such as NetBIOS, TCP/IP, and IPX. However, LANE does not take advantage of ATM's potential to provide particular connections with a higher quality of service.
The specification describes how ATM can take on the appearance of a legacy physical layer medium, such as Ethernet or token ring, by providing a layer of software that translates, for example, among your program's NetBIOS calls, or your program's IPX calls, and the underlying ATM network.
LANE defines the way the thre
e primary characteristics of IEEE-802 LANs (connectionless transmissions, broadcast/multicast messages, and hard-wired MAC addresses) work over ATM networks, which are connection-oriented, use point-to-point messaging, and have network-defined telephone-number-like addresses. An address-resolution protocol within LANE discovers the ATM address corresponding to a given MAC station address (whether the station is ATM-attached directly or connected via Ethernet/token ring) and constructs a virtual circuit between the end points. For broadcast and multicast IEEE-802 packets to travel over the network, a LANE server uses point-to-point circuits inbound and point-to-multipoint circuits outbound to direct the traffic. The LANE specification details the packet formats and packet encapsulations necessary for ATM to pretend to be some other physical layer, and it defines how an ATM adapter in a host can present an Ethernet or token- ring logical interface to the protocol stack in that host.
LANE can slow down you
r communications links because it's an extra insulating layer of software, but existing IPX, NetBIOS, and TCP/IP programming techniques work with LANE, and it is readily available.
IP over ATM
Based on work by the Internet Engineering Task Force (IETF) and others, two recent RFCs have helped IP become ATM-aware. The specification defines how to put IP packets and ARP requests directly into protocol data units and convert them to ATM cells. This is necessary because IP does not recognize conventional MAC-layer protocols, such as those that are generated on an Ethernet LAN.
RFC 1483 defines the encapsulation of IP datagrams, while RFC 1577 specifies how IP-oriented address resolution works on ATM. Both standards treat ATM as a direct replacement for the local LAN segments that connect IP nodes and routers in a non-ATM IP-based LAN. In its discussion of address resolution, RFC 1577 defines an ATM-oriented protocol for logical IP subnets (LISes). Within a LIS, IP addresses map direc
tly into ATM Forum's (Foster City, CA) UNI 3.0 addresses.
From a programming point of view, you'll interface to IP over ATM with a socket-oriented API similar to the version 1.1 set of standard WinSock function calls. These calls let you open sockets to establish TCP/IP communications links, send and receive messages across those links, and tear down the links when you're finished.
IP over ATM makes better use than LANE of larger packet sizes and handles unicast traffic more efficiently. However, IP multicast traffic will likely require tunneling over ATM (i.e., encapsulation of multicast packets inside broadcast messages), which might make IP over ATM less efficient than LANE.
Vendors are currently developing drivers for IP over ATM, which means you won't be able to use it right away. When it's available, IP over ATM will be as easy for programmers to use as WinSock.
Three Choices
Once you've made your API selection, there's one more issue you need to address: ATM i
s new enough that you'll also need to make sure your hardware manufacturer can supply the drivers for your chosen approach. ATM programming isn't perfect, but these technologies are steps in the right direction.
illustration_link (26 Kbytes)
Programmers don't have an easy way to write applications that take advantage of ATM's connection-oriented networks.
illustration_link (32 Kbytes)
Barry Nance is a BYTE consulting editor and has been a programmer for 25 years. You can reach him at
barryn@bix.com
.
Teach Your Apps to Speak ATM
