What is LANE?
Why Do We Care?
By Tom Van Meter, Senior Consultant

LAN Emulation (LANE) is a hot topic in the campus ATM environment. It basically allows us to mimic a broadcast environment in a circuit switched environment. Both Ethernet and Token Ring Local Area Networks have an inherent capability to send a transmission to everyone at the same time. But in an ATM environment, a connection must be established to a device prior to communicating with that device. This means that for IP, you would need a connection to a client before you could ARP for that client to talk to it. This is a catch 22, because in IP you must send a broadcast (an ARP) before you can talk with a device, but in ATM you must have a connection to the device before you can broadcast to it. So how do we solve this problem? We come up with a way to provide the same features the broadcast environment provides in the connection- oriented ATM world. We provide a capability for broadcasting. We also provide a way to map the ATM addresses of the devices participating in the artificial or 'emulated' LAN to MAC addresses. Since the LAN is artificial inside an ATM cloud, nothing prevents us from having many logical artificial LANs. Therefore, we also identify a way to record all the possible artificial or Emulated LANs. Let's briefly describe those services. Then we'll follow that up with a little more detail.

Specifically, we identify a service that runs in the ATM cloud that provides a broadcast capability. Every device participating in the artificial LAN must have a connection to that broadcast service. That way you send all MAC broadcast traffic to the ATM broadcast service. The broadcast service then forwards the broadcast to every device it has a connection to, which is everyone in the artificial LAN. If just a single device in the artificial LAN does not have a connection to the broadcast service, the artificial LAN fails to provide the same capability a physical LAN does. For example, you wouldn't be able to IP ARP to a device that does not have a connection to the broadcast service since that device could not receive the ARP broadcast. So everyone must be connected to the broadcast service which we'll call a BUS (Broadcast and Unknown Server).

LANE makes extensive use of ATM Forum switched virtual circuits (SVCs). SVCs require ATM addresses for setup. If we want to act like a Token Ring or an Ethernet host, we need a unique MAC address. The ATM NIC driver on the computer provides a way to map our MAC address to our ATM address. In LANE, we need a service that maps other ATM addresses to other MAC addresses. We'll call this service the LES (LAN Emulation Server). Frequently, the LES is co-located with the BUS service, allowing, in certain cases, the BUS to utilize LES tables for greater efficiency. When an ATM attached device wants to communicate with another ATM attached device, it sends an LE_ARP request to the LES asking for the ATM address of the MAC address with which it wants to communicate. Since every ATM-attached device participating in the emulated LAN registers with the LES, the LES provides an LE_ARP response with the correct ATM address to MAC address association. Once the end system has the ATM address of the other endpoint with which it wants to form a connection, it passes that address to the signaling channel for an SVC setup request. The LES acts like a reference librarian that everyone goes to when they want to know what ATM address maps to what MAC address.

Remember that these are artificial, or emulated, LANs. In an ATM cloud, we could have many Emulated LANs. This makes things difficult if we're not sure which Emulated LAN we want to join, so a LAN Emulation Configuration Server (LECS) is defined. The LECS maintains a table of defined Emulated LANs and tells the hosts which Emulated LANs they can join. It does this by maintaining the ATM address of the LES for every Emulated LAN. Additionally, the LECS maintains configuration parameters, like membership restrictions and cache aging values. There is no requirement that an ATM attached device look at the LECS tables to find out the address of the LES for the Emulated LAN it wants to join, but that is the common configuration.

Other pieces of the pie we need to talk about are the actual ATM attached devices that want to participate in the Emulated LAN. Let's call these devices LAN Emulation Clients (LECs) [ Note that the abbreviation is LECs, not LECS. This is a major cause of confusion in LANE discussions. Try to say "Client" or "Configuration Server" instead of saying LECS , because no one is sure if you mean LECS (the configuration server) or LECs (the clients). It isn't always obvious from the context]. Clients are the devices that have ATM addresses and need MAC addresses so they can act like they are on Ethernet and Token Ring networks. We end up with two classes of ATM attached device or LAN Emulation Clients (LECs): ATM-attached only (called a non-proxy LEC) and ATM-attached proxy devices (proxy LECs). The joy of proxy-LECs is that they allow many LAN devices to have connectivity to the ATM cloud without loading a separate ATM driver on the system (and installing an ATM NIC).

