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/aarconfig File".