ATM LAN EMULATION

ATM LAN EMULATION

One issue that was not addressed in our discussion of ATM LANs

has to do with the interoperability of end systems on a variety of interconnected

LANs. End systems attached directly to one of the legacy LANs implement the

MAC layer appropriate to that type of LAN. End systems attached directly to an

ATM network implement the ATM and AAL protocols. As a result, there are three

areas of compatibility to consider:

Interaction between an end system on an ATM network and an end system

on a legacy LAN.

Interaction between an end system on a legacy LAN and an end system on

another legacy LAN of the same type (e.g., two IEEE 802.3 networks).

Interaction between an end system on a legacy LAN and an end system on

another legacy LAN of a different type (e.g., an IEEE 802.3 network and an

IEEE 802.5 network).

The most general solution to this problem is the router, which is explored in

Lesson 16. In essence, the router operates at the level of the Internet Protocol (IP).

All of the end systems implement IP, and all networks are interconnected with

routers. If data are to travel beyond the scope of an individual LAN, they are

directed to the local router. There, the LLC and MAC layers are stripped off, and

the IP PDU is routed across one or more other networks to the destination LAN,

where the appropriate LLC and MAC layers are invoked. Similarly, if one or both

of the end systems are directly attached to an ATM network, the AAL and ATM

layers are stripped off or added to an IP PDU.

While this approach is effective, it introduces a certain amount of processing

overhead and delay at each router. In very large internetworks, these delays can

become substantial. Networks of 1000 routers are increasingly common, and networks

of as many as 10,000 routers have been installed [LANG95]. A technique that

exploits the efficiency of ATM and that reduces the number of required routers is

desired.

Another way to approach the problem is to convert all end systems such that

they operate directly on ATM. In this case, there is a seamless technology used

throughout any network, including local and wide area components. However, with

millions of Ethernet and token ring nodes installed on today's shared-media LANs,

most organizations simply can't afford a one-shot upgrade of all systems to ATM.

In addition, although the cost of ATM interface cards is dropping, Ethernet and

token ring interfaces remain cheaper for the time being.

In response to this need, the ATM or urn^ has created a specification for the

coexistence of legacy LANs and ATM LANs, known as ATM LAN emulation

[ATM95]. The objective on ATM LAN emulation is to enable existing shared-

media LAN nodes to interoperate across an ATM network and to interoperate with

devices that connect directly to ATM switches.

Figure 14.13 illustrates the type of configuration that can be constructed using

ATM LAN emulation. In its present form, the ATM specification satisfies two

of the three requirements listed earlier; namely, ATM LAN emulation defines the

following:

1. The way in which end systems on two separate LANs of the same type (same

MAC layer) can exchange MAC frames across the ATM network.

2. The way in which an end system on a LAN can interoperate with an end system

emulating the same LAN type and attached directly to an ATM switch.

The specification does not as yet address interoperability between end systems

on different LANs with different MAC protocols.

Protocol Architecture

Figure 14.14 indicates the protocol architecture involved in ATM LAN emulation.

In this case, we are looking at the interaction of an ATM-attached system with an

end system attached to a legacy LAN. Note that the end system attached to a legacy

LAN is unaffected; it is able to use the ordinary repertoire of protocols, including

the MAC protocol specific to this LAN and LLC running on top of the MAC. Thus,

the end system runs TCPIIP over LLC, and various application-level protocols on

top of that; the various application-level protocols are unaware that there is an

ATM network underneath. The key to this diagram is the use of a bridge device

known as an ATM-to-LAN converter.

In Figure 14.14, the bridge logic must be augmented by the capability of converting

MAC frames to and from ATM cells. This is one of the key functions of the

LAN emulation module. The ATM Forum specification calls for making use of

AAL 5 to segment MAC frames into ATM cells and to reassemble incoming ATM

cells into MAC frames. For outgoing ATM cells, the ATM-to-LAN converter connects

in the usual fashion to an ATM switch as part of an ATM network.

Figure 14.14 shows the case in which a host on a legacy LAN is exchanging

data with a host attached directly to an ATM network. To accommodate this

exchange, the ATM host must include a LAN emulation module that accepts MAC

frames from AAL and must pass up the contents to an LLC layer. Thus, the host is

indeed emulating a LAN because it can receive and transmit MAC frames in the

