ASID Working Group Paul J. Leach, Microsoft INTERNET-DRAFT <draft-ietf-asid-replica-selection-00.txt> Expires August 23, 1997 February 23,1997 Selecting a server from among many replicas Paul J. Leach, Microsoft Preliminary Draft 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. This draft is not a work item of the ASID working group, and does not represent WG consensus. 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". WARNING: The specification in this document is subject to change, and will certainly change. It is inappropriate AND STUPID to implement to the proposed specification in this document. In particular, anyone who implements to this specification and then complains when it changes will be properly viewed as an idiot, and any such complaints shall be ignored. YOU HAVE BEEN WARNED. 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). Distribution of this document is unlimited. Please send comments to the ASID working group at <ietf-asid@umich.edu>. Discussions of the working group are archived at <URL: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive>. Leach [Page 1]
Internet-Draft Locating LDAP Servers 02/23/97 ABSTRACT Many organizations today have Web servers for their organization, which supply information published by their organization to the Internet and to internal users via the HTTP protocol [6]. It is anticipated that many organizations will in the not-to-distant future have directory servers, which supply information about their organization to the Internet and to internal users via the LDAP protocol [7]. These servers all have DNS [1, 2] names, and they often are (or, in the future, will be likely to be) replicated for reliability or greater capacity. This leads to the problem of selecting among the replicas. We briefly survey current practice, for both centralized and geographically distributed replicas. Then we discuss emerging practice, represented by SRV and LOC RRs [3, 4]. We propose a way to use both of these together to select among geographically distributed replicas which, while not perfect, automates current practice. We propose a convention to handle the case of an organization that has a large number of sites, each of which needs a small number of replicas for availability in case of loss of external connectivity. Table of Contents 1. Introduction........................................................2 2. Current Practice....................................................4 3. Emerging Practice: SRV and LOC RRs..................................4 3.1 Discussion.......................................................4 4. Locating a replica..................................................5 5. Locating a local replica............................................7 6. Security Considerations.............................................8 7. References..........................................................8 8. Author's address....................................................9 1. Introduction We assume that large organizations will implement various network based services (such as directory services and Web services) by deploying replicated servers for reliability and load sharing, and Leach [Page 2]
Internet-Draft Locating LDAP Servers 02/23/97 that geographically distributed organizations will geographically distribute some of the replicas. This leads to the problem of selecting among the replicas. In the Internet context, the named entities which exist today about which users seek information almost all either have, or contain, DNS names [1,2], since it is by far the most widely used naming service in the Internet. There has a huge social investment spanning two decades to get to the point where names like "john.doe@somecorp.com" and "http://www.sony.com" can appear in newspaper articles, TV commercials, and on billboards, and millions of people understand what do with them. Thus, we can refine the problem statement above to "starting with a DNS name for an organization, and the name of a desired service, intelligently select a server hosting an instance of that service from among the replicas". By an "intelligent" choice, we mean one that is expected to be better than one chosen purely at random, but not necessarily an optimum choice. Current practice, discussed below in more detail, can only attempt to split the load evenly across replicas, which is not good if the replicas are of different capacity. It also doesn't provide for anything other than manual selection among geographically distributed replicas. Improvements to current practice have been proposed: recently, LOC and SRV resource records have been added to the DNS repertoire (see RFC 1876 [3] and RFC 2052 [4], respectively). The use of SRV records allows for load to be distributed among replicas in proportion to statically assigned weights (typically chosen to reflect relative server capacity). However, replica selection per RFC 2052 using SRV records does not take communication cost (throughput, latency) into consideration, which is important if the replicas are geographically distributed. The use of LOC records would allow a client to choose among the replicas based on geographic proximity. As with SRV records, however, replica selection using LOC records does not take communication cost into consideration. Neither of these are widely used as of yet, but their use is likely to become more widespread. No one (to our knowledge) has proposed a way to use both in conjunction for replica selection when replicas are geographically distributed. We describe how to select an "reasonable" instance from among geographically distributed replicated instances of such servers, using DNS SRV and LOC RRs in conjunction. We propose two styles - one for use from "outside" an organization, and one for use from "inside" when there are a very large number of replicas. Leach [Page 3]
Internet-Draft Locating LDAP Servers 02/23/97 2. Current Practice We will consider two approaches in current use that are fairly typical. The first approach works reasonably when all the replicas are at a single site and of roughly the same capacity. The idea is to register multiple A records under the name of the server; when clients resolve the name they pick one at random. Usually, the DNS server also randomizes the order of the A records before returning them, in order to deal with clients that blindly take the first one. Often the name of the server is created by stropping the name of the organization with an indication of the type of server desired; for example, the Web server for "microsoft.com" is "www.microsoft.com" (see [5] for an attempt to make this more formal). The second approach is used when multiple geographically distributed sites are desired so that clients can obtain service from a "nearby" replica that hopefully has higher bandwidth to the client than other replicas. It is used primarily with Web sites. When heavy load is expected, say for downloading new versions of popular software, users are presented with a list of sites from which to it may be downloaded, and asked (perhaps implicitly) to pick the closest one. One implementation presents a map on which the user clicks to indicate their geographical location, and the server uses that to select a replica. 3. Emerging Practice: SRV and LOC RRs SRV records were introduced to overcome limitations in the first approach. The SRV record allows an administrator to prioritize server hosts and divide the load among them according to a weight. SRV records work well for selecting among replicas all of which are at a single site, and as long as dynamic load information is not required to properly balance the load. We are most concerned with the case where the replicas are at different sites; in this case, the communications costs can be more important than the server capacity, so selection based only on capacity often won't yield the best performance. We are also concerned with the case where there are large numbers of servers, which would lead to too many SRV RRs to to return in a UDP DNS response. LOC records, if present for a host, would allow a client to choose among logically equivalent server hosts based on geographic proximity. 3.1 Discussion It is well known that geographic proximity is not necessarily the Leach [Page 4]
Internet-Draft Locating LDAP Servers 02/23/97 same as proximity as measured by network communication costs. A nearby server may have worse connectivity (in bandwidth or latency or other dimensions) than one significantly farther away. Hence, proposing to select a server based on geographical proximity is controversial. However, we argue that it will produce better server selections than when it is not used because of the following: · A server found by geographic proximity will in practice usually be better than one chosen at random without regard to proximity. In any case, servers chose this way will be just as good or better as the ones chosen manually, because almost none of the users making such choices know the network topology well enough to do any better. To summarize -- as long we limit our objectives to selecting servers in the same (sub)continent or at the same campus, LOC based selection will always work at least as well as current practice, and often much better, even if not perfectly. However, selecting the nearest server doesn't handle well the case where a site has several servers to increase capacity - it would be desirable to spread the load over "roughly equally nearby" servers, instead of always picking the nearest. 4. Locating a replica For a service that follows this specification, a client that is given a DNS name for a domain can obtain an IP address for one of the replicas of the service for that domain using DNS as follows. It MAY choose among the hosts as described in RFC 2052 [4], or it is RECOMMENDED that they use the following modification of that procedure to locate a list of servers and connect to the preferred one: Let "target" be the name of the domain. Let "service" be the symbolic name of the service, as defined in Assigned Numbers or locally. Let "protocol" be the transport protocol used by the service; usually "tcp" or "udp", but may be any defined in Assigned Numbers of locally. (See [4] for more information.) 1. Do a lookup for QNAME=service.protocol.target, QCLASS=IN, QTYPE=SRV. 2. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR which specifies the requested Service and Protocol in the reply: If there is precisely one SRV RR, and its Target is "." (the root Leach [Page 5]
Internet-Draft Locating LDAP Servers 02/23/97 domain), abort. For all SRV RR's, build a list of (Priority, Weight, Target) tuples Sort the list by priority (lowest number first) Create a new empty list For each distinct priority level For each element at this priority level query the DNS for LOC RR for the Target (if not found in the Additional Data section of the earlier SRV query). Find the nearest target Find all targets "close" to the nearest target (target to target distance less than 2-3% of client to nearest target distance) Remove all other targets at this priority level While there are still elements left at this priority level Select an element randomly, with probability Weight, and move it to the tail of the new list For each element in the new list query the DNS for A RR's for the Target or use any RR's found in the Additional Data section of the earlier SRV query. for each A RR found, if the protocol is TCP (connection-oriented) try to connect to the (protocol, address, service); if the protocol is UDP, send a service request Stop if connection is successful (TCP) or a response is received (UDP) 3. Else if the service desired is SMTP skip to RFC 974 (MX). 4. Else Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A Leach [Page 6]
Internet-Draft Locating LDAP Servers 02/23/97 for each A RR found, try to connect to the (protocol, address, service) For IPv6, one would follow the same procedure, except using AAAA records instead of A records. As an example, if a client wanted to find the FTP server for Universal Exports (the fictitious holding company that employed James Bond), whose domain name was "univexports.com", then in the procedure above, "service" would be "ftp", "protocol" would be "tcp", and "target" would be "univexports.com", and the name to lookup in step 1 above would be Error! Bookmark not defined.. 5. Large numbers of replicas Imagine an organization (such as a bank) which has thousands of branch offices. For reliability, each office may want to have a replica of (at least) certain critical information in case of loss of connectivity to the Internet. An example of such information might be an address book for employees or an authentication database. It is not reasonable to use the method of the previous section to locate a replica for the information - there would be thousands of SRV entries for the service being replicated. Instead, it would be desirable to have a method that first looked to see if there is a replica for the service at the branch office, and only used the previous method if there werent. Let us generalize the notion of branch office to that of "site" - a site is a collection of hosts that have good enough connectivity that use of a service instance at the site is always to be preferred to one at another, and that there is no connectivity reason to prefer one replica within a site to another. A site has a site name which incorporates a site specific component and the domain name of the organization of the form <site>@<org-domain-name> For example, the Dublin office of Universal Exports might have the site name Error! Bookmark not defined.. Assume that each client has been configured to know its site name. (The configuration could be manual or automatic; the exact mechanism is beyond the scope of this document, although DHCP seems an obvious candidate for automatic configuration). Then a client at site <site>@<org-domain-name> looking for a service for domain <domain-name>, where <org-domain- name> is a suffix of <domain-name>, should use the name <site>.sites.<domain-name> as the value of "target" in the procedure described in RFC 2052. If the procedure fails, then it should try with <domain-name> Leach [Page 7]
Internet-Draft Locating LDAP Servers 02/23/97 as the value of "target" using the procedure in section 4 above. Note that within a site, this means the client just uses straight SRV records; by definition of "site", there would be no advantage to be gained from using LOC records. For example, suppose a client at the site "dublin@univexports.com" wanted to access the LDAP server for the Asian region of Universal Exports, whose domain name was "fareast.univexports.com". It would observe that its <org-domain-name> of "univexports.com" was a suffix of "fareast.univexports.com", and first construct the name "dublin.sites.fareast.univexports.com" to use as the "target" in the procedure above; this would cause it to then lookup "ldap.tcp.dublin.fareast.univexports.com" searching for SRV RRs. Note that the list of SRV records for a site does not have to point at only hosts at that site - for example, the highest priority records could be for hosts at the site, and then some lower priority records for hosts at the best-connected alternate site for backup. Using this method, a client looking for a service that has an replica at its site will only have to fetch SRV records for its site, not for the whole organization. The SRV records associated with the unadorned organization name can be reserved to clients from outside the organization, who have no idea of the site structure of the organization. 6. Security Considerations The security considerations for the use of this procedure are the same as for the use of SRV or LOC RRs in general; see RFC 1876 [3] and RFC 2052 [4]. 7. References [1] P. Mockapetris, RFC 1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES", November, 1987. [2] P. Mockapetris, RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", November, 1987. [3] C. Davis, P. Vixie, T. Goodwin, I. Dickinson, RFC 1876,"A Means for Expressing Location Information in the Domain Name System", 01/15/1996. [4] A. Gulbrandsen, P. Vixie, RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)", 10/31/1996. [5] M. Hamilton, R. Wright, "Use of DNS Aliases for Network Services", Internet Draft <draft-ietf-ids-dnsnames-01.txt>, August Leach [Page 8]
Internet-Draft Locating LDAP Servers 02/23/97 1996. (Work in Progress) [6] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, RFC 2068, "Hypertext Transfer Protocol -- HTTP/1.1", 01/03/19 [7] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol(v3)". Internet-Draft <draft-ietf-asid-ldapv3- protocol.txt>, ASID Working Group, June 5, 1996. 8. Author's address Paul J. Leach Microsoft 1 Microsoft Way Redmond, Washington, 98052, U.S.A. Email: paulle@microsoft.com Leach [Page 9]
