HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:01:55 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 26 Feb 1996 06:41:17 GMT ETag: "2e6d92-a4b4-3131560d" Accept-Ranges: bytes Content-Length: 42164 Connection: close Content-Type: text/plain INTERNET-DRAFT Carl Marcinik Expires May 27, 1996 FORE Systems,Inc. Maryann Perez Maher ISI November 22, 1995 Distributed ATMARP Service in Classical IP over ATM Networks 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 One of the basic limitations of the ATMARP service model specified in RFC 1577 [LAUB94] is the requirement that only one ATMARP server be utilized to provide the address resolution service for a given LIS. Besides introducing a single-point-of-failure into a LIS, this model also presents obvious scaling issues. A proposal was put forth in "Classical IP and ARP over ATM Update" [LAUB95] to resolve these shortcomings through the introduction of a model supporting multiple ATMARP servers that maintain fully-replicated, synchronized address resolution databases. This model necessitates a certain amount of complexity introduced by the addition of a server database synchronization protocol. This synchronization protocol also requires additional packet types and formats as well as associated semantics. It is felt, however, that a fully-replicated, synchronized database scheme is not required to provide a reasonably robust ATMARP service that addresses the limitations of the basic model. This memo describes an alternative scheme that provides a distributed ATMARP service for a Classical IP LIS by introducing simple, straight-forward extensions to the basic model described in RFC 1577 [LAUB94]. An arbitrary number of ATMARP servers cooperate (when required) to resolve client address resolution requests in a manner that both distributes the client load among the cooperating servers and supports reasonable scaling properties. Rather than a synchronization protocol, this scheme proposes a few simple mechanisms to help maintain cache consistency between distributed ATMARP servers. Moreover, these require no additional (In)ATMARP packet types and only very minor changes to the existing packet formats and semantics (the reserved bit in the type and length fields is utilized, otherwise the formats remain unchanged). Finally, this scheme supports both the ATMARP client autoconfiguration mechanism proposed in [MAR95] as well as non-autoconfiguring (i.e., UNI 3.0/3.1) clients. Backward compatibility is also provided for existing (i.e., unmodified) RFC1577 clients. Aside from the difference in approach outlined here for supporting multiple ARP servers, this memo (for the most part) assumes the procedures contained in [LAUB95]. Other differences, where they might exist, will be explicitly stated. 1. Terminology This memo introduces a few terms that have not been used in the context of previous discussions concerning ATMARP. These terms are briefly defined here for the sake of clarity. First, this memo makes a distinction between "connected" and "unconnected" ATMARP clients. In this context, a "connected" client is a client that (persistently) maintains a connection to its ATMARP server. An "unconnected" client only uses a connection to the ATMARP server to register its address resolution information and then releases it. The term "directly-registered" is used to refer to a client's registration status relative to a given server. A client is only permitted to register its address resolution information with one server in the LIS. This server is referred to as the client's "designated" server. The client determines its "designated" server either through manual configuration (and associated procedures) or through autoconfiguration [MAR95]. When a client registers its address information with its "designated" server, the client is said to be "directly-registered" with that server regardless of whether or not the client maintains a connection to its ATMARP server (i.e., is "connected" or "unconnected"). Clients not "directly-registered" with a particular server are termed "nondirectly-registered" clients relative to that server. Finally, cache information (pertaining to a client's IP/ATM address mapping), maintained by either a client or server, is categorized as being "authoritative" or "non-authoritative." From a server perspective, "authoritative" cache information refers to cache entries maintained by the server for "directly-registered" clients. A server's cache entries for "nondirectly-registered" clients are considered "non-authoritative." From a client perspective, cache entries are considered "authoritative" only when explicitly indicated as such by the server from which they are obtained. Otherwise they are considered "non-authoritative." 2. Introduction The model proposed in this memo consists of an arbitrary number distributed ATMARP servers interconnected by means of a set of point-to-multipoint (PMP) connections. Servers accept point-to-point +---------+ | ATMARP | | Client | | | +---------+ ^ | | V +---------+ | ATMARP | | Server | | | +----+----+ ^ | ^ | | | PMP | | | Connections | | | +--------+ +--------+ | | | +--------+ +--------+ | ATMARP | | ATMARP |<---|---+---|-->| ATMARP | | ATMARP | | Client |<------>| Server |<---|-------+---+ Server |<------>| Client | | | | +----+---------->| | | | +--------+ +--------+ +--------+ +--------+ Figure 1 Distributed ATMARP Model connections from both autconfiguring [MAR95] and non-autoconfiguring ATMARP clients. The clients utilize their point-to-point connections to register their address resolution (i.e., IP address/ATM address mapping) information with their designated server. Subsequently, clients perform address resolution operations to obtain mapping information (which they cache locally) for destinations throughout the LIS. Servers use their PMP connections to distribute client mapping information among all the ATMARP servers serving the LIS. Each server caches this mapping information but may also query all servers simultaneously to obtain mapping information needed to resolve a client's request when the information is not available in its local cache. A representative example of this model is shown in Figure 1. While the server connection topology employed here is perhaps more constrained than that proposed in [LAUB95], it is simpler to maintain and may be more amenible to possible server autoconfiguration mechanisms (see Section X). Although [LAUB95] permits an arbitrary server connection topology, creating such a topology is accomplished entirely through manual configuration. It is felt that supporting an arbitrary server topology might provide some benefit, however, to be most useful such a scheme would require additional protocol mechanisms. These mechanisms would be needed to maintain the server topology in the face of dynamic topology changes. Such mechanisms would result in considerable cost, in terms of protocol complexity (e.g., loop detection, partition repair, etc.), and are felt to be too expensive to warrant this approach. However, even if it were deemed necessary or desirable to provide such support, the basic model described here could be employed as long as server packets could be forwarded to, and received from, each of the other cooperating servers in the LIS. 3. Overview A client must register its address resolution information upon its initialization using the applicable registration procedures in RFC 1577 [LAUB94] or in [LAUB95]. Included in the client registration procedure is need for the client to locate its designated server. This memo supports the ATMARP client autconfiguration proposal described in [MAR95] which essentially allows a client to locate and connect to its designated ATMARP server by utilizing a LIS-specific anycast address (determined a priori). While this mode of client operation is preferred, this scheme also supports non-autoconfiguring clients as well (e.g., a client supporting only UNI 3.0/UNI 3.1 signalling capability). A non-autoconfiguring client must be administratively configured with the ATM address of each ATMARP server in the LIS. The client randomly selects its designated server and then establishes a connection to it. Utilizing either of these procedures, clients are distributed to cooperating servers throughout the LIS. The client registers its address resolution information with its server using the previously established connection. The server, in turn, reliably distributes the client's mapping information to all cooperating servers in the LIS using its (outgoing) point-to- multipoint connection (replys are returned on the incoming VCs associated with the other servers' leaf nodes) Each server caches the client information which is updated from time to time when the client re-registers as part of its refresh operations. Of particular interest is the means by which address resolution operations are carried out by the scheme proposed in this memo. Servers attempt to resolve client address resolution requests from their local caches, if possible. If a server cannot resolve a request with mapping information contained in its own cache, it forwards the request to all other servers and awaits a response. A server may elect to solicit a reply for either authoritative or non- authoritative cache information. In the authoritative case, only the server with a directly-registered client matching the target IP address in the request may reply. In the non-authoritative case, any (and every) server that contains the sought after cache information may reply. The approach utilizing an authoritative reply requires the least amount of overhead and minimizes the propagation of stale cache information to other servers and clients in the LIS. The proposal put forth in [LAUB95] requires that any server in a LIS be able to resolve an address resolution request received from any client that is a member of the same LIS. The way in which this is achieved is by ensuring that every server fully replicates all cache entries for all the clients in the LIS. The scheme proposed here aims to achieve the same goal (i.e., any server can resolve a client's request), but does so in a slightly different manner. Instead of "guaranteeing" (with a high degree of probability) that each server will have the cache entry needed to resolve a given client request, this scheme "guarantees" (with a high degree of probability) that, if a client's designated server cannot resolve the request from its own cache, it can obtain the information needed from another server. The scheme, therefore, approximates a fully-replicated database from a client perspective, but uses fewer and simpler mechanisms to do so. The goal is to be able to satisfy any client request at any server without allowing a period of non-connectivity to exist for any client. For unconnected clients, the possibility exists that a designated server could lose its client mapping information for directly-registered clients (e.g., due to a server crash). In such a case, a designated server will not be able to resolve a request for such clients until those clients refresh their address resolution information. This scheme allows servers with non-authoritative cache information (however, only cache information previously obtained from an authoritative source) to answer a request for such information. Since client information for each client is reliably propagated to all other servers when a client registers, we can "guarantee" with a high degree of probability that another server on the LIS has the information needed. The probability increases as the number of servers in the LIS increases. As intimated above, there are two possible schemes that may be employed for address resolution operations discussed in this memo. Each will interoperate with the other so servers are free to implement either one. If a server receives an address resolution request that it cannot resolve from its own cache, it basically has two choices: it can forward a request for either authoritative cache information or non-authoritative cache information to all the other servers in the LIS. Authoritative cache information is desirable, but the requesting server cannot be absolutely sure that it can be obtained. It is more certain, however, that it can obtain non- authoritative information. Just to be clear: only the server with cache information for a directly-registered client may respond to a request for authoritative cache information. However, any server (including the server holding the authoritative answer) may respond to a request for non-authoritative information if it can provide the answer with cache information obtained from an authoritative source (e.g., a server forwarding address resolution information as a result of a client's registration) These two choices lead to two strategies, the first being: Try to obtain an authoritative reply. If this is unsuccessful, try to obtain a non-authoritative reply. If this is unsuccessful, then the address resolution request fails. This strategy leads to less stale cache information in the network, but could occasionally suffer from a delayed response to the client. However, viewed from an amortized perspective, this may be the most preferred strategy. The other strategy is obvious: Try to obtain non-authoritative information first. If the initial request fails to produce any responses (not very likely) within a short, bounded period of time, retry the request a small number of times. If this is unsuccessful, then the address resolution request fails. This strategy will produce an answer with less delay in the case where there is no authoritative cache information in the LIS (e.g., due to a server crash). However, this will also propagate more stale cache information throughout the LIS. This is somewhat offset by requiring both servers and clients to impose a more strict limit on the lifetime on cache information obtained from a non-authoritative source. Furthermore, servers are only permitted to return cache information obtained from an authoritative source in non-authoritative replys. Finally, unconnected clients are required to refresh their address resolution information more often (perhaps as much as three times the rate of a connected client, e.g., once every 5 minutes). The remaining sections in this memo focus on specifying the details of this scheme. Section 4 presents the details of client registration and the associated server procedures. Section 5 focuses on the details of address resolution operations for both clients and servers. Section 6 discusses server failure and recovery. Section 7 presents the minor modifications required to the ATMARP packet formats to support this scheme. 4. ATMARP Registration Procedures 4.1 ATMARP Server Startup Procedures Before any client registrations can be accepted, each server must establish an outgoing point-to-multipoint connection, with each of the cooperating ATMARP servers in the LIS as leaves, using the applicable procedures outlined in RFC 1755 [PEREZ95] or UNI 4.0 [ATMF95]. This is necessary so that all client registration information can be propagated to all other servers as clients begin to register. Currently this scheme requires that the identity of cooperating servers be determined by examining a list of individual ATM addresses administratively configured at each server. Each server must be identically configured with regard to the number and value of the ATM addresses supported with the obvious exception that the server, itself, is not included in the list. While a server autoconfiguration procedure would be desirable (and may be specified in a future version of this or another memo; see Section X), all servers must support administrative configuration of all other cooperating servers in the LIS. A failure to successfully add a server to the existing point-to- multipoint call should be continuously retried, backing off each time until a reasonable "polling" rate is achieved. A persistent failure to add a server may indicate a configuration error and therefore should be reported through the server's management facility. During this period of time, a server must also accept incoming point-to- multipoint calls from other servers so that it may be added as a leaf on PMP calls originating from other servers. A server may reject incoming point-to-multipoint call attempts if the calling address contained in the setup message does not match any of the ATM addresses of its configured servers. After all servers have been added to the server's own outgoing point-to-multipoint call (notwithstanding signalling problems for certain parties), servers must be prepared to accept incoming calls from clients that have identified this server as being their designated server. Servers supporting the ATMARP client autoconfiguration procedure, must also perform the required server initialization outlined in [MAR95]. 4.2 ATMARP Client Startup Procedures In order to facilitate server initialization operations, ATMARP clients should delay the start of the client registration procedure by a random period of time of between TBD and TBD seconds. Note, however, that an RFC 1577 client will not necessarily delay the start of its registration procedure. Therefore, an RFC 1577 client may initially experience setup failures if the network is in a mode where all ATMARP servers (and in particular its own server) are simultaneously initializing. Once this period of random delay has elapsed, a client must determine its designated server. For autoconfiguring clients, this procedure is outlined in [MAR95]. For non-autoconfiguring clients supporting this scheme, this is accomplished by randomly choosing an address from its list of administratively configured server ATM addresses. Each client supporting this procedure, whether capable of autoconfiguration operation or not, must provide a means of being administratively configured with the ATM addresses of all the cooperating servers in the LIS. No ordering or priority is necessarily to be imposed on the configured server addresses. The default behavior of a non-autoconfiguring client is to choose a server address at random as its designated server. However, all implementations must support the capability to override this default behavior so that an ordering or priority among the configured addresses can be obtained. Each client must support the capability to be administratively configured with the maximum number of servers supported for a LIS. This number is TBD. RFC 1577 clients may be configured with any of the individual ATM addresses of any server on the LIS as its atm$arp-req address. 4.3 ATMARP Client Registration Procedures Client registration procedures may be initiated as part of a client's initial startup sequence or due to the necessity of the client to refresh its address resolution information (see section 4.5). Once a client determines its designated server, it must establish a connection to that server and register its address resolution information. For autoconfiguring clients this is accomplished by utilizing a LIS-specific anycast address and following the procedures outlined in [MAR95] and [LAUB95]. A non-autoconfiguring client supporting this scheme must follow the procedures outlined in [LAUB95]. RFC 1577 clients follow the procedures outlined in [LAUB94]. Note that clients based on [LAUB95] will use an ATMARP_Request with both the source and target addresses set to its own address resolution information to register itself, while RFC 1577 client registration will now occur implicitly. If a non-RFC 1577 client's initial attempt to connect to its designated server fails, it is suggested that the client use a simple exponential backoff algorithm before retrying the setup. This may be necessary to avoid a "setup" storm that might occur during periodic client refresh operations or perhaps during a server failure. In no case, however, should a client allow the cumulative time spent trying to establish a connection to its designated server to exceed TBD seconds. This is required to support an upper bound on the amount of time that occurs before a client initiates recovery operations (see Section 6). It is necessary for a client to wait until its registration information has been reliably propagated to all the cooperating servers in the LIS (that are currently operable) before it receives a reply. Non-RFC 1577 clients must allow, at a minimum, TBD seconds for this to be accomplished. If this period of time elapses before a reply is received, the client should retry the registration. If the registration is still not successful after TBD attempts, the client initiates recovery operations. 4.4 ATMARP Server Registration Procedures 4.4.1 Considerations The main goal of the server registration procedures is to reliably distribute a client's address resolution information to all the cooperating servers in the LIS so that such information may be cached. Among the issues that must be considered in accomplishing this goal is how (if at all) the client's address resolution information is related to other information already cached throughout the LIS. It is imperative that, as a result of the server registration procedure, inconsistencies not be introduced into the servers' caches. In particular, three cases stand out as areas of concern: 1. A client is attempting to register an IP address that is already cached in the LIS, but with a different ATM address and an open connection is associated with the cache entry 2. A client is attempting to register an IP address that is already cached in the LIS, but with a different ATM address and no open connection is associated with the cache entry 3. A client is attempting to register an IP address not currently cached in the LIS, however, the client's ATM address is associated with another IP address that is already cached The first case will normally occur as the result of a pair of mis- configured hosts. In a single server environment, this situation is easily detected by performing a "duplicate IP address" test. The results of this test could be used to deny registration to the requesting client, if the client's IP address proved to be a duplicate. However, performing this test, and denying service if it fails, is no easy task in a distributed environment. This would seem to require a two phase "lock and commit" database type of operation to be performed across all the servers in the LIS. Since we obviously don't know ahead of time if a particular client registration is a duplicate or not, we would need to check every client registration. Since a client is required to re-register periodically, the more clients we add to the LIS, the more often we would be performing this check. This would lead to a great deal of overhead. Another consideration here is, although it is bound to happen, the occurrence of this event is expected to be very low. The second case would be most likely to occur as a result of a client's physical connection being moved to another UNI, probably located on a switch other than it was connected to when it last registered. The action of moving the physical cable would have released the connection to the ATMARP server and caused the mapping between the IP address/ATM address to change. This action would have also necessitated that the client reconnect and re-register with the ARP server. It is claimed that this case is most likely to explain the second case because a connection is not currently associated with the cache entry. However, this case could be equivalent to the first case if the previously registered client did not maintain a connection to the ATMARP server. Nevertheless, it is felt that more times than not, a "change" operation has occurred in this case. Therefore, rather than deny registration we would want this new mapping to take effect throughout the LIS as rapidly as possible. The third case is not very likely to happen given the wide acceptance and implementation of the ILMI address registration procedure [ATM95]. Most ATM address configuration is removed from human hands and so we are unlikely to end up with this case. Given the above considerations, it seems that the server registration procedure should be optimized for the second case. While the first case is cause for concern, it is not expected to occur as often as the second. We propose to adopt a policy of "last registration always overrides an earlier registration" as opposed to that supported by the policy of the "detection and denial" model which is "first registration always wins." In the absence of any specific security mechanisms, the "last registration overrides" policy is just as valid as denying a registration. Furthermore, this policy is much simpler to implement in a distributed scheme and simplifies the processing when a duplicate entry is discovered at a server other than the one where a registration originated. If the first case were to occur and persist, then it is likely that this scheme will thrash about waiting for something or someone to correct the problem. However, this behavior is not so much different than what has been observed with other address resolution protocols. 4.4.2 Procedures Server registration procedures are initiated upon receiving an ATMARP_Request packet from a client with the source and target IP addresses equal ("explicit" case) or an ATMARP_Request packet is received from a client and the server does not have a corresponding cache entry (implicit case). After updating (or creating) its local cache entry according to the policy described above, the server must forward the client's address resolution reliably to each of the other servers in the LIS. This is accomplished by forwarding a Server ATMARP_Request, containing the client's mapping information, over the sever's outgoing point-to- multipoint VC and awaiting for a Server ARP_Reply reply from each server. Note that if a timeout occurs while waiting for a reply, resending the request will cause all servers to receive the request again (unless perhaps one or more of the servers missed the previous one). When a server receives a Server ATMARP_Request, it creates or updates its local cache entry according to the policy described above. After the entry is updated, the server forwards an ATMARP_Reply to the server from which it was received. After the initiating server receives ATMARP_Replys from all the servers, it sends an ATMARP_Reply to the client (explicitly or implicitly) initiating the registration. 4.5 Client Refresh Procedures TBD 5. Address Resolution Procedures 5.1 Client Address Resolution Procedures ATMARP clients attempt to resolve IP addresses to ATM addresses by examining their local address resolution cache. If a client's address resolution cache does not contain an entry matching the sought after IP address, it must send an ATMARP_Request to its designated server in order to obtain the desired mapping information as outlined in the applicable procedures [LAUB94, LAUB95] and as augmented by this memo. The scheme presented here is completely backward compatible with RFC 1577 clients. There are only minor differences for non-RFC 1577 clients. After sending an ATMARP_Request to its designated server, the client awaits for a corresponding ATMARP_Reply. An ATMARP_Reply returned to an RFC 1577 client is handled as outlined in [LAUB94]. However, an ATMARP_Reply returned to a non-RFC 1577 client may require slightly different handling. This is due to the possibility that the mapping information returned in the reply may have been obtained second hand. In other words, the client's designated server may have not been able to resolve the request from its own cache and therefore would have had to obtain the sought after information from another server. Depending on the strategy employed, the information returned to the requesting server (i.e., the requesting client's designated server) may have been non-authoritative. If this is were the case, then a more restrictive limit must be used on the lifetime of the mapping information to be cached by the client. This is necessary to avoid having stale cache information persist in the client's cache thus reducing that the possibility that the client will experience any period of non-connectivity due to such stale cache information. ([LAUB95] requires a client to purge a cache entry when a failure to connect to another client occurs. Following this, the client sends an ATMARP_Request to try to obtain fresh cache information. The caching scheme employed in this memo attempts to limit this type of activity.) For non-RFC 1577 clients, the NON-AUTHORITATIVE bit (see section X) is set when second hand cache information is returned to the client. This is an indication to the client that it needs to use the restricted cache timeout value when completing the cache entry. This value is defined as TBD seconds. If the NON-AUTHORITATIVE bit is clear in a reply received by a non-RFC 1577 client, then normal packet handling procedures apply. For backward compatibility with RFC 1577 clients, the NON-AUTHORITATIVE bit is never set so such clients are more susceptible to the issues discussed above. [Most RFC 1577 implementations were modified to accommodate the "non-connectivity because of stale cache information" problem so most of these implementations should eventually recover from this condition.] Because of the differences between the distributed ATMARP scheme presented in this memo and the approach outlined in [LAUB95], the handling of an ARP_Nak is slightly different and actually results in significantly simpler client behavior. In [LAUB95] the receipt of an ARP_Nak requires the client to query another ATMARP server in an attempt to resolve its request. In fact, in the worst case, the client would need to query all the address resolution servers in the LIS. This approach complicates the client behavior and significantly increases the delay required to resolve a request (in the worst case). The approach taken in this memo essentially retains the original ARP_Nak semantics as defined in RFC 1577 [LAUB94]. Because the scheme presented here ensures that all servers in the LIS are queried (simultaneously) if a designated server does not contain a cache entry matching the target IP address in a request, it can provide the answer in a definitive manner as to whether the information exists anywhere in the LIS. This approach, therefore, maintains characteristics similar to a single ATMARP server for this case as well as the normal case. Non-RFC 1577 clients must allow at least TBD seconds for the ATMARP server to return a reply to its request. If a timeout occurs, the client should retry the request a small number of times. If a reply is still not obtained, the client may initiate recovery procedures (see Section 6). RFC 1577 behavior remains the same for this case. 5.2 Server Address Resolution Procedures Server address resolution operations are initiated upon the receipt of an ATMARP_Request from a client or from another server. In the case of an ATMARP_Request received from a client, a (designated) server attempts to resolve the request from entries contained in its local address resolution cache. If an entry is found, the sought after information is extracted and returned to the client in an ATMARP_Reply. Before returning a reply, however, the server must perform a series of checks to determine if it should set the NON- AUTHORITATIVE bit in the ATMARP_Reply If the client request can be satisfied with cache information from (another) directly-registered client, then no further considerations are necessary and the ATMARP_Reply is returned to requesting client with the NON-AUTHORITATIVE bit clear. However, if the server is holding a cache entry that can satisfy the request, but the entry does not correspond to a directly-registered client, then the server must determine how this cache information was obtained. If the cache entry was created from an authoritative reply, or from a relayed client registration, then the ATMARP_Reply is returned with the NON- AUTHORITATIVE bit clear. If, however, the cache entry was created from a non-authoritative reply, then the type of requesting client must be determined, if known. This information is normally recorded at the time the client registered. If requesting client registered implicitly, then for backward compatibility reasons the NON- AUTHORITATIVE bit cannot be set. However, if the client is known to be a non-RFC 1577 client then the NON-AUTHORITATIVE bit must be set so that the appropriate client handling procedures can be performed. If the server is not holding a cache entry matching the requested IP address, then it must query all the other servers in the LIS for the answer. The sequence used to perform this query is somewhat dependent on the strategy employed by the server. Two interoperable strategies were outlined in section 2. For the sake of brevity only the first strategy will be detailed here. A server sends a Server ATMARP_Request (see section 7) over its outgoing point-to-multipoint VC to forward the request to all other servers in the LIS. The Server ATMARP_Request carries the server's address information in the source address fields, and the IP address to be resolved in the target protocol address field. To indicate a request for authoritative cache information (in keeping with the goals of the first strategy), both the REGISTRATION and the NON- AUTHORITATIVE bits are clear. A server receiving a Server ATMARP_Request for authoritative cache information examines its cache to determine if it has a matching entry. If a cache entry was found, and if the entry corresponds to a directly-registered client, the server forms a Server ATMARP_Reply using the information found in the entry and returns the reply to the requesting server. Otherwise, the server discards the request. [Would it be better to have servers send NAKs if they do not find authoritative information?] When the requesting server receives the Server ARP_Reply, it completes its cache entry and forwards the reply on to the requesting client. 6. Server Failure Detection and Recovery Depending on how an ATMARP server failure occurs, the client may or may not immediately detect its failure. If a client maintains a connection to the ARP server then it probably has a better chance of detecting a problem sooner (again, depending on the failure). In any event, the client will probably initiate recovery operations when it repeatedly fails to connect to its designated server or when the client fails to receive an expected reply from the server after several retry attempts. Note, if the client still has a connection established to the server (e.g., the timeout case), then it must release it. When its connection to the ATMARP server is released, the client must attempt to reconnect and re-register its ATMARP information. If the client is non- autoconfiguring then a new server address should be selected at random (ensuring that a different address is indeed selected). For autoconfiguring clients, anycast will "search" for the new server (presumably, the failed server's anycast address will eventually be de-registered by an ILMI connectivity timeout if' nothing else). During the period of time that it is setting up a call, the client may continue to use its cache to resolve addresses. When the client succeeds in establishing a new connection to its (new) server, and registers its address resolution information, it may then resolve any pending requests. Notice that when a client re-registers (as above) the (new) server will record the client as being "directly-registered." Once a failed server is returned to service, it is necessary that the clients that have failed over to the (new) server, return to the original server. This happens automatically in this scheme when the clients refresh their address resolution information with the server. As part of a modified refresh operation, the clients must release their current connection and setup a new call. For autoconfiguring clients this is done using the appropriate anycast address; non-autoconfiguring clients choose a new server address at random from those it has configured. 7. Packet Formats TBD 8. VC Resource Requirements One consideration for this scheme is its use of VC resources. The requirements in terms of VCs for the server-server case is N (N - 1) incoming VCs [the leafs associated with the (N - 1) incoming PMP connections per server, where N = the number of servers in a LIS] and N outgoing VCs for the root of each PMP call to each of the (N - 1) other servers. So the total VC requirements for server-server interaction are N**2 VCs per LIS. Each server would as well need to support an additional M/N (with M = the number of clients in the LIS) bidirectional VCs for client-server interaction (assuming clients are distributed uniformly across multiple servers). So the total VC requirements for each server would then be N + M/N VCs and N**2 + N (M/N) = N**2 + M VCs for all servers in a LIS. 9. Acknowledgments The authors would like to thank Mike Kazar (FORE Systems) for useful feedback concerning some of the cache issues discussed in this memo. 10. References [LAUB94] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, January 1994. [LAUB95] Laubach, M., "Classical IP and ARP over ATM Update", draft-ietf-ipatm-classic2-00.txt, Internet Draft (work in progress), August 1995. [ATMF95] ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification Version 4.0", ATM Forum, December 1995. [MAR95] Marcinik, C., Liaw, F., "ATMARP Client Autoconfiguration", draft-marcinik-ipatm-auto-arp-00.txt, Internet Draft (work in progress), November 1995. [PEREZ95] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, ISI, Fore, Motorola Codex, Ascom Timeplex, February 1995. 11. Security Considerations Security issues are not addressed in this memo. 12. Authors' Addresses Carl Marcinik FORE Systems, Inc. Pittsburgh Office and Research Park Pittsburgh, PA 15237-5829 Phone: (412) 625-9051 Email: carlm@fore.com Maryann Perez Maher USC/Information Sciences Institute 4350 N. Fairfax Drive Suite 400 Arlington, VA 22203 Phone: 703-807-0132 EMail: perez@isi.edu