same format as the distant legacy LAN. From the point of view of end systems on

the legacy LAN, the ATM host is just another end system with a MAC address. The

entire LAN emulation process is transparent to existing systems implementing LLC

and MAC.

Emulated LANs

With the protocol architecture just described, it is possible to set up a number

of logically independent, emulated LANs. An emulated LAN supports a single

MAC protocol, of which two types are currently defined: EthernetIIEEE 802.3 and

IEEE 802.5 (token ring). An emulated LAN consists of some combination of the

following:

End systems on one or more legacy LANs

End systems attached directly to an ATM switch

Each end system on an emulated LAN must have a unique MAC address.

Data interchange between end systems on the same emulated LAN involves the use

of the MAC protocol and is transparent to the upper layers. That is, it appears to

LLC that all of the end systems on an emulated LAN are on the same sharedmedium

LAN. Communication between end systems on different emulated LANs

is possible only through routers or bridges. Note that the bridges or routers have to

reassemble the cells into packets and then chop them up into cells to send them to

another emulated LAN.

LAN Emulation Clients and Servers

The discussion so far leaves out a number of issues that must be addressed, including

the following:

1. Devices attached directly to ATM switches and to ATM-to-LAN converter

systems have ATM-based addresses. How are translations made between

these addresses and MAC addresses?

2. ATM makes use of a connection-oriented protocol involving virtual channels

and virtual paths. How can the connectionless LAN MAC protocol be supported

over this connection-oriented framework?

3. Multicasting and broadcasting on a shared-medium LAN is easily achieved.

How is this capability carried over into the ATM environment?

To address these issues, the ATM Forum developed a capability based on a

clientlserver approach, which is discussed next.

ATM LAN emulation requires two types of components: clients and servers.

Clients operate on behalf of devices that are attached to legacy LANs and that use

MAC addresses. A client is responsible for adding its MAC entities into the overall

configuration and for dealing with the tasks associated with translating between

MAC addresses and ATM addresses. Typically, a client would be provided in a

router, in an ATM-attached server (see Figure 14.13), or perhaps in an ATM switch

that directly connects to one of the above (referred to as an edge switch). Servers

are responsible for integrating MAC entities into the overall configuration and for

managing all of the associated tasks, such as finding addresses and emulating broadcasting.

Servers may be implemented in separate components or in ATM switches.

Each emulated LAN consists of one or more clients and a single LAN emulation

service.

The LAN emulation service in fact comprises three types of servers, which

perform separate tasks: the LAN Emulation Configuration Server (LECS), the

LAN Emulation Server (LES), and the Broadcast and Unknown Server (BUS).

The reason for breaking the server up into three modules is that a manager may

decide to have more of one kind of server than another, for efficient operation, and

may decide to distribute the servers physically to minimize the communications

burden. Table 14.2 provides a brief definition of the three types of servers and of

the client.

Figure 14.15 indicates the way in which clients and the three types of servers

interact. The client can establish virtual channel connections, called control connections,

to the LECS and the LES. The link to the LECS is used by an LEC to gain

entrance to an emulated LAN and to locate an LES. The LES is responsible for

registering new clients and their MAC addresses into an emulated LAN, as well as

for mapping between MAC addresses and ATM addresses.

Once a client and its end systems have joined an emulated LAN, most of the

work is done across virtual channel connections called data connections. MAC

frames, segmented into ATM cells, are transmitted via data connections between

end systems on the same emulated LAN. For a unicast transmission, a virtual channel

connection is set up between two clients; this is the protocol setup illustrated in

Figure 14.14. Finally, the data connection between a client and a BUS carries transmissions

intended for broadcast or multicast, and it also is used to handle transmissions

in which the sending client does not know the address of the receiving client.

LAN Emulation Scenario

To clarify the concepts involved in LAN emulation, let us follow a typical sequence

of events.

Initialization

To join an emulated LAN, a client must begin by obtaining the ATM address of the

LAN emulation server (LES) for that emulated LAN. Typically, the way in which

this is done is that the client establishes a virtual channel connection to the LAN

emulation configuration server (LECS).

There are three possible techniques by which the client can discover the LECS

ATM address so that it can perform initialization:

I. The client can use a network management procedure defined as part of the

ATM Forum's Interim Local Management Interface (ILMI). This procedure

