C H A P T E R  5

Classical IP and LAN Emulation

ATM is a connection-oriented network protocol, which means that a connection must be established between two communicating entities before data transfer can begin. IP is inherently connectionless. The implementation on the host must therefore reconcile the differences in these two paradigms.

There are two standard ways of doing this: Classical IP, standardized in RFC 1577, and LAN Emulation, standardized in the LAN Emulation 1.0 specification from the ATM Forum. The SunATM architecture supports all of these methods. This chapter discusses some of the key ideas of these two methods.

Both methods allow IP to run transparently over the ATM interface. Thus IP itself sees the ATM interface just as it sees any traditional network interface. Every SunATM interface has a subnet IP address. As an ATM interface starts up, appropriate modules and drivers are plumbed. All the TCP/IP and
UDP/IP applications run without modifications over these modules, and all the utilities associated with the network interfaces also run without modification and display similar results (for example, netstat and ifconfig utilities), with one exception. Because of the different plumbing of the ATM modules, the plumb and unplumb options of ifconfig will not work on ATM interfaces. The atmifconfig(1M) command must be used to plumb and unplumb ATM interfaces. IP treats the ATM interface as a subnet, choosing the interface used to send a packet out based on the IP address of the destination and on the IP address and netmask of the interface itself.

The transparency to IP is enabled in different ways in Classical IP and LAN Emulation. Those differences will be discussed in later sections of this chapter.

SunATM signalling conforms to the user network interface (UNI) specification of the ATM Forum. Versions 3.0, 3.1, and 4.0 of that specification are supported. This signalling, called Q.2931, runs on top of QSAAL and uses VC 5 for signalling as specified in the Forum specification.

This chapter contains the following sections:

ATM Addresses and Address Registration

UNI signalling uses ATM addresses for signalling. Every ATM interface has an ATM address in addition to its IP address.

ATM addresses, like Network Service Access Point (NSAP) addresses, are 20 octets long. The End System Identifier (ESI) field within the ATM address is a unique 6 octet value; this can be the IEEE hardware MAC address conventionally associated with every network interface. The Selector field is one octet long. The 13 octets that make up the rest of the ATM address are called the Network Prefix, and are derived from the ATM switch fabric to which the interface is connected. Every ATM switch fabric is configured with a 13 octet prefix.

On a SunATM host, the prefix associated with the local switch fabric is represented by the $prefix variable. Its value is obtained by the system at configuration time.

FIGURE 5-1 ATM Address Fields

Image of the three ATM address fields. Displayed from left to right, the fields read as follows: Determined by the ATM switch/13, ESI/6 octets, SEL (1 octet).

The UNI specification specifies the Interim Local Management Interface (ILMI) service interface for a client to learn and register its ATM address. The ILMI service interface is based on the use of SNMP over AAL5. In the SunATM software package, ILMI service is provided by an address registration daemon, ilmid.

ATM Address Registration Daemon (ilmid)

Address registration with a switch is controlled by ilmid. When an ATM interface is brought up at boot time, ilmid is also started. ilmid then begins an exchange of messages with the switch: relaying local address information (the 7 octet ESI and selector) to the switch and receiving the 13 octet network prefix information from the switch.

The default local address that is registered with the switch at boot time consists of the network prefix provided by the switch, the MAC address assigned to the local interface, and the default selector for that interface (usually 0). Additional addresses are registered in two different ways. aarsetup(1M) and lanesetup(1M) register additional local addresses that may appear in aarconfig(4) and laneconfig(4), respectively. You can also use atmreg(1M) to register addresses, un-register addresses, and check the status of any address.

Classical Internet Protocol

For ATM to work transparently under IP, an IP address must be resolved to an ATM address and a connection to that destination must be established. Classical IP does this via a database of IP/ATM address pairs that is either provided by an ATM ARP server that is accessible to all hosts on the subnet, or is maintained locally in each host.

ATM Address Resolution

Traditional TCP/IP and UDP/IP applications use IP addresses for communicating to a destination. For these applications to run like traditional applications, IP addresses need to be resolved into ATM addresses. The ATM address then signals to establish an ATM connection to the destination. An ATM connection in turn is represented by a VPI/VCI. The host must use this returned VPI/VCI to send packets to the destination that represents the ATM connection.

ATM address resolution, also called ATM ARP, follows RFC 1577, the classic draft that describes the ATM ARP process.

RFC 1577 assumes the existence of an ATM ARP server on every subnet. Every client on the subnet communicates with the ATM ARP server to derive the destination's ATM address from its IP address. The ATM ARP server holds the IP-to-ATM address information for all hosts in the ATM subnet. It is likely that initial ATM configurations will not rely on dynamic ATM address resolution because it requires the presence of an ATM ARP server on every subnet. Also, there are no specified standards for providing redundant ATM ARP servers for a subnet. As specified, the ATM ARP server would constitute a single point of failure in the system. From a practical standpoint, however, early configurations can use an IP-to-ATM address database in every system, thus avoiding the IP-to-ATM address resolution step altogether.

