LAN Emulation brings legacy LANs onto the ATM bandwagon
Rex Baldazo
LAN Emulation (LE) may be the killer application that brings asynchronous transfer mode (ATM) networking into the mainstream. ATM is a fast, modern networking technology that is considered by many to be the biggest thing since Ethernet (see "On the Road to ATM," September 1994 BYTE). But corporations with huge investments in mission-critical applications running on Ethernet and Token Ring networks have been loath to make the transition, slowing the acceptance of ATM.
The reason was simple -- interoperability, or rather the lack thereof. Computers directly connected to an ATM network couldn't run legacy applications that depended on a LAN's unique properties. Instead
, the only way to bring some of the benefits of ATM to legacy networks required devices such as Ethernet-to-ATM switches (see "Merging ATM and Ethernet," August BYTE). But perhaps ATM's biggest strength is as an end-to-end solution, connecting desktops across the enterprise -- one network architecture, from LAN to WAN. LE is just the ticket, allowing legacy applications to run essentially unchanged, while also allowing the computers on which the applications run to be directly connected to the ATM network.
ATM was developed by telecommunications companies. It is based on fast ATM switches and is connection-oriented (see "All-Terrain Networking," August 1993 BYTE). In contrast, LANs such as Ethernet and Token Ring are based on a shared, not switched, medium, and the protocols are connectionless.
LE, which was developed by the ATM Forum's LAN Emulation Subworking Group, bridges the gap by hiding the underlying ATM network at the media access control (MAC) layer. This layer provides device-driver int
erfaces such as Open Data-Link Interface (ODI) and Network Driver Interface Specification (NDIS), so higher-level applications dependent on these protocols work without modification. A group of ATM stations acting as a traditional LAN is called
an emulated LAN
(ELAN).
Performing this magic requires four components: LAN Emulation Client (LEC), LAN Emulation Server (LES), Broadcast and Unknown Server (BUS), and LAN Emulation Configuration Server (LECS). (See the figure
"Getting from Here to There."
) The LEC resides on all ATM-attached stations (e.g., bridges and workstations) that are participating in the LE service. The three server components may reside on one ATM-attached workstation or on separate workstations. Some vendors may even implement one or more of the server functions inside an ATM switch.
The Client
The LEC is responsible for the MAC-layer connectionless service that hides ATM from LAN-based applications. In a bas
ic configuration, each LEC possesses two addresses: an IEEE-format 48-bit MAC address and a 20-byte ATM address. If the LEC is running on a bridging device such as ATM-to-Ethernet, the LEC might have multiple IEEE MAC addresses for which it is responsible.
When a new outgoing message arrives from a higher-layer entity to the LEC, that message includes a MAC address for the intended destination. The LEC must translate that address into the appropriate 20-byte ATM address, establish a connection (if one is not already open), and transmit the message.
The LEC begins by looking at the connections, called Virtual Channel Connections (VCCs), it has open. The LEC maintains a translation table of destination MAC addresses to VCCs. If the destination address for the new message is in the table, the LEC can simply send the message using the existing VCC.
If the destination address is not in the translation table, the LEC has to perform an address resolution using the LAN Emulation Address Resolution P
rotocol (LE-ARP). It sends an address-resolution request to the LES. When the LEC receives back the valid destination ATM address, it performs standard ATM signaling to establish a VCC and transmit the message.
LECs are able to register their ATM-to-MAC address translation with the LES. Then, when the LES receives an address-resolution request, it can reply directly with a message containing the matching ATM address. Otherwise, the LES must forward the message to the destination ATM station, which replies with the correct address.
Each LES entity represents one ELAN. On any ATM network, there might be multiple LESes maintaining independent networks. The LECS is responsible for maintaining configuration information about the various ELANs. An LEC is assigned to an ELAN based on the configuration stored in the LECS.
The BUS to Everywhere
When an LEC has a multicast or broadcast message to send, it does not know a priori the MAC addresses of all the recipients. Even if
it did, repeatedly querying the LES and setting up an ATM VCC for each station would be wasteful of bandwidth and computing resources. The solution is the BUS.
During the initialization of an LEC, it has to determine the ATM address of the BUS. It transmits to the LES an address-resolution request for the broadcast address (hexadecimal FFFFFF) and receives back the ATM address for the BUS. The LEC must then establish a VCC to the BUS.
ATM supports a one-way point-to-multipoint broadcast mechanism. One station becomes the root. It sets up one-way VCCs to each receiving station. The BUS sets up such a tree, with the BUS as the root node and all stations of the ELAN as branches. This tree is maintained as long as the ELAN is in service. New LEC stations joining the ELAN are added to, and stations leaving the ELAN are pruned from, this broadcast tree.
Thus, the BUS has several two-way VCCs, one to each LEC, that are established during the initialization of each LEC. The BUS also maintains a one-
way broadcast tree to those same LECs. Data to be broadcast from each LEC, as well as control information between the BUS and LECs, travels on the two-way VCCs. The BUS uses the one-way broadcast tree to send the actual broadcast messages.
It is important to mention here a limitation of the LE scheme. To achieve its high bandwidth, ATM relies on fixed-size packets called cells. An ATM cell contains 53 bytes (48 bytes of payload and a 5-byte header containing the VCC), an error-control code to protect the header, and some control bits.
The format of the payload is left up to what are called ATM Adaptation Layers (AALs). LE uses AAL5, which is the most efficient in terms of the 48-byte payload. Other AALs use part of each cell's 48-byte payload for things such as cyclic redundancy checks (CRCs) and sequencing numbers. This allows multiplexing different cell streams onto the same VCC, but it wastes part of every cell's payload. LE eschews such services by using AAL5, which breaks up an incoming messa
ge into 48-byte blocks and passes them onto the ATM physical layer for transmission.
The upside is efficient use of bandwidth. The downside is that the BUS is limited to sending out a broadcast message from only one LEC at a time. The BUS has to accumulate all the cells of a broadcast message, unpack them into the original frame to make sure a valid frame has been received, and repackage and send out the broadcast message. Incoming broadcast messages from other LECs must be queued up, awaiting their turn.
The LEC sends to the BUS all messages for which the LEC does not yet know the corresponding ATM address. This includes broadcast and multicast messages. However, it also includes any regular message whose destination address has not yet been received from the LES. This is where the "Unknown" component in the BUS acronym comes from.
As mentioned earlier, when an LEC has a message with an unknown destination MAC address, it transmits an address-resolution request to the LES. While awaiting th
e reply from the LES, the LEC does not sit idle. It begins transmitting the message to the BUS. If the LEC receives an ATM address from the LES, the LEC stops transmission to the BUS and connects directly to the destination station. Thus, some frames may arrive at a receiving station from a VCC connected to the BUS, and some from a VCC connected directly to the source LEC.
This may be undesirable in some cases. In a shared medium such as 802.3 and 802.5 LANs, frames will usually arrive in order. But in an ELAN, where some frames get sent via the BUS and some over a direct LEC-LEC connection, there is a real possibility the frames will arrive out of order. So the LE specification includes an optional flush protocol.
The sending LEC suspends transmission of the data frames and transmits a flush message down the old path, in this instance to the BUS. The BUS in turn broadcasts the flush message to all the stations in the ELAN. The destination station whose address matches the flush message replies to
the flush. When the sending LEC receives this response, it begins transmitting again on the new path, in this case the direct VCC to the destination LEC.
Still on the Road to ATM
The success of technologies such as switched Ethernet and fast Ethernet is not due solely to technical merit. These technologies leverage the existing investment in software, providing greater throughput without requiring a total rewrite of all applications. This lesson has not been lost on the ATM Forum.
All the extra protocol baggage may seem like a lot of effort on the part of an ATM network just to accommodate old LAN software. But it is probably the key to the acceptance of ATM. It allows incremental deployment of ATM. You can replace the physical wiring of your existing LAN with an ATM network but keep existing applications intact. When you're ready, you can make the leap to applications that take full advantage of ATM.
Of course, dangers lie ahead. Early implementations of LE may hav
e initial interoperability problems, as with any new specification. And because the specification leaves open the question of where the various servers reside -- on one or multiple machines, or even in the ATM switch itself -- there will be numerous solutions offered from numerous vendors. You may not be able to take one vendor's LES and another's BUS. Pick one vendor's solution and stick with it for now. It's going to be a minefield for the IS department, but with users clamoring for bandwidth, you will have to negotiate that minefield sooner or later.
LAN Emulation Client --
a software driver that runs on a network client
LAN Emulation Server --
maintains a mapping between ATM and LAN addresses
Broadcast and Unknown Server --
maintains lists of Virtual Channel Connections
illustration_link (16 Kbytes)
For two virtual LAN clients to make a connection, a client first queries the LAN Emulation Server for the destination client's asynchronous transfer mode (ATM) address. The server looks up the address and determines the appropriate path (over the ATM network) to that address.
Rex Baldazo is a BYTE technical editor. You can reach him on the Internet or BIX at
rbaldazo@bix.com
.
ATM with a Twist of LAN