takes place between the client and ILMI software in the associated ATM

switch. If the ILMI software has the LECS address for the requested emulated

LAN, it provides that address to the client. The client then establishes a virtual

channel connection to the LECS.

2. If the ILMI procedure fails, the client tries a predefined address listed in the

specification, called the well-known address. This address is supposed to correspond

to an LECS on any ATM network that conforms to the ATM Forum

specification. The client uses this address to establish a virtual channel connection

to the LECS.

3. If the well-known address fails, the client tries the well-known virtual path

identifledvirtual channel identifier defined in the ATM Forum specification.

When the ATM network is configured, the network manager can establish this

permanent virtual pathlvirtual channel.

Configuration

Once a connection is established between the client and the LECS, the client can

engage in a dialogue with the LECS. Based upon its own policies, configuration

database, and information provided by the client, the LECS assigns the client to a

particular emulated LAN service by giving the client the LES's ATM address. The

LECS returns information to the client about the emulated LAN, including MAC

protocol, maximum frame size, and the name of the emulated LAN. The name may

be something defined by the configuration manager to be meaningful in defining

logical workgroups (e.g., finance, personnel).

Joining

The client now has the information it needs to join an emulated LAN. It proceeds

by setting up a control connection to the LES. The client then issues a JOIN

REQUEST to the LES, which includes the client's ATM address, its MAC address,

LAN type, maximum frame size, a client identifier, and a proxy indication. This latter

parameter indicates whether this client corresponds to an end system attached

directly to an ATM switch or is a LAN-to-ATM converter supporting end systems

on a legacy LAN.

If the LES is prepared to accept this client, it sends back a JOIN RESPONSE,

indicating acceptance. Otherwise, it sends back a JOIN RESPONSE indicating

rejection.

Registration and BUS Initialization

Once a client has joined an emulated LAN, it goes through a registration procedure.

If the client is a proxy for a number of end systems on a legacy LAN, it sends a list

of all MAC addresses on the legacy LAN that are to be part of this emulated LAN

to the LES.

Next, the client sends a request to the LES for the ATM address of the BUS.

This address functions as the broadcast address for the emulated LAN and is used

when a MAC frame is to be broadcast to all stations on the emulated LAN. The

client then sets up a data connection to the BUS.

Data Transfer

Once a client is registered, it is able to send and receive MAC frames. First, consider

the sending of MAC frames. In the case of an end system attached to an ATM

switch, the end system generates its own MAC frames for transmission to one or

more other end systems on the emulated LAN. In the case of a proxy client, it functions

as a bridge that receives MAC frames from end systems on its legacy LAN and

then transmits those MAC frames. In both cases, an outgoing MAC frame must be

segmented into ATM cells and transmitted over a virtual channel. There are three

cases to consider:

* Unicast MAC frame, ATM address known

Unicast MAC frame, address unknown

Multicast or broadcast MAC frame

If the client knows the ATM address of the unicast frame, it checks whether it

has a virtual data connection already established to the destination client. If so, it

sends the frame over that connection (as a series of ATM cells); otherwise, it uses

ATM signaling to set up the connection and then sends the frame.

If the address is unknown, the sending client performs two actions. First, the

client sends the frame to the BUS over the data connection that it maintains with

the BUS. The BUS, in turn, either transmits the frame to the intended MAC destination

or else broadcasts the frame to all MAC destinations on the emulated LAN.

In the latter case, the intended destination will recognize its MAC address and

accept the frame. Second, the client attempts to learn the ATM address for this

MAC for future reference. It does this by sending an LE-ARP-REQUEST (LAN

Emulation Address Resolution Protocol Request) command to the LES; the command

includes the MAC address for which an ATM address is desired. If the LES

knows the ATM address, it returns the address to the client in an

LE-ARP-RESPONSE. Otherwise, the LES holds the request while it attempts to

learn the ATM address. The LES sends out its own LE-ARP-REQUEST to all

clients on the emulated LAN. The client that represents the MAC address in question

will return its ATM address to the LES, which can then send that address back

to the original requesting client.

Finally, if the MAC frame is a multicast or broadcast frame, the sending client

transmits the frame to the BUS over the virtual data connection it has to the BUS.

The bus then replicates that frame and sends it over virtual data connections to all

of the clients on the emulated LAN.