The RFC requires a router for passing data between subnets. SunATM software provides ATM utilities that allow configurations to specify IP-to-ATM addresses in
/etc/opt/SUNWconn/atm/aarconfig files. The aarsetup program uses the information in /etc/opt/SUNWconn/atm/aarconfig to create IP-to-ATM address resolution tables. Dynamic entries into a server's resolution table are also supported.

TABLE 3-1 shows the format of the /etc/opt/SUNWconn/atm/aarconfig file for specifying the IP-to-ATM address. It is important for the file to be consistent on all systems in the subnet. See Editing the /etc/opt/SUNWconn/atm/atmconfig File.

ATM ARP Address Resolution Tables

Depending on the aarconfig file, the Classical IP software runs as either a server or a client. As a server, the Classical IP software handles ATM ARP requests originating from its clients. An ATM server has to be configured for each subnet. The ATM ARP server code conforms to RFC 1577: clients send ATM ARP requests to the server to resolve a destination IP address to an ATM address. The server then replies to ATM ARP requests by sending an ATM ARP response. If the server does not have the IP-to-ATM address entry, then it replies with NAK.

All the IP-to-ATM address entries specified in the /etc/opt/SUNWconn/atm/aarconfig file are entered into a kernel resident table by the ATM ARP setup program, aarsetup. Additional entries in the kernel table are added dynamically using the inverse ARP process. When a client connects to the server, the server sends an inverse ARP request back to the client to obtain the client's IP address. When a response is received, an entry is created for that client. The Classical IP software also responds to client ARP requests. The software looks up a kernel IP-to-ATM address entry and responds to an ATM ARP request with either an ATM ARP reply or ATM ARP NAK (if there is no entry in the table). Note that an ATM ARP client uses the virtual channel (VC) specified in the /etc/opt/SUNWconn/atm/aarconfig file to communicate with the server; or, if an ATM address is specified, it establishes a switched virtual circuit (SVC) connection to communicate with the server.

While dynamic entries in the ARP server's table make network administration less complex, they also create a security problem. Any host can register with the ARP server and therefore gain access to the subnet. To resolve this issue, you can provide a list of hosts or networks with a entries in the server's
file. If no a entries appear, any host can connect to the server. If any a entries exist, only those hosts whose addresses match those specified will be allowed to connect.

Although the a entry requires a complete ATM address, you can reference multiple addresses in a single entry using the provided wildcards. See Editing the /etc/opt/SUNWconn/atm/atmconfig File for more information about this feature.

The advantage of having an ATM ARP server in the subnet is that it represents a known source for all address resolutions. It is the only host that a client must know about to have IP addresses resolved to ATM connections, and it allows for access control in the ATM network.

When the /etc/opt/SUNWconn/atm/aarconfig file has been modified on a system, it is necessary to rerun aarsetup.

Note - For better caching, all clients have the option of adding to their configuration file the IP-to-ATM address information for other clients.
This can benefit clients that communicate frequently because it eliminates having to go through the ATM ARP server for IP-to-ATM address resolution.

If a host has multiple SunATM cards, the host can be a server for one IP subnet and a client for another. This is handled transparently by aarsetup.

IPv6 Address Resolution Process

IPv6 addressing works diffferntly than IPv4. IPv6 uses Neighbor Discovery process (RFC 2461) rather than ARP protocol for the address resolution. SunATM 5.1 does not currently support address resolution through RFC 2461 over IPv6. Thus PVC and SVC address resolution over IPv6 must be statically configured. You must enter all destination hosts and ATM Address/VCI entries on each host's local aarconfig file.

LAN Emulation

As described in previous sections, Classical IP provides its own (IP-to-ATM) address resolution mechanism that corresponds to and replaces ARP, thus allowing IP-based applications to run transparently over ATM. A shortcoming of Classical IP, and a primary reason it must replace the traditional ARP, is that it does not support broadcast messages.

Because ATM is a connection-oriented protocol (unlike ethernet), implementing broadcast is much more difficult. The only host that receives a message is the host to which the message is addressed, and a call must be established to that host before the message can be sent.

Local Area Network (LAN) Emulation, as standardized by the ATM Forum, provides mechanisms to send broadcast messages in an ATM environment. Given this capability, LAN Emulation is also able to work transparently with ARP, as well as IP. IP and ARP send broadcast messages over the ATM interface, and thus resolve IP addresses to MAC addresses; messages are then sent to the LAN Emulation driver, which has its own address resolution protocol (similar to that of Classical IP) to resolve the medium access control (MAC) address to an ATM address and connection.

