home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-svrloc-discovery-01.txt < prev    next >
Text File  |  1997-05-08  |  11KB  |  362 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet-Draft                                                Ryan Moats
  8. draft-ietf-svrloc-discovery-01.txt                                  AT&T
  9. Expires in six months                                    Martin Hamilton
  10.                                                  Loughborough University
  11.                                                            Paul J. Leach
  12.                                                                Microsoft
  13.                                                                 May 1997
  14.  
  15.  
  16.                              Finding Stuff
  17.                        (How to discover services)
  18.               Filename: draft-ietf-svrloc-discovery-01.txt
  19.  
  20.  
  21. Status of This Memo
  22.  
  23.       This document is an Internet-Draft.  Internet-Drafts are working
  24.       documents of the Internet Engineering Task Force (IETF), its
  25.       areas, and its working groups.  Note that other groups may also
  26.       distribute working documents as Internet-Drafts.
  27.  
  28.       Internet-Drafts are draft documents valid for a maximum of six
  29.       months and may be updated, replaced, or obsoleted by other
  30.       documents at any time.  It is inappropriate to use Internet-
  31.       Drafts as reference material or to cite them other than as ``work
  32.       in progress.''
  33.  
  34.       To learn the current status of any Internet-Draft, please check
  35.       the ``1id-abstracts.txt'' listing contained in the Internet-
  36.       Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  37.       (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  38.       Coast), or ftp.isi.edu (US West Coast).
  39.  
  40.  
  41. Abstract
  42.  
  43.    This document proposes a solution to the problem of finding
  44.    information about that services are being offered at a particular
  45.    Internet domain.  Therefore, it is possible for clients, using this
  46.    approach, to locate services in a domain with only prior knowledge of
  47.    the domain name.
  48.  
  49.  
  50. 1. Rationale
  51.  
  52.    Currently, there is no one single way of discovering the network
  53.    services and application protocols supported at a particular Internet
  54.    domain.  The Domain Name System (DNS) provides some basic facilities
  55.  
  56.  
  57.  
  58. Expires 11/30/97                                                [Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. INTERNET DRAFT               Finding Stuff                    April 1997
  65.  
  66.  
  67.    for finding the hosts that offer particular services, such as DNS
  68.    servers themselves (NS records), mail exchangers (MX records [3]).
  69.    Recently general service records (SRV records [1]) have been proposed
  70.    for DNS, along with storing geographic information (LOC records [6]).
  71.    In addition, there are evolving methods for doing service location
  72.    via other methods [4] & [5].
  73.  
  74.    This document sets forth a process to rationalize how a client could
  75.    use these various methods for service location.
  76.  
  77.  
  78. 2. The process
  79.  
  80.    For a client in domain "srcdom" that wants to locate service
  81.    "service" in domain "tgtdom", the following process should be
  82.    followed:
  83.  
  84.       1. If "srcdom" == "tgtdom", use the Service Location Protocol [4]
  85.       to determine if the service can be found that way.
  86.  
  87.       2. Look for SRV records [1] for a directory agent (i.e.
  88.       da.udp."tgtdom" or da.tcp."tgtdom").  This consists of:
  89.  
  90.       2a. Do a lookup of QNAME=da.tcp.tgtdom, QCLASS=IN, QTYPE=SRV.
  91.  
  92.       2b. If the reply is NOERROR, ANCOUNT>0 and there is at least one
  93.       SRV RR which specifies the requested Service and Protocol in the
  94.       reply:
  95.  
  96.         If there is precisely one SRV RR, and its Target is "." (the
  97.         root domain), go to step 2c.
  98.  
  99.         For all SRV RR's build a list of (Priority, Weight, Target)
  100.         tuples and sort the list by priority (lowest number first).
  101.  
  102.         Create a new empty list.
  103.  
  104.         For each distinct priority level
  105.  
  106.           For each element at this priority level
  107.             While there are still elements left at this priority level,
  108.             select an element randomly, with probability weight, and
  109.             move it to the tail of the new list.
  110.  
  111.           For each element in the new list
  112.             Query the DNS for A RR's for the target or use any RR's
  113.             found in the additional data section of the earlier SRV
  114.             query
  115.  
  116.  
  117.  
  118. Expires 11/30/97                                                [Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. INTERNET DRAFT               Finding Stuff                    April 1997
  125.  
  126.  
  127.             For each A RR found, try to connect to the directory agent
  128.             using the Service Location Protocol over TCP.
  129.  
  130.       2c. Else do a lookup of QNAME=da.udp.tgtdom, QCLASS=IN, QTYPE=SRV.
  131.  
  132.       2d. Process the reply as in 2b, except that if there is precisely
  133.       one SRV RR with a target of ".", go to step 3 and connections to
  134.       the directory agent use Service Location Protocol over UDP.
  135.  
  136.       3. Look for SRV records for service.protocol.tgtdom, where
  137.       protocol is whichever protocol (TCP or UDP) is associated with
  138.       service.  This consists of:
  139.  
  140.       3a. Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
  141.       QTYPE=SRV.
  142.  
  143.       3b. If the reply is NOERROR, ANCOUNT>0 and there is at least one
  144.       SRV RR which specifies the requested Service and Protocol in the
  145.       reply:
  146.  
  147.         If there is precisely one SRV RR, and its Target is "." (the
  148.         root domain), go to step 4.
  149.  
  150.         For all SRV RR's, build a list of (Priority, Weight, Target)
  151.         tuples and sort the list by priority (lowest number first).
  152.  
  153.         Create a new empty list.
  154.  
  155.         For each distinct priority level
  156.  
  157.           For each element at this priority level
  158.             Query the DNS for LOC RR [6] for the Target (if not found in
  159.             the Additional Data section of the earlier SRV query).
  160.  
  161.             Find the nearest target and all targets "close" to the
  162.             nearest target (target to target distance less than 2-3% of
  163.             client to nearest target distance)
  164.  
  165.             Remove all other targets at this priority level
  166.  
  167.             While there are still elements left at this priority level,
  168.             select an element randomly, with probability weight, and
  169.             move it to the tail of the new list
  170.  
  171.           For each element in the new list
  172.             Query the DNS for A RR's for the Target or use any RR's
  173.             found in the Additional Data section of the earlier SRV
  174.             query.
  175.  
  176.  
  177.  
  178. Expires 11/30/97                                                [Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. INTERNET DRAFT               Finding Stuff                    April 1997
  185.  
  186.  
  187.             For each A RR found, if the protocol is TCP (connection-
  188.             oriented) try to connect to the (protocol, address,
  189.             service); if the protocol is UDP, send a service request
  190.  
  191.       4. If the service desired is SMTP, skip to RFC 974 (MX records)
  192.       else go to step 5.
  193.  
  194.       5. If the service has a "well known" alias (see [2]) service',
  195.       look for A RRs for service'.target.  This is done in the following
  196.       way:
  197.  
  198.       5a. Do a lookup for QNAME=service'.target, QCLASS=IN, QTYPE=A.
  199.  
  200.         If no A RR's returned, go to step 6.
  201.  
  202.         For each A RR found, try to connect to the (protocol, address,
  203.         service).  If successful, stop.
  204.  
  205.         If all A RR's have been tried go to step 6.
  206.  
  207.       6. Look for "service:" URLs stored in TXT RRs for service.target:
  208.  
  209.       6a. Do a lookup for QNAME=service.target, QCLASS=IN, QTYPE=TXT.
  210.  
  211.         If no TXT RR's returned, go to step 7.
  212.  
  213.         For each TXT RR found, try to connect to the (address, port)
  214.         specified in the service: URL. If successful, stop.
  215.  
  216.         If all TXT RR's have been tried go to step 7.
  217.  
  218.       7. Look for "service:" URLs stored in TXT RRs for target:
  219.  
  220.       7a. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=TXT.
  221.  
  222.         If no TXT RR's returned, go to step 8.
  223.  
  224.         For each TXT RR found, try to connect to the (address, port)
  225.         specified in the service: URL. If successful, stop.
  226.  
  227.         If all TXT RR's have been tried go to step 8.
  228.  
  229.       8. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
  230.  
  231.         For each A RR found, try to connect to the (protocol, address,
  232.         service).  If successful, stop.
  233.  
  234.  
  235.  
  236.  
  237.  
  238. Expires 11/30/97                                                [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. INTERNET DRAFT               Finding Stuff                    April 1997
  245.  
  246.  
  247. 3. Security Considerations
  248.  
  249.    Because of the suggested mechanisms for service discovery, this
  250.    document inherits all the security considerations of using DNS RR's
  251.    and the Service Location Protocol.  Implementors should consider both
  252.    [7] and the security section of [4] for appropriate methods.
  253.  
  254.  
  255. 4. Conclusion
  256.  
  257.    By following the above process, a client may be reasonably certain of
  258.    determining whether a particular service is provided for a particular
  259.    domain name, given the domain name.
  260.  
  261.  
  262. 5. Acknowledgments
  263.  
  264.    This document is partially supported by the National Science
  265.    Foundation, Cooperative Agreement NCR-9218179, the UK Electronic
  266.    Libraries Programme (eLib) grant 12/39/01, and the European
  267.    Commission's Telematics for Research Programme grant RE 1004.
  268.  
  269.  
  270. 6. References
  271.  
  272.    Request For Comments (RFC) and Internet Draft documents are available
  273.    from <URL:ftp://ftp.internic.net> and numerous mirror sites.
  274.  
  275.          [1]         A. Gulbrandsen, P. Vixie, "A DNS RR for specifying
  276.                      the location of services (DNS SRV)," RFC 2052,
  277.                      October 1996.
  278.  
  279.  
  280.          [2]         M. Hamilton, R. Wright,  "Use of DNS Aliases for
  281.                      Network Services," Internet Draft (work in pro-
  282.                      gress), June 1996.
  283.  
  284.  
  285.          [3]         S. C. Partridge, "Mail routing and the domain sys-
  286.                      tem," RFC 974, January 1, 1986.
  287.  
  288.  
  289.          [4]         J. Veizades, E. Guttman, C. Perkins, S. Kaplan,
  290.                      "Service Location Protocol," Internet Draft (work
  291.                      in progress), April 3, 1997.
  292.  
  293.  
  294.          [5]         R. Moats, M. Hamilton, "Advertising Services,"
  295.  
  296.  
  297.  
  298. Expires 11/30/97                                                [Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304. INTERNET DRAFT               Finding Stuff                    April 1997
  305.  
  306.  
  307.                      Internet Draft (work in progress), February 1997.
  308.  
  309.  
  310.          [6]         C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A
  311.                      Means for Expressing Location Information in the
  312.                      Domain Name System," RFC 1876, January 15, 1996.
  313.  
  314.  
  315.          [7]         D. Eastlake, C. Kaufman, "Domain Name System Secu-
  316.                      rity Extensions," RFC 2065, January 3, 1997.
  317.  
  318.  
  319. 7. Authors' addresses
  320.  
  321.    Ryan Moats
  322.    AT&T
  323.    15621 Drexel Circle
  324.    Omaha, NE 68135-2358
  325.    USA
  326.    Phone:  +1 402 894-9456
  327.    EMail:  jayhawk@ds.internic.net
  328.  
  329.    Martin Hamilton
  330.    Department of Computer Studies
  331.    Loughborough University of Technology
  332.    Leics. LE11 3TU, UK
  333.    Email:  m.t.hamilton@lut.ac.uk
  334.  
  335.    Paul J. Leach
  336.    Microsoft
  337.    1 Microsoft Way
  338.    Redmond, Washington, 98052, U.S.A.
  339.    Email: paulle@microsoft.com
  340.  
  341.  
  342.               This Internet Draft expires November 30, 1997.
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358. Expires 11/30/97                                                [Page 6]
  359.  
  360.  
  361.  
  362.