idnits 2.17.00 (12 Aug 2021) /tmp/idnits38287/draft-marcinik-ipatm-dist-atmarp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 781 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MAR95], [LAUB94], [LAUB95]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 97 has weird spacing: '...ntained by ei...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 22, 1995) is 9677 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ATM95' is mentioned on line 467, but not defined ** Obsolete normative reference: RFC 1577 (ref. 'LAUB94') (Obsoleted by RFC 2225) -- No information found for draft-ietf-ipatm-classic2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LAUB95' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATMF95' -- Possible downref: Normative reference to a draft: ref. 'MAR95' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carl Marcinik 2 Expires May 27, 1996 FORE Systems,Inc. 3 Maryann Perez Maher 4 ISI 5 November 22, 1995 7 Distributed ATMARP Service in Classical IP over ATM Networks 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 One of the basic limitations of the ATMARP service model specified in 32 RFC 1577 [LAUB94] is the requirement that only one ATMARP server be 33 utilized to provide the address resolution service for a given LIS. 34 Besides introducing a single-point-of-failure into a LIS, this model 35 also presents obvious scaling issues. A proposal was put forth in 36 "Classical IP and ARP over ATM Update" [LAUB95] to resolve these 37 shortcomings through the introduction of a model supporting multiple 38 ATMARP servers that maintain fully-replicated, synchronized address 39 resolution databases. This model necessitates a certain amount of 40 complexity introduced by the addition of a server database 41 synchronization protocol. This synchronization protocol also requires 42 additional packet types and formats as well as associated semantics. 43 It is felt, however, that a fully-replicated, synchronized database 44 scheme is not required to provide a reasonably robust ATMARP service 45 that addresses the limitations of the basic model. 47 This memo describes an alternative scheme that provides a distributed 48 ATMARP service for a Classical IP LIS by introducing simple, 49 straight-forward extensions to the basic model described in RFC 1577 50 [LAUB94]. An arbitrary number of ATMARP servers cooperate (when 51 required) to resolve client address resolution requests in a manner 52 that both distributes the client load among the cooperating servers 53 and supports reasonable scaling properties. Rather than a 54 synchronization protocol, this scheme proposes a few simple 55 mechanisms to help maintain cache consistency between distributed 56 ATMARP servers. Moreover, these require no additional (In)ATMARP 57 packet types and only very minor changes to the existing packet 58 formats and semantics (the reserved bit in the type and length fields 59 is utilized, otherwise the formats remain unchanged). Finally, this 60 scheme supports both the ATMARP client autoconfiguration mechanism 61 proposed in [MAR95] as well as non-autoconfiguring (i.e., UNI 62 3.0/3.1) clients. Backward compatibility is also provided for 63 existing (i.e., unmodified) RFC1577 clients. Aside from the 64 difference in approach outlined here for supporting multiple ARP 65 servers, this memo (for the most part) assumes the procedures 66 contained in [LAUB95]. Other differences, where they might exist, 67 will be explicitly stated. 69 1. Terminology 71 This memo introduces a few terms that have not been used in the 72 context of previous discussions concerning ATMARP. These terms are 73 briefly defined here for the sake of clarity. 75 First, this memo makes a distinction between "connected" and 76 "unconnected" ATMARP clients. In this context, a "connected" client 77 is a client that (persistently) maintains a connection to its ATMARP 78 server. An "unconnected" client only uses a connection to the ATMARP 79 server to register its address resolution information and then 80 releases it. 82 The term "directly-registered" is used to refer to a client's 83 registration status relative to a given server. A client is only 84 permitted to register its address resolution information with one 85 server in the LIS. This server is referred to as the client's 86 "designated" server. The client determines its "designated" server 87 either through manual configuration (and associated procedures) or 88 through autoconfiguration [MAR95]. When a client registers its 89 address information with its "designated" server, the client is said 90 to be "directly-registered" with that server regardless of whether or 91 not the client maintains a connection to its ATMARP server (i.e., is 92 "connected" or "unconnected"). Clients not "directly-registered" with 93 a particular server are termed "nondirectly-registered" clients 94 relative to that server. 96 Finally, cache information (pertaining to a client's IP/ATM address 97 mapping), maintained by either a client or server, is categorized as 98 being "authoritative" or "non-authoritative." From a server 99 perspective, "authoritative" cache information refers to cache 100 entries maintained by the server for "directly-registered" clients. A 101 server's cache entries for "nondirectly-registered" clients are 102 considered "non-authoritative." From a client perspective, cache 103 entries are considered "authoritative" only when explicitly indicated 104 as such by the server from which they are obtained. Otherwise they 105 are considered "non-authoritative." 107 2. Introduction 109 The model proposed in this memo consists of an arbitrary number 110 distributed ATMARP servers interconnected by means of a set of 111 point-to-multipoint (PMP) connections. Servers accept point-to-point 113 +---------+ 114 | ATMARP | 115 | Client | 116 | | 117 +---------+ 118 ^ 119 | 120 | 121 V 122 +---------+ 123 | ATMARP | 124 | Server | 125 | | 126 +----+----+ 127 ^ | ^ 128 | | | PMP 129 | | | Connections 130 | | | 131 +--------+ +--------+ | | | +--------+ +--------+ 132 | ATMARP | | ATMARP |<---|---+---|-->| ATMARP | | ATMARP | 133 | Client |<------>| Server |<---|-------+---+ Server |<------>| Client | 134 | | | +----+---------->| | | | 135 +--------+ +--------+ +--------+ +--------+ 137 Figure 1 Distributed ATMARP Model 139 connections from both autconfiguring [MAR95] and non-autoconfiguring 140 ATMARP clients. The clients utilize their point-to-point connections 141 to register their address resolution (i.e., IP address/ATM address 142 mapping) information with their designated server. Subsequently, 143 clients perform address resolution operations to obtain mapping 144 information (which they cache locally) for destinations throughout 145 the LIS. Servers use their PMP connections to distribute client 146 mapping information among all the ATMARP servers serving the LIS. 147 Each server caches this mapping information but may also query all 148 servers simultaneously to obtain mapping information needed to 149 resolve a client's request when the information is not available in 150 its local cache. A representative example of this model is shown in 151 Figure 1. 153 While the server connection topology employed here is perhaps more 154 constrained than that proposed in [LAUB95], it is simpler to maintain 155 and may be more amenible to possible server autoconfiguration 156 mechanisms (see Section X). Although [LAUB95] permits an arbitrary 157 server connection topology, creating such a topology is accomplished 158 entirely through manual configuration. It is felt that supporting an 159 arbitrary server topology might provide some benefit, however, to be 160 most useful such a scheme would require additional protocol 161 mechanisms. These mechanisms would be needed to maintain the server 162 topology in the face of dynamic topology changes. Such mechanisms 163 would result in considerable cost, in terms of protocol complexity 164 (e.g., loop detection, partition repair, etc.), and are felt to be 165 too expensive to warrant this approach. However, even if it were 166 deemed necessary or desirable to provide such support, the basic 167 model described here could be employed as long as server packets 168 could be forwarded to, and received from, each of the other 169 cooperating servers in the LIS. 171 3. Overview 173 A client must register its address resolution information upon its 174 initialization using the applicable registration procedures in RFC 175 1577 [LAUB94] or in [LAUB95]. Included in the client registration 176 procedure is need for the client to locate its designated server. 177 This memo supports the ATMARP client autconfiguration proposal 178 described in [MAR95] which essentially allows a client to locate and 179 connect to its designated ATMARP server by utilizing a LIS-specific 180 anycast address (determined a priori). While this mode of client 181 operation is preferred, this scheme also supports non-autoconfiguring 182 clients as well (e.g., a client supporting only UNI 3.0/UNI 3.1 183 signalling capability). A non-autoconfiguring client must be 184 administratively configured with the ATM address of each ATMARP 185 server in the LIS. The client randomly selects its designated server 186 and then establishes a connection to it. Utilizing either of these 187 procedures, clients are distributed to cooperating servers throughout 188 the LIS. The client registers its address resolution information with 189 its server using the previously established connection. The server, 190 in turn, reliably distributes the client's mapping information to all 191 cooperating servers in the LIS using its (outgoing) point-to- 192 multipoint connection (replys are returned on the incoming VCs 193 associated with the other servers' leaf nodes) Each server caches the 194 client information which is updated from time to time when the client 195 re-registers as part of its refresh operations. 197 Of particular interest is the means by which address resolution 198 operations are carried out by the scheme proposed in this memo. 199 Servers attempt to resolve client address resolution requests from 200 their local caches, if possible. If a server cannot resolve a request 201 with mapping information contained in its own cache, it forwards the 202 request to all other servers and awaits a response. A server may 203 elect to solicit a reply for either authoritative or non- 204 authoritative cache information. In the authoritative case, only the 205 server with a directly-registered client matching the target IP 206 address in the request may reply. In the non-authoritative case, any 207 (and every) server that contains the sought after cache information 208 may reply. The approach utilizing an authoritative reply requires the 209 least amount of overhead and minimizes the propagation of stale cache 210 information to other servers and clients in the LIS. 212 The proposal put forth in [LAUB95] requires that any server in a LIS 213 be able to resolve an address resolution request received from any 214 client that is a member of the same LIS. The way in which this is 215 achieved is by ensuring that every server fully replicates all cache 216 entries for all the clients in the LIS. The scheme proposed here aims 217 to achieve the same goal (i.e., any server can resolve a client's 218 request), but does so in a slightly different manner. Instead of 219 "guaranteeing" (with a high degree of probability) that each server 220 will have the cache entry needed to resolve a given client request, 221 this scheme "guarantees" (with a high degree of probability) that, if 222 a client's designated server cannot resolve the request from its own 223 cache, it can obtain the information needed from another server. The 224 scheme, therefore, approximates a fully-replicated database from a 225 client perspective, but uses fewer and simpler mechanisms to do so. 227 The goal is to be able to satisfy any client request at any server 228 without allowing a period of non-connectivity to exist for any 229 client. For unconnected clients, the possibility exists that a 230 designated server could lose its client mapping information for 231 directly-registered clients (e.g., due to a server crash). In such a 232 case, a designated server will not be able to resolve a request for 233 such clients until those clients refresh their address resolution 234 information. This scheme allows servers with non-authoritative cache 235 information (however, only cache information previously obtained from 236 an authoritative source) to answer a request for such information. 237 Since client information for each client is reliably propagated to 238 all other servers when a client registers, we can "guarantee" with a 239 high degree of probability that another server on the LIS has the 240 information needed. The probability increases as the number of 241 servers in the LIS increases. 243 As intimated above, there are two possible schemes that may be 244 employed for address resolution operations discussed in this memo. 245 Each will interoperate with the other so servers are free to 246 implement either one. If a server receives an address resolution 247 request that it cannot resolve from its own cache, it basically has 248 two choices: it can forward a request for either authoritative cache 249 information or non-authoritative cache information to all the other 250 servers in the LIS. Authoritative cache information is desirable, but 251 the requesting server cannot be absolutely sure that it can be 252 obtained. It is more certain, however, that it can obtain non- 253 authoritative information. Just to be clear: only the server with 254 cache information for a directly-registered client may respond to a 255 request for authoritative cache information. However, any server 256 (including the server holding the authoritative answer) may respond 257 to a request for non-authoritative information if it can provide the 258 answer with cache information obtained from an authoritative source 259 (e.g., a server forwarding address resolution information as a result 260 of a client's registration) 262 These two choices lead to two strategies, the first being: Try to 263 obtain an authoritative reply. If this is unsuccessful, try to obtain 264 a non-authoritative reply. If this is unsuccessful, then the address 265 resolution request fails. This strategy leads to less stale cache 266 information in the network, but could occasionally suffer from a 267 delayed response to the client. However, viewed from an amortized 268 perspective, this may be the most preferred strategy. 270 The other strategy is obvious: Try to obtain non-authoritative 271 information first. If the initial request fails to produce any 272 responses (not very likely) within a short, bounded period of time, 273 retry the request a small number of times. If this is unsuccessful, 274 then the address resolution request fails. This strategy will produce 275 an answer with less delay in the case where there is no authoritative 276 cache information in the LIS (e.g., due to a server crash). However, 277 this will also propagate more stale cache information throughout the 278 LIS. This is somewhat offset by requiring both servers and clients to 279 impose a more strict limit on the lifetime on cache information 280 obtained from a non-authoritative source. Furthermore, servers are 281 only permitted to return cache information obtained from an 282 authoritative source in non-authoritative replys. Finally, 283 unconnected clients are required to refresh their address resolution 284 information more often (perhaps as much as three times the rate of a 285 connected client, e.g., once every 5 minutes). 287 The remaining sections in this memo focus on specifying the details 288 of this scheme. Section 4 presents the details of client registration 289 and the associated server procedures. Section 5 focuses on the 290 details of address resolution operations for both clients and 291 servers. Section 6 discusses server failure and recovery. Section 7 292 presents the minor modifications required to the ATMARP packet 293 formats to support this scheme. 295 4. ATMARP Registration Procedures 297 4.1 ATMARP Server Startup Procedures 299 Before any client registrations can be accepted, each server must 300 establish an outgoing point-to-multipoint connection, with each of 301 the cooperating ATMARP servers in the LIS as leaves, using the 302 applicable procedures outlined in RFC 1755 [PEREZ95] or UNI 4.0 303 [ATMF95]. This is necessary so that all client registration 304 information can be propagated to all other servers as clients begin 305 to register. Currently this scheme requires that the identity of 306 cooperating servers be determined by examining a list of individual 307 ATM addresses administratively configured at each server. Each 308 server must be identically configured with regard to the number and 309 value of the ATM addresses supported with the obvious exception that 310 the server, itself, is not included in the list. While a server 311 autoconfiguration procedure would be desirable (and may be specified 312 in a future version of this or another memo; see Section X), all 313 servers must support administrative configuration of all other 314 cooperating servers in the LIS. 316 A failure to successfully add a server to the existing point-to- 317 multipoint call should be continuously retried, backing off each time 318 until a reasonable "polling" rate is achieved. A persistent failure 319 to add a server may indicate a configuration error and therefore 320 should be reported through the server's management facility. During 321 this period of time, a server must also accept incoming point-to- 322 multipoint calls from other servers so that it may be added as a leaf 323 on PMP calls originating from other servers. A server may reject 324 incoming point-to-multipoint call attempts if the calling address 325 contained in the setup message does not match any of the ATM 326 addresses of its configured servers. After all servers have been 327 added to the server's own outgoing point-to-multipoint call 328 (notwithstanding signalling problems for certain parties), servers 329 must be prepared to accept incoming calls from clients that have 330 identified this server as being their designated server. Servers 331 supporting the ATMARP client autoconfiguration procedure, must also 332 perform the required server initialization outlined in [MAR95]. 334 4.2 ATMARP Client Startup Procedures 336 In order to facilitate server initialization operations, ATMARP 337 clients should delay the start of the client registration procedure 338 by a random period of time of between TBD and TBD seconds. Note, 339 however, that an RFC 1577 client will not necessarily delay the start 340 of its registration procedure. Therefore, an RFC 1577 client may 341 initially experience setup failures if the network is in a mode where 342 all ATMARP servers (and in particular its own server) are 343 simultaneously initializing. 345 Once this period of random delay has elapsed, a client must determine 346 its designated server. For autoconfiguring clients, this procedure is 347 outlined in [MAR95]. For non-autoconfiguring clients supporting this 348 scheme, this is accomplished by randomly choosing an address from its 349 list of administratively configured server ATM addresses. 351 Each client supporting this procedure, whether capable of 352 autoconfiguration operation or not, must provide a means of being 353 administratively configured with the ATM addresses of all the 354 cooperating servers in the LIS. No ordering or priority is 355 necessarily to be imposed on the configured server addresses. The 356 default behavior of a non-autoconfiguring client is to choose a 357 server address at random as its designated server. However, all 358 implementations must support the capability to override this default 359 behavior so that an ordering or priority among the configured 360 addresses can be obtained. Each client must support the capability 361 to be administratively configured with the maximum number of servers 362 supported for a LIS. This number is TBD. RFC 1577 clients may be 363 configured with any of the individual ATM addresses of any server on 364 the LIS as its atm$arp-req address. 366 4.3 ATMARP Client Registration Procedures 368 Client registration procedures may be initiated as part of a client's 369 initial startup sequence or due to the necessity of the client to 370 refresh its address resolution information (see section 4.5). Once a 371 client determines its designated server, it must establish a 372 connection to that server and register its address resolution 373 information. For autoconfiguring clients this is accomplished by 374 utilizing a LIS-specific anycast address and following the procedures 375 outlined in [MAR95] and [LAUB95]. A non-autoconfiguring client 376 supporting this scheme must follow the procedures outlined in 377 [LAUB95]. RFC 1577 clients follow the procedures outlined in 378 [LAUB94]. Note that clients based on [LAUB95] will use an 379 ATMARP_Request with both the source and target addresses set to its 380 own address resolution information to register itself, while RFC 1577 381 client registration will now occur implicitly. 383 If a non-RFC 1577 client's initial attempt to connect to its 384 designated server fails, it is suggested that the client use a simple 385 exponential backoff algorithm before retrying the setup. This may be 386 necessary to avoid a "setup" storm that might occur during periodic 387 client refresh operations or perhaps during a server failure. In no 388 case, however, should a client allow the cumulative time spent trying 389 to establish a connection to its designated server to exceed TBD 390 seconds. This is required to support an upper bound on the amount of 391 time that occurs before a client initiates recovery operations (see 392 Section 6). 394 It is necessary for a client to wait until its registration 395 information has been reliably propagated to all the cooperating 396 servers in the LIS (that are currently operable) before it receives a 397 reply. Non-RFC 1577 clients must allow, at a minimum, TBD seconds for 398 this to be accomplished. If this period of time elapses before a 399 reply is received, the client should retry the registration. If the 400 registration is still not successful after TBD attempts, the client 401 initiates recovery operations. 403 4.4 ATMARP Server Registration Procedures 405 4.4.1 Considerations 407 The main goal of the server registration procedures is to reliably 408 distribute a client's address resolution information to all the 409 cooperating servers in the LIS so that such information may be 410 cached. Among the issues that must be considered in accomplishing 411 this goal is how (if at all) the client's address resolution 412 information is related to other information already cached throughout 413 the LIS. It is imperative that, as a result of the server 414 registration procedure, inconsistencies not be introduced into the 415 servers' caches. In particular, three cases stand out as areas of 416 concern: 418 1. A client is attempting to register an IP address that is 419 already cached in the LIS, but with a different ATM 420 address and an open connection is associated with the 421 cache entry 423 2. A client is attempting to register an IP address that is 424 already cached in the LIS, but with a different ATM address 425 and no open connection is associated with the cache entry 427 3. A client is attempting to register an IP address not 428 currently cached in the LIS, however, the client's ATM 429 address is associated with another IP address that is 430 already cached 432 The first case will normally occur as the result of a pair of mis- 433 configured hosts. In a single server environment, this situation is 434 easily detected by performing a "duplicate IP address" test. The 435 results of this test could be used to deny registration to the 436 requesting client, if the client's IP address proved to be a 437 duplicate. However, performing this test, and denying service if it 438 fails, is no easy task in a distributed environment. This would seem 439 to require a two phase "lock and commit" database type of operation 440 to be performed across all the servers in the LIS. Since we obviously 441 don't know ahead of time if a particular client registration is a 442 duplicate or not, we would need to check every client registration. 443 Since a client is required to re-register periodically, the more 444 clients we add to the LIS, the more often we would be performing this 445 check. This would lead to a great deal of overhead. Another 446 consideration here is, although it is bound to happen, the occurrence 447 of this event is expected to be very low. 449 The second case would be most likely to occur as a result of a 450 client's physical connection being moved to another UNI, probably 451 located on a switch other than it was connected to when it last 452 registered. The action of moving the physical cable would have 453 released the connection to the ATMARP server and caused the mapping 454 between the IP address/ATM address to change. This action would have 455 also necessitated that the client reconnect and re-register with the 456 ARP server. It is claimed that this case is most likely to explain 457 the second case because a connection is not currently associated with 458 the cache entry. However, this case could be equivalent to the first 459 case if the previously registered client did not maintain a 460 connection to the ATMARP server. Nevertheless, it is felt that more 461 times than not, a "change" operation has occurred in this case. 462 Therefore, rather than deny registration we would want this new 463 mapping to take effect throughout the LIS as rapidly as possible. 465 The third case is not very likely to happen given the wide acceptance 466 and implementation of the ILMI address registration procedure 467 [ATM95]. Most ATM address configuration is removed from human hands 468 and so we are unlikely to end up with this case. 470 Given the above considerations, it seems that the server registration 471 procedure should be optimized for the second case. While the first 472 case is cause for concern, it is not expected to occur as often as 473 the second. We propose to adopt a policy of "last registration always 474 overrides an earlier registration" as opposed to that supported by 475 the policy of the "detection and denial" model which is "first 476 registration always wins." In the absence of any specific security 477 mechanisms, the "last registration overrides" policy is just as valid 478 as denying a registration. Furthermore, this policy is much simpler 479 to implement in a distributed scheme and simplifies the processing 480 when a duplicate entry is discovered at a server other than the one 481 where a registration originated. If the first case were to occur and 482 persist, then it is likely that this scheme will thrash about waiting 483 for something or someone to correct the problem. However, this 484 behavior is not so much different than what has been observed with 485 other address resolution protocols. 487 4.4.2 Procedures 489 Server registration procedures are initiated upon receiving an 490 ATMARP_Request packet from a client with the source and target IP 491 addresses equal ("explicit" case) or an ATMARP_Request packet is 492 received from a client and the server does not have a corresponding 493 cache entry (implicit case). 495 After updating (or creating) its local cache entry according to the 496 policy described above, the server must forward the client's address 497 resolution reliably to each of the other servers in the LIS. This is 498 accomplished by forwarding a Server ATMARP_Request, containing the 499 client's mapping information, over the sever's outgoing point-to- 500 multipoint VC and awaiting for a Server ARP_Reply reply from each 501 server. Note that if a timeout occurs while waiting for a reply, 502 resending the request will cause all servers to receive the request 503 again (unless perhaps one or more of the servers missed the previous 504 one). 506 When a server receives a Server ATMARP_Request, it creates or updates 507 its local cache entry according to the policy described above. After 508 the entry is updated, the server forwards an ATMARP_Reply to the 509 server from which it was received. 511 After the initiating server receives ATMARP_Replys from all the 512 servers, it sends an ATMARP_Reply to the client (explicitly or 513 implicitly) initiating the registration. 515 4.5 Client Refresh Procedures 517 TBD 519 5. Address Resolution Procedures 521 5.1 Client Address Resolution Procedures 523 ATMARP clients attempt to resolve IP addresses to ATM addresses by 524 examining their local address resolution cache. If a client's address 525 resolution cache does not contain an entry matching the sought after 526 IP address, it must send an ATMARP_Request to its designated server 527 in order to obtain the desired mapping information as outlined in the 528 applicable procedures [LAUB94, LAUB95] and as augmented by this memo. 529 The scheme presented here is completely backward compatible with RFC 530 1577 clients. There are only minor differences for non-RFC 1577 531 clients. 533 After sending an ATMARP_Request to its designated server, the client 534 awaits for a corresponding ATMARP_Reply. An ATMARP_Reply returned to 535 an RFC 1577 client is handled as outlined in [LAUB94]. However, an 536 ATMARP_Reply returned to a non-RFC 1577 client may require slightly 537 different handling. This is due to the possibility that the mapping 538 information returned in the reply may have been obtained second hand. 539 In other words, the client's designated server may have not been able 540 to resolve the request from its own cache and therefore would have 541 had to obtain the sought after information from another server. 542 Depending on the strategy employed, the information returned to the 543 requesting server (i.e., the requesting client's designated server) 544 may have been non-authoritative. If this is were the case, then a 545 more restrictive limit must be used on the lifetime of the mapping 546 information to be cached by the client. This is necessary to avoid 547 having stale cache information persist in the client's cache thus 548 reducing that the possibility that the client will experience any 549 period of non-connectivity due to such stale cache information. 550 ([LAUB95] requires a client to purge a cache entry when a failure to 551 connect to another client occurs. Following this, the client sends an 552 ATMARP_Request to try to obtain fresh cache information. The caching 553 scheme employed in this memo attempts to limit this type of 554 activity.) 556 For non-RFC 1577 clients, the NON-AUTHORITATIVE bit (see section X) 557 is set when second hand cache information is returned to the client. 558 This is an indication to the client that it needs to use the 559 restricted cache timeout value when completing the cache entry. This 560 value is defined as TBD seconds. If the NON-AUTHORITATIVE bit is 561 clear in a reply received by a non-RFC 1577 client, then normal 562 packet handling procedures apply. For backward compatibility with RFC 563 1577 clients, the NON-AUTHORITATIVE bit is never set so such clients 564 are more susceptible to the issues discussed above. [Most RFC 1577 565 implementations were modified to accommodate the "non-connectivity 566 because of stale cache information" problem so most of these 567 implementations should eventually recover from this condition.] 569 Because of the differences between the distributed ATMARP scheme 570 presented in this memo and the approach outlined in [LAUB95], the 571 handling of an ARP_Nak is slightly different and actually results in 572 significantly simpler client behavior. In [LAUB95] the receipt of an 573 ARP_Nak requires the client to query another ATMARP server in an 574 attempt to resolve its request. In fact, in the worst case, the 575 client would need to query all the address resolution servers in the 576 LIS. This approach complicates the client behavior and significantly 577 increases the delay required to resolve a request (in the worst 578 case). The approach taken in this memo essentially retains the 579 original ARP_Nak semantics as defined in RFC 1577 [LAUB94]. Because 580 the scheme presented here ensures that all servers in the LIS are 581 queried (simultaneously) if a designated server does not contain a 582 cache entry matching the target IP address in a request, it can 583 provide the answer in a definitive manner as to whether the 584 information exists anywhere in the LIS. This approach, therefore, 585 maintains characteristics similar to a single ATMARP server for this 586 case as well as the normal case. 588 Non-RFC 1577 clients must allow at least TBD seconds for the ATMARP 589 server to return a reply to its request. If a timeout occurs, the 590 client should retry the request a small number of times. If a reply 591 is still not obtained, the client may initiate recovery procedures 592 (see Section 6). RFC 1577 behavior remains the same for this case. 594 5.2 Server Address Resolution Procedures 596 Server address resolution operations are initiated upon the receipt 597 of an ATMARP_Request from a client or from another server. In the 598 case of an ATMARP_Request received from a client, a (designated) 599 server attempts to resolve the request from entries contained in its 600 local address resolution cache. If an entry is found, the sought 601 after information is extracted and returned to the client in an 602 ATMARP_Reply. Before returning a reply, however, the server must 603 perform a series of checks to determine if it should set the NON- 604 AUTHORITATIVE bit in the ATMARP_Reply 606 If the client request can be satisfied with cache information from 607 (another) directly-registered client, then no further considerations 608 are necessary and the ATMARP_Reply is returned to requesting client 609 with the NON-AUTHORITATIVE bit clear. However, if the server is 610 holding a cache entry that can satisfy the request, but the entry 611 does not correspond to a directly-registered client, then the server 612 must determine how this cache information was obtained. If the cache 613 entry was created from an authoritative reply, or from a relayed 614 client registration, then the ATMARP_Reply is returned with the NON- 615 AUTHORITATIVE bit clear. If, however, the cache entry was created 616 from a non-authoritative reply, then the type of requesting client 617 must be determined, if known. This information is normally recorded 618 at the time the client registered. If requesting client registered 619 implicitly, then for backward compatibility reasons the NON- 620 AUTHORITATIVE bit cannot be set. However, if the client is known to 621 be a non-RFC 1577 client then the NON-AUTHORITATIVE bit must be set 622 so that the appropriate client handling procedures can be performed. 624 If the server is not holding a cache entry matching the requested IP 625 address, then it must query all the other servers in the LIS for the 626 answer. The sequence used to perform this query is somewhat dependent 627 on the strategy employed by the server. Two interoperable strategies 628 were outlined in section 2. For the sake of brevity only the first 629 strategy will be detailed here. 631 A server sends a Server ATMARP_Request (see section 7) over its 632 outgoing point-to-multipoint VC to forward the request to all other 633 servers in the LIS. The Server ATMARP_Request carries the server's 634 address information in the source address fields, and the IP address 635 to be resolved in the target protocol address field. To indicate a 636 request for authoritative cache information (in keeping with the 637 goals of the first strategy), both the REGISTRATION and the NON- 638 AUTHORITATIVE bits are clear. 640 A server receiving a Server ATMARP_Request for authoritative cache 641 information examines its cache to determine if it has a matching 642 entry. If a cache entry was found, and if the entry corresponds to a 643 directly-registered client, the server forms a Server ATMARP_Reply 644 using the information found in the entry and returns the reply to the 645 requesting server. Otherwise, the server discards the request. 646 [Would it be better to have servers send NAKs if they do not find 647 authoritative information?] When the requesting server receives the 648 Server ARP_Reply, it completes its cache entry and forwards the reply 649 on to the requesting client. 651 6. Server Failure Detection and Recovery 653 Depending on how an ATMARP server failure occurs, the client may or 654 may not immediately detect its failure. If a client maintains a 655 connection to the ARP server then it probably has a better chance of 656 detecting a problem sooner (again, depending on the failure). In any 657 event, the client will probably initiate recovery operations when it 658 repeatedly fails to connect to its designated server or when the 659 client fails to receive an expected reply from the server after 660 several retry attempts. 662 Note, if the client still has a connection established to the server 663 (e.g., the timeout case), then it must release it. When its 664 connection to the ATMARP server is released, the client must attempt 665 to reconnect and re-register its ATMARP information. If the client is 666 non- autoconfiguring then a new server address should be selected at 667 random (ensuring that a different address is indeed selected). For 668 autoconfiguring clients, anycast will "search" for the new server 669 (presumably, the failed server's anycast address will eventually be 670 de-registered by an ILMI connectivity timeout if' nothing else). 671 During the period of time that it is setting up a call, the client 672 may continue to use its cache to resolve addresses. When the client 673 succeeds in establishing a new connection to its (new) server, and 674 registers its address resolution information, it may then resolve any 675 pending requests. 677 Notice that when a client re-registers (as above) the (new) server 678 will record the client as being "directly-registered." Once a failed 679 server is returned to service, it is necessary that the clients that 680 have failed over to the (new) server, return to the original server. 681 This happens automatically in this scheme when the clients refresh 682 their address resolution information with the server. As part of a 683 modified refresh operation, the clients must release their current 684 connection and setup a new call. For autoconfiguring clients this is 685 done using the appropriate anycast address; non-autoconfiguring 686 clients choose a new server address at random from those it has 687 configured. 689 7. Packet Formats 691 TBD 693 8. VC Resource Requirements 695 One consideration for this scheme is its use of VC resources. The 696 requirements in terms of VCs for the server-server case is N (N - 1) 697 incoming VCs [the leafs associated with the (N - 1) incoming PMP 698 connections per server, where N = the number of servers in a LIS] and 699 N outgoing VCs for the root of each PMP call to each of the (N - 1) 700 other servers. So the total VC requirements for server-server 701 interaction are N**2 VCs per LIS. Each server would as well need to 702 support an additional M/N (with M = the number of clients in the LIS) 703 bidirectional VCs for client-server interaction (assuming clients are 704 distributed uniformly across multiple servers). So the total VC 705 requirements for each server would then be N + M/N VCs and N**2 + N 706 (M/N) = N**2 + M VCs for all servers in a LIS. 708 9. Acknowledgments 710 The authors would like to thank Mike Kazar (FORE Systems) for useful 711 feedback concerning some of the cache issues discussed in this memo. 713 10. References 715 [LAUB94] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, 716 Hewlett-Packard Laboratories, January 1994. 718 [LAUB95] Laubach, M., "Classical IP and ARP over ATM Update", 719 draft-ietf-ipatm-classic2-00.txt, Internet Draft (work 720 in progress), August 1995. 722 [ATMF95] ATM Forum, "ATM User-Network Interface (UNI) Signalling 723 Specification Version 4.0", ATM Forum, December 1995. 725 [MAR95] Marcinik, C., Liaw, F., "ATMARP Client Autoconfiguration", 726 draft-marcinik-ipatm-auto-arp-00.txt, Internet Draft (work 727 in progress), November 1995. 729 [PEREZ95] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. 730 and A. Malis, "ATM Signaling Support for IP over ATM", 731 RFC 1755, ISI, Fore, Motorola Codex, Ascom Timeplex, 732 February 1995. 734 11. Security Considerations 736 Security issues are not addressed in this memo. 738 12. Authors' Addresses 740 Carl Marcinik 741 FORE Systems, Inc. 742 Pittsburgh Office and Research Park 743 Pittsburgh, PA 15237-5829 745 Phone: (412) 625-9051 746 Email: carlm@fore.com 748 Maryann Perez Maher 749 USC/Information Sciences Institute 750 4350 N. Fairfax Drive Suite 400 751 Arlington, VA 22203 753 Phone: 703-807-0132 754 EMail: perez@isi.edu