Network Computingwww.networkcomputing.com

LANE: The Basics

LANE comprises four components: a LEC (LAN Emulation Client), a LECS (LAN Emulation Configuration Server), a LES (LAN Emulation Server) and a BUS (Broadcast and Unknown Server). Everything begins with the LEC's NSAP (Network Service Access Point) address. When a LEC starts up, it first tries to contact its LECS. This can be accomplished by using hard-coded NSAP address, a standardized NSAP address, a known VPI/VCI (virtual path identifier/virtual channel identifier), or an ILMI (Integrated Local Management Interface) to the switch (see "Initializing a LEC To Communicate With Other LECs," below).

Each LECS maintains a list of all the LECs that belong to that ELAN (emulated LAN). By contacting a LECS, a LEC can determine which ELAN it belongs to, and which LES and BUS to contact. In most installations, the LECS, LES and BUS are the same switch or router, as the operation of the LECS is not overhead-intensive, and the LES and BUS functions are closely tied. The LES/BUS is the brains behind the ELAN, providing the mapping necessary for the computers on the ATM network to communicate with one another and with Ethernet or token-ring IP systems. When the LEC contacts the LES, the LES records and maps the LEC NSAP and MAC (Media Access Control) addresses.

ATM was not designed to "broadcast" data blindly, but to deliver traffic from point A to point B on a dedicated VC (virtual circuit). The BUS provides all the broadcast services to the ATM world that we take for granted on an IP network--not only for the LECs, but for the LES as well. When a LEC needs to communicate with a machine for the first time, it will contact the LES to obtain the NSAP or MAC address of the destination device. The LES will then perform a lookup within its own database and provide the needed information to the LEC. If, however, the LES does not have the information, it will look to the BUS to broadcast a query to find the needed information. The BUS will then send the LE_ARP (LAN Emulation Address Resolution Protocol) via a multicast VC to all LECs in the ELAN. Although all LECs are registered with the LES, they can act as proxies for clients of which the LES is unaware; therefore, a broadcast message must be sent to each LEC so it can help find the requested recipient.

This procedure has been the basis for LANE, and has allowed ATM clients to communicate with pure IP-based clients--but there are flaws. The biggest problem is the inability to have more than one LES/ BUS on any ELAN. If the single LES/BUS were to go down, all new lookups or transmissions would stop until it was back online. Furthermore, if the LECS were to go down, no new clients could be added, as there would be no way for them to contact the LES/BUS.

Enter the Next Version

The biggest thorn in LANE's side has been the lack of redundancy, but version 2 fixes this problem with the addition of LNNI (LANE Network-to-Network Interface). LNNI provides communication services between redundant servers on the ELAN. While LNNI allows redundant servers on the network, not every LECS may be active at once. Since the LECS provides initial information to a LEC and are located via known methods, it would be confusing for more than one LECS to respond on an ELAN at a given time. Instead, a LECS in a LANE 2 network is designated as master or slave. The master LECS provides all information to the LECs, while communicating any database changes to the slaves via LNNI. The master continues communication with the slaves at regular intervals. If this does not occur, the highest priority slave will assume the master is no longer working and will come online as a replacement master, responding to new LECs that join the network.

If the master LECS had been located via a hard-coded NSAP address or a standardized address, the new master will change its NSAP to match the one for which the LECs is looking. If the old master returns to the network, the slave will relinquish control to the master. These address changes need to occur as with any addressing scheme--two devices cannot share the same address, and LANE cannot provide multiple addresses for the same services.

Redundant LES/BUS operation is different, but still relies on successful LECS operation. Since a LEC is given its LES address by the LECS, the LECS maintains a full list of every LES/BUS active on an ELAN. The LECS will pass a valid LES address to the LEC to use. If that LES becomes unavailable, the LEC reconnects to the ELAN by contacting the LECS and acquiring another LES address. For each LES to be able to handle all new requests from LECs, each one updates the others via LNNI with its complete cache information. Thus, each LES maintains a complete picture of the current network and LECs. Each BUS also uses LNNI to update each other in the same manner.

All the traffic on an ELAN consisted of UBR SVCs (unspecified bit rate switched virtual circuits) prior to the arrival of LANE 2, which is also capable of delivering ABR (available bit rate) traffic. LANE 2 also adds functions to the connections that allow flow multiplexing. Previously, a separate VC had to be created for each one-way conversation. Therefore, if two workstations were transmitting files, a VC would be created from workstation A to workstation B, and a second VC would be created from B to A if B needed to acknowledge receipt from A. Flow multiplexing allows multiple conversations to take place over the same VC as long as the QoS is the same.

Bus 'em Out

To lessen the amount of data the BUS has to multicast, LANE 2 introduces selective multicast, which lets a LEC registered with the BUS specify which multicasts it wants to be part of. The BUS keeps a list of multicasts and which LECs to include in those multicasts. This can be extended so that only devices capable of routing to other ELANs receive LE_ARP requests. Additional load can be taken from the BUS if the LECs create their own VC mesh between them.

While the BUS carries all multicast traffic by default, a new device--the SMS (selective multicast server)--can be introduced to the ELAN for dedicated multicasts. The SMS creates a multicast group containing all the LECs that will receive the SMS transmission.

Send your comments on this story to Darrin Woods at dwoods@nwc.com.