| Platform Notes: The SunATM Driver Software |    
|
| Platform Notes: The SunATM Driver Software |
|
| 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:
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.
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.
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.
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.
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.
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
/etc/opt/SUNWconn/atm/aarconfig 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.
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 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.
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.
There are three types of LAN Emulation servers. Each type is briefly described in this section.
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.
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.
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.
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).
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.
ARP creates a broadcast request for the MAC address corresponding to the given IP address, which it sends to the LAN Emulation driver.
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.
The message is received on each host, and sent up to ARP by the LAN Emulation driver.
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.
The LAN Emulation driver sends an LE ARP request to the LES to resolve the source's MAC address to its ATM address.
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.
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.
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.
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 |
LAN Emulation supports IPv6's Neighbor Discovery process (RFC 2461) and is thus able to work transparently over IPv6.
| Platform Notes: The SunATM Driver Software | 816-1915-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.