INTERNET-DRAFT Carl Marcinik Expires May 16, 1996 FORE Systems,Inc. Fong Ching Liaw Ipsilon Networks,Inc. November 22, 1995 ATMARP Client Autoconfiguration Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes an extension to RFC 1577 [1] that allows an ATMARP client to automatically locate its ATMARP server. This procedure is facilitated through the use of ATM anycast addressing [2]. ATMARP clients use a LIS-specific anycast address to locate their LIS-designated ATMARP Server. Both an ATMARP client and an ATMARP server algorithmically determine their LIS-specific anycast address upon restart. The use of this procedure will significantly relieve the administrative burden currently required to (re)configure a Classical IP network. This procedure requires that an IP address and subnet mask be made available (e.g., through manual configuration) before autoconfiguration can be initiated for a given ATMARP client or server. In addition, this procedure requires an ATMARP client or server to support the capability to detect a change to its IP address and/or subnet mask during operation. The autoconfiguration procedure requires no changes to the packet formats specified for ATMARP and InATMARP in [1]. This procedure is not applicable to PVCs. While autoconfiguration is the preferred mode of operation for an ATMARP client, all clients must support manual configuration of their ATMARP server address. Interoperability between ATMARP servers and clients supporting this autoconfiguration procedure and those that do not is subject to the following constraints. An ATMARP server utilizing this autoconfiguration procedure must be able to service all clients in the LIS whether they support manual configuration or autoconfiguration. Therefore, this procedure requires that an ATMARP server accept calls to either the LIS-specific anycast address or its individual ATM address. For the case in which a LIS is serviced by an ATMARP server not supporting this procedure, clients are restricted to using manual configuration only. 1. ATMARP Client Autconfiguration Procedures In addition to the operational requirements specified for an ATMARP client in [1], the client, upon restart, must determine the "ATMARP Client Autoconfiguration" anycast address to use for the LIS to which it belongs. The client accomplishes this by retrieving its IP address and subnet mask and forming a subnet number. The resulting subnet number is then embedded within the designated anycast address (see ATMARP Client Autoconfiguration Anycast Address Format) and is used as the ATMARP Request Address (atm$arp-req) by the client. The client then contacts the ATMARP server to register its ATMARP information as outlined in [1] using the LIS-specific anycast address to setup the call. If, during operation in the autoconfiguration mode, a client detects that its subnet mask or IP address has changed, it must release its connection (if one exists) to the ATMARP server. If the client's subnet mask has changed, or if its IP address has changed in such a way as to affect its LIS membership, it should discard all ARP table entries associated with the affected LIS and determine the (new) LIS-specific anycast address as previously outlined. Finally, (whether or not LIS membership) has changed, the client must re- register with its LIS-designated ATMARP server. 2. ATMARP Server Autconfiguration Procedures In addition to the operational requirements specified for an ATMARP server in [1], the server, upon restart, must determine the "ATMARP Client Autoconfiguration" anycast address to use for the LIS it will serve. This is accomplished as outlined above for an ATMARP client. Upon determining the LIS-specific anycast address, the server registers it with the network using the ILMI address registration procedure [2] (see also ILMI Address Registration below). The registration of the anycast address is in addition to (not instead of) the registration of the server's individual ATM address. Upon successful registration of the anycast address with the network, an ATMARP server accepts calls/connections to either the LIS-specific anycast address or its individual ATM address as outlined in [1]. When a call/connection is established using a LIS-specific anycast address (or an individual ATM address for that matter), an ATMARP server must use its individual ATM address as the "hardware" address in any (In)ATMARP packets it exchanges with a client. The VC created as a result of a call/connection established using the LIS-specific anycast address may be shared and thus may also be used for non- address resolution traffic. If, during operation in the autconfiguration mode, a server detects that its subnet mask has changed, or that its IP address has changed in such a way as to affect its LIS membership, it must perform the following actions. First, it must deregister the appropriate anycast address from the network. The server must then release all client connections that correspond to the affected LIS and discard their associated ARP table entries. The ATMARP server then determines the new LIS-specific anycast address to be used and registers this address with the network using the ILMI address registration procedure. Upon successful completion of address registration, the server accepts calls/connections to either the (new) LIS-specific anycast address or its individual ATM address. 3. ILMI Address Registration If the autoconfiguration procedure is supported by an ATMARP server, the ILMI address registration procedure must be used to register both its individual ATM address and its LIS-specific anycast address with the network as described in [2]. The occurrence of any of the events listed below, following successful registration of these addresses, will cause the addresses to be automatically de-registered: o A coldStart Trap received from the network-side UME o Detection of a "UNI Down" condition by the user-side UME o A coldStart Trap sent by the user-side UME to the network-side UME In response to any of these events, the server must re-register the LIS-specific anycast address with the network in addition to performing ILMI address registration for the server's individual ATM address. Once the server's LIS-specific anycast address and individual ATM address have been successfully registered, the server again accepts calls/connections to either address. 4. ATMARP Client Autoconfiguration Anycast Address Format The format of the LIS-specific anycast address identifying the "ATMARP Client Autoconfiguration" service is defined according to [2] as follows: C5.0079.xx.xxxxxx.xxxx.nnnnnnnn.???????00001.00 where nnnnnnnn is the 32-bit subnet number determined by the client or server. [Note: xx digits to be assigned by the ATM Forum] 5. Open Issues One of the interesting issues concerning this scheme is how to manage the dynamic relationship existing between a Classical IP LIS and P- NNI [3] peer groups. A Classical IP LIS may overlay P-NNI peer groups in an arbitrary way. When a LIS-specific anycast address is used to set up a connection to the ARP server, the client must either explicitly supply a Connection Scope Selection IE and choose the appropriate scope for the call or use the default (Local Network) provided by the network. However, how does one choose the appropriate connection scope a priori? What happens when the underlying P-NNI topology changes such that certain clients or servers are pushed outside the scope used by other clients or servers to initially setup connections to the affected stations? What happens when the boundaries of the LIS change such that certain clients or servers end up in P-NNI peer groups outside the scope of any existing calls setup by anycast? Perhaps one approach that might be used to address these issues would be for the client, at initialization, to attempt to setup a call using the LIS-specific anycast address and the lowest possible scope. If a connection cannot be established at this scope, try the next highest scope, and so on. Once a connection has been established, the client should record the scope at which the connection was successful. If for any reason, the client's connection would be released, it could first try to re-establish the connection using the scope that was previously successful. This topic requries further consideration. 6. References [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, January 1994. [2] ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification Version 4.0", ATM Forum, December 1995. [3] ATM Forum, "PNNI Draft Specification", 94-0471R12, ATM Forum 7. Security Considerations Security issues are not addressed in this memo. 8. Acknowledgments The authors would like thank Drew Perkins (FORE Systems) for useful feedback on earlier versions of this proposal. 9. Authors' Addresses Carl Marcinik FORE Systems, Inc. Pittsburgh Office and Research Park 5800 Corporate Drive Pittsburgh, PA 15237-5829 Phone: (412) 635-3338 EMail: carlm@fore.com Fong Ching Liaw Ipsilon Networks, Inc. 2191 E. Bayshore Road, Suite 100 Palo Alto, CA 94303 Phone: (415) 846-4600 EMail: fong@ipsilon.com