The SunATM software implements the client side of the LAN Emulation standard. To use LAN Emulation in an environment, several LAN Emulation services must also exist in the emulated LAN. These services, called the LAN Emulation Configuration Server (LECS), the LAN Emulation Server (LES), and the Broadcast and Unknown Address Server (BUS), are generally provided in an ATM switch. The following sections provide an overview of the functions of these servers.

LAN Emulation Servers

There are three types of LAN Emulation servers. Each type is briefly described in this section.

LAN Emulation Configuration Server

This server is first contacted by a host interface when the host is brought up on the emulated LAN. Its address is generally a well-known address specified by the LAN Emulation standard that is coded into the host software; thus establishing this connection requires no input from you. When contacted by a host wishing to join its emulated LAN, the LECS replies with configuration parameters for the emulated LAN, as well as the address of the LES.

LAN Emulation Server

The second step in joining an emulated LAN is to make a connection to the LAN Emulation Server. After receiving the LES address from the LECS, a host will establish a connection to the LES. The LES may add the host to a point-to-multipoint call that is maintained by the LES with connections to every host in the emulated LAN. This point-to-multipoint connection, if created by the LES, is used to send control information to each host on the emulated LAN.

The LES acts as the ATM ARP server. Since IP and ARP work with MAC addresses, an additional address resolution step is required to convert a MAC address to the corresponding ATM address, which is used to make a connection to the target host; this resolution step is provided by the LES.

Broadcast and Unknown Address Server

The final step in joining an emulated LAN is to make a connection to the BUS. The ATM address of the BUS is obtained by sending a LAN Emulation ARP request to the LES for the broadcast address. Once established, this connection is used to send broadcast messages to the BUS, which will add the client to a point-to-multipoint call including all hosts on the emulated LAN. Thus when a broadcast message (such as an IP ARP request) is received by the LAN Emulation host from its upper layers, it sends that message to the BUS, which forwards it to all hosts in the emulated LAN. Just as in the case of ethernet, the correct host responds to the sender, and thus the IP address is resolved to a MAC address.

Resolving an IP Address to an ATM Connection

The entire process from the time IP sends a message addressed to an IP address to the arrival of that message at the appropriate destination was hinted at in the previous descriptions of the LAN Emulation servers. To demonstrate how those pieces work together during the actual transmission of a message, the process is described below. This description assumes that none of the needed addresses have been previously resolved and cached. The two hosts involved are referred to as the source (the system that wishes to send a message) and the target (the system to which the message is addressed).

  1. IP has a message to transmit and only knows the IP address of the target system. IP first sends a message to ARP, to resolve the IP address to a MAC address.

  2. ARP creates a broadcast request for the MAC address corresponding to the given IP address, which it sends to the LAN Emulation driver.

  3. The LAN Emulation driver recognizes that this message has a broadcast address, and sends it to the BUS, which forwards the message to every host on the emulated LAN.

  4. The message is received on each host, and sent up to ARP by the LAN Emulation driver.

  5. On the target, ARP recognizes the IP address as its own and sends a response with its MAC address (addressed to the source's MAC address) down to the LAN Emulation driver.

  6. The LAN Emulation driver sends an LE ARP request to the LES to resolve the source's MAC address to its ATM address.

  7. The LES responds with the requested ATM address, and the target host sets up an ATM connection to the source host, over which it sends the IP ARP response.

  8. The LAN Emulation driver on the source receives the IP ARP response message and sends it up to ARP. ARP then inserts the MAC address into the original message and sends it back down to the LAN Emulation driver.

  9. The LAN Emulation driver then must send an LE ARP request to the LES to resolve the MAC address in the message from ARP to an ATM address. When it receives an LE ARP response, it then sees that it has a connection to that address (established by the target to return the IP ARP response) and sends the original IP message to the target over that connection.

LAN Emulation Connections

There are several connections established at all times when a host is a member of an emulated LAN. The following table outlines the various LAN Emulation-related connections that should be on a LAN Emulation client (LEC).

Note - Use the command qccstat(1M) to view all existing connections for a given interface

TABLE 5-1 LAN Emulation Connections




Configuration Direct


This connection is not required to remain open after the initial join of the emulated LAN, and thus may time out after a host has joined the LAN.

Control Direct


Point-to-point connection over which the host may send LE ARP requests and receive responses from the LES.

Control Distribute


Point-to-multipoint connection over which the LES may send administrative information to all hosts. Hosts may not send on this connection.

Multicast Send


Point-to-point connection over which the host may send broadcast messages to the BUS. A limited amount of data is also allowed on this connection.

Multicast Forward


Point-to-multipoint connection over which the BUS sends broadcast messages. Hosts may not send on this connection.

IPv6 Address Resolution Process

LAN Emulation supports IPv6's Neighbor Discovery process (RFC 2461) and is thus able to work transparently over IPv6.