[author] [subject] [title]

Sanjay Kapoor Building Hybrid ATM Networks Presently, there are two popular methods of communicating in an ATM environment: Local area network emulation or LAN emulation, and Classical Internet Protocol (IP) over ATM. The LAN emulation specification allows the transport of multiple protocols such as the Internet Packet Exchange Protocol and the Internet Protocol over an ATM network. Classical Internet Protocol, in contrast, allows the transport of IP only over an ATM network. Given this difference, it is easy to understand why LAN emulation is the most popular communication approach today. This article focuses on the LAN emulation specification in an effort to help you better understand the advantages of communicating in an ATM environment. WHAT IS LAN EMULATION? LAN emulation is a specification defined by the ATM Forum that enables users to build networks that include Ethernet and ATM-attached devices. The primary goal of this specification is to facilitate the transparent attachment of an ATM-attached client to a legacy network such as Ethernet. It enables users to migrate to an ATM infrastructure with minimal impact on the existing Ethernet legacy infrastructure. The current specifications for LAN emulation version 1.0 are well defined. Several ATM switch and adapter card vendors are shipping products today that conform to these specifications. Figure 1 details the implementation of LAN emulation. From Figure 1, we can see that several legacy users on Ethernet can communicate with users on ATM networks. The nice thing about this specification is that there is no change in either hardware or software for the legacy clients. However, the ATM-attached clients will need to run LAN emulation drivers on their ATM cards to communicate with legacy users. This does not pose a problem as there are several ATM card vendors currently shipping LAN emulation drivers for their cards.1 SEGMENTATION AND REASSEMBLY When a variable length Ethernet frame traverses the ATM network, it has to be chopped into standard 53-byte ATM cells. This is because a standard Ethernet frame is much larger than a fixed size ATM cell. Similarly, when these cells need to get to an Ethernet client, they must be repackaged into Ethernet frames. This process is known collectively as the Segmentation and Reassembly (SAR) layer and is embedded within the ATM Adaptation Layer 5 (AAL5), as shown in Figure 2a. The SAR process is detailed in Figure 2b. As seen in the figure, the Ethernet frames that need to go out on the ATM port are processed internally within the edge device. Processing includes several steps, some of which are: Determining the outgoing ATM address. Segmenting and reassembling. Connecting with the destination. When the device receives ATM cells that need to be forwarded to an Ethernet client, it reassembles the ATM cells into Ethernet frames and forwards them accordingly. Figure 2b-2 illustrates a similar process for a Token Ring network. The AAL/SAR sub-layer is responsible for handling the conversion of Ethernet frames into ATM cells and vice versa. An important point to note here is the address translation, i.e., how the Ethernet address is translated into the ATM address which will be explained in detail in the following sections. This segmentation and reassembly process is implemented primarily in two general types of ATM devices. Adapter cards found in ATM-attached workstations, where traditional applications on computers (PCs or workstations) run on well-known protocols such as the Transmission Control Protocol/Internet Protocol or the Internet Packet Exchange Protocol. User data that is encapsulated into these protocols is sent to the ATM adapter card. The SAR layer functionality is generally implemented within a chip-set on the adapter cards. The larger application data packets are segmented into smaller ATM cells before transmission onto the ATM network. Correspondingly, the incoming ATM cells are reassembled into larger application data packets. The SAR process might also be accomplished by a class of devices generically known as edge devices (shown in Figure 2b), which typically connect a number of legacy users to an ATM switch. In this case, there is a central SAR architecture with associated memory to serve a large group of legacy users. Figure 2b also shows the protocol stack implemented within the edge device. As you can see, both the ATM protocol stack and the legacy protocol stack are implemented within the edge device. WHY DO WE NEED LAN EMULATION? LAN emulation helps primarily in supporting existing applications on an ATM network. For example, a manufacturing company may have some of their high-end users, such as CAD/CAM and simulation workgroups, on an ATM backbone. Yet they also need to communicate with the rest of the company via the company's existing legacy network(s) such as Ethernet and/or Token Ring. LAN emulation is an efficient solution for facilitating communication with existing network users. Recall that traditional local area networks have inherent broadcast qualities built-in, i.e., when an Ethernet station wants to talk to another station, it sends out a broadcast that is "heard" by everyone on the network. The data/message is pulled off the wire after an address match is found. Although this may be a waste of bandwidth, the basic broadcast feature is easy to implement. Therefore, LAN emulation attempts to add broadcast and multicast capabilities on an ATM network which, by its very nature, is connection-oriented. LAN EMULATION COMPONENTS The LAN emulation specifications, as defined by the ATM Forum, have four primary components: LAN Emulation Client. LAN Emulation Configuration Server. Broadcast and Unknown Server. LAN Emulation Server. Based on the vendors' architecture, these components (primarily software) are either configured within the switch or are installed on a single UNIX-based workstation outside the physical switch chassis. Currently, there are two basic connection management trends -- centralized and distributed -- with no clear winner. This is a conceptual debate I will not get into. What I will do is explain the functions of each one of these modules so that you can understand the design issues involved in building a hybrid ATM network. The explanations are based on the LAN emulation specification version 1.0, as per those specified by the ATM Forum. LAN EMULATION CLIENT A LAN emulation client is defined as an ATM-attached workstation, file server, or personal computer that runs LAN emulation software. Before one client can talk to another, it must first join the emulated LAN. There are four major phases a LAN emulation client must go through before becoming a member of an emulated LAN. These steps primarily deal with how one client gets ATM addressing information. I will also explain the kinds of control and data connections that are set up in this networking paradigm. Connect with the LAN emulation configuration server: This server provides the client with configuration information pertinent to the emulated LAN that the client wishes to join. Join phase: This is an important phase in which the client sets up control connections (which will be described in the next section) with the LAN emulation server. Upon successful completion of the join phase, the client is assigned a LAN Emulation Client ID, maximum allowable frame size, and the LAN type (e.g., Ethernet or Token Ring). Figure 3 shows the join process in which there are two types of connections between the client and the emulation server: Control Direct VCC (a bi-directional point-to-point connection to communicate control information between the client and the server) and Control Distribute VCC (a point-to-multipoint connection that is used to receive control information, updates, etc. from the server). Initial Registration: In this phase, the client registers its Media Access Control (MAC) addresses, as in the case of Ethernet, or route descriptors, as with the case of Token Ring, with the LAN emulation server. Connection with the Broadcast and Unknown Server (BUS): In this step, the client attaches with the BUS. Initial communication with other clients in the emulated environment take place via the BUS. BROADCAST AND UNKNOWN SERVER There are two types of connections between the client and the BUS. A bi-directional point-to-point connection between the client and the BUS known as the Multicast Send VCC (Virtual Channel Connection). A point-to-multipoint connection from the BUS to all the servers known as the Multicast Forward VCC. The client must maintain this connection as long as it wants to participate in the LAN emulation session. The LAN emulation client uses the Multicast Send VCC to transmit data to members in its group or virtual LAN. After receiving the packet, the BUS makes the required copies and sends it to the members based on its call-tree, as shown in step 1 in Figure 4. Every client builds up an address translation table that maps ATM addresses with traditional Ethernet addresses. Step 2, shown in Figure 4, shows that clients can set up direct connections with other clients known as the Data Direct VCC. In this case, the connection with the BUS that is used to forward data to the other clients must be torn down first. LAN EMULATION SERVER The server maintains a central translation table that keeps the ATM/MAC address bindings for all the members, i.e., clients that are participating in that emulated LAN. When a client needs either an ATM address for a destination, it consults the LAN emulation server. There are three cases which result in different actions, based on the state of the client. The source client knows the ATM address of the destination client and has a connection to it. If it has the ATM address and a connection to the destination client, the data is sent. The source client knows the ATM address of the destination client, but does not have a connection to the destination. The client will look in its address cache to determine if it has the destination ATM address. It then determines if it has a connection to that client. If not, it requests that a connection be set up. The source client does not know the ATM address of the destination client, nor does it have a connection to it. In this case, the source client communicates its request to the server via the point-to-point connection. It is possible that the server may not have the ATM address of the destination client in question. In that case, the server issues a LAN emulation address resolution protocol request to all the servers in the emulated LAN. Upon receiving a reply from the designated client, the server forwards the ATM address binding to the source client. CONCLUSION Figure 5 summarizes what I have discussed in this article. A typical network can consist of both ATM and Ethernet topologies. Users are efficiently served by connecting the file servers via ATM in the network. Some departments within the corporation -- CAD/CAM workstations, simulation engines, and imaging workstations -- are also ATM-attached. The rest of the corporate network is Ethernet-attached in two ways: Dedicated 10 Mb/s Ethernet users via the HUB. This, of course, is the way legacy networks are set up, where the 10 Mb/s Ethernet is shared among several users. LAN emulation drivers are installed and configured on the ATM-attached workstations, file servers, etc. This allows transparent communication between legacy-attached users and ATM users. Among several communication options that exist today, LAN emulation is the most popular technique. It allows users to build hybrid networks, i.e., networks that consist of both ATM and legacy-attached nodes. The benefits of LAN emulation can be summarized as follows: LAN emulation allows users to incorporate ATM into their existing networks in a gradual, phased manner. Users/department(s) that need the high bandwidth, performance, and scalability that ATM delivers can benefit without impacting existing network infrastructure. LAN emulation allows companies to protect the investment in their legacy networks. 1 Check with your ATM card vendor and make sure the LAN emulation drivers are ATM Forum compliant. Source: This article originaly appeared in the New Telecom Quarterly: 1996Q1. We also provide a PDF version. [home][author] [subject] [title]