All this begs the question, 'If ATM is so great, why do we want to act like old Ethernet and Token Ring networks?' Well, in a perfect world, we wouldn't want to do that. But that would require rewriting every network application that relies on MAC addresses to now use ATM addresses, which will never happen. So LANE allows us to continue to use existing network gear (drivers, equipment, etc.) over a more powerful ATM cloud. Oh yeah, there is one other minor reason we want to emulate existing LAN topologies over ATM. It has to do with the huge installed base of existing Ethernet and Token Ring networks. Basically, no one wants to install ATM to the desktop for every network device already in existence. Would you? So what happens is that we have an Ethernet or Token Ring edge device that has an ATM connection to the ATM cloud and 'legacy' connections to existing Ethernet or Token Ring networks. This edge device (a proxy-LEC) connects the legacy LAN devices to the Emulated LAN. If you think about it, you can put a large capacity edge device (high port density) in each wiring closet and tie them together with an ATM backbone. The ATM backbone in this case being the Emulated LAN that all the edge devices have joined. Carried further, since ATM clouds can have multiple Emulated LANs, we can use a single ATM cloud to provide a common transport for multiple emulated LANs. You can put sales, marketing, and engineering sections on the same network without ever worrying that people in the different departments will ever inadvertently communicate with each other. So LANE allows us to continue to use our installed LANS, utilize a high speed ATM backbone, and migrate high bandwidth stations to ATM over time. This is a good thing.

Let's go through the process of creating an Emulated LAN. Then we will join two clients to it. This is just one sequence of steps. It does not always have to be done in this order. See Figures for more detailed information.

1. Create the LES and BUS service. Once you do this you will have the ATM addresses of those services.

You now have the Emulated LAN defined.

2. Create the LECS database file using the LES address from step 1
3. Create the LECS service. The LECS will have an address and a well known alias for its address at this point.
4. Inform the first LEC (Client) of the LECS address.
5. First LEC forms a SVC to the LECS. (Configuration Direct VCC). The LECS returns the LES ATM address of the Emulated LANs it can join.
6. First LEC forms SVCs to LES (joins the ELAN-Control Direct and Control Distribute VCCs)
7. LEC issues LE_ARP for MAC address of FF: FF: FF: FF: FF: FF (This is the LEC asking, "What's the address of the BUS?")
8. LES responds with ATM address of BUS
9. LEC forms SVCs to BUS (Multicast Send and Multicast Forward VCCs)

Now, the first LEC has joined the Emulated LAN. Let's add the next LEC. This one will be a proxy LEC, which means it is ATM connected on one side but has legacy LAN connections on the other. Let's also make those other connections be Ethernet connections.

10. Inform the second LEC (Client) of the LECS address.
11. Second LEC forms an SVC to the LECS. (Configuration Direct VCC). The LECS returns the LES ATM addresses of the Emulated LANs it can join.
12. Second LEC forms SVCs to LES (joins ELAN-Control Direct and Control Distribute VCCS)
13. LEC issues LE_ARP for MAC address of FF: FF: FF: FF: FF: FF (What's the address of the BUS?)
14. LES responds with ATM address of BUS
15. LEC forms SVCs to BUS (Multicast Send and Multicast Forward VCCS

At this point, the second LEC has joined the Emulated LAN. Let's communicate between the two devices now.

16. The first LEC has data to send to the second LEC (e.g., one machine wants to FTP something to the other machine). The first LEC issues an LE_ARP for the second LEC. (Assume it already knows the MAC address of the second LEC from some higher level protocol like IP ARP).
17. Simultaneously, the first LEC forwards the actual data to the BUS. It may be delay sensitive data and not able to wait until the destination MAC address to ATM address resolution occurs and subsequent SVC is established.
18. The LES does a table lookup on the MAC address and returns the ATM address of the second LEC in an LE_ARP response.
19. The first LEC passes the ATM address of the second LEC to the signaling channel to form an SVC (Data Direct VCC).
20. All done. We are now communicating.