Summary

Classical IP over ATM, specified in IETF RFC 1577, integrates IP and ATM technologies and minimizes the changes required to accomodate the technology in existing routers, switches, and hosts. The end to end IP routing architecture is the same as with legagy LAN technologies such as Ethernet. Because ATM is a connection oriented technology, the traditional Address Resolution Protocol (ARP) used on broadcast networks is no longer sufficient. CLIP solves this problem by specifying an ATMARP server which performs address resolution for network endpoints. IP hosts establish Switched Virtual Circuits to other IP hosts, and IP frames are delivered between hosts on these SVC's. This paper addresses a number of issues that we encountered while implementing CLIP. The following is a set of acronyms used in the paper.

	ARP - Address Resolution Protocol
	ATM - Asynchronous Transfer Mode
	CLIP - Classical IP over ATM
	IETF - Internet Engineering Task Force
	IP - Internet Protocol
	LIS - Logical IP Subnet
	MARS - Multicast Address Resolution Server
	MIB - Management Information Base
	RFC - Request for Comments
	SVC - Switched Virtual Circuit
	UNI - User Network Interface

• There are a number of RFC's related to RFC1577 which weren't available when RFC1577 was completed and address a number of important issues for the implementation. RFC 1755 addresses issues related to UNI signalling with respect to CLIP. RFC 1483 specifies the supported frame encapsulation types. RFC 1626 specifies the default IP MTU to be used. Additionally, there are draft updates to RFC's 1577 and 1755 which will soon be RFC's. These drafts contain some protocol improvements as well as prepare for support of protocols such as RSVP. The issues raised in these drafts must be considered so as to reduce wasted effort.
• An implementation should be capable of SNMP management. There is currently an IETF draft which specifies a CLIP MIB, but this MIB is currently undergoing revision. Attempting to stay current with each draft revision doesn't necessarily add value to the implementation. Implementers may be best served by choosing one of the draft revisions and waiting for the RFC before upgrading their software.
• As mentioned above, communicating endpoints in a LIS form a fully connected SVC mesh. The paper discusses the following issues raised by such a topology.
  The data structures that comprise the ATMARP cache must be carefully designed. More is required than that for a traditional Ethernet ARP Cache. For example, a set of endpoints may have multiple active SVC's. This requires a one-to-many mapping between an endpoint and its associated SVC's. This paper describes one approach using the C++ Standard Template Library for the implementation.
  IP endpoints can be in various stages of address resolution and connection management simultaneously. Endpoints must be prepared to handle the various race conditions that can arise in these scenarios.
• CLIP addresses only unicast IP traffic over ATM. Some other mechanism is required for delivery of IP multicast frames over ATM. MARS is an IETF RFC which addresses IP multicast over ATM. Endpoint receivers register with the MARS to join IP Multicast Groups, and endpoints senders query the MARS to determine the endpoints which must be added as leafs in a Point-to-Multipoint SVC. The paper briefly discusses the MARS architecture and reference documentation.
• It is important to be able to develop protocols without requiring switch hardware for testing. We have developed two key pieces of technology which allowed us to do full protocol development using only Sun workstations. We need only re-compile to deploy the code on the target switch hardware. The paper discusses the following components of the development environment.
  A lightweight UNI signalling emulation module that exports the same API to UNI clients as exists on the production switch. It also provides a lightweight implementation of the signalling protocol based on UNIX sockets. UNI endpoints are distributed across the LAN by mapping the ATM addresses specified in the UNI API to IP addresses on the LAN.
  A SunOS network pseudo-driver that provides a conduit for IP frames between the CLIP code and the IP stack on the Sun workstation. This allows us to unit test the CLIP implementation on the Sun using the full suite of IP applications such as telnet, ftp, rlogin, ping, ftp, etc. The driver can be installed and removed dynamically.
• As mentioned above, an update to CLIP will soon be available as an RFC. Although the changes are not major, the new draft presents a compatability problem between old ATMARP clients and new ATMARP servers. The paper dicusses the problem and the various alternatives implementors and users can take.

Bill Willcox
Nexion, Inc.
289 Great Rd.
Acton, MA 01720
Tel: (508) 266-4506
Fax: (508) 266-2300
willcox@acm.org