Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_a_c/draft-ietf-asid-replica-selection-00.txt

Text File | 1997-02-25 | 20KB | 524 lines

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 <[e-mail]>.  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 "[e-mail]"
  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 werenÆt.

  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 "[e-mail]"
  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: [e-mail]



































  Leach                                         [Page 9]