[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                                    WASRV
INTERNET DRAFT
                                                      Jonathan Rosenberg
                                                       Bell Laboratories
                                                            Erik Guttman
                                                        Sun Microsystems
                                                              Ryan Moats
                                                                    AT&T
                                                     Henning Schulzrinne
draft-rosenberg-wasrv-arch-00.txt                            Columbia U.
February 15, 1998
Expires: August 15, 1998


                     WASRV Architectural Principles

STATUS OF THIS MEMO

   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference mate-
   rial or to cite them other than as ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

1 Abstract

   This document defines the problem of wide area service location,


                                                              [Page 1]


Internet Draft                 wasrv arch              February 15, 1998


   describing its key attributes, and giving examples of location prob-
   lems which do or do not fall under its definition.  It also touches
   on a number of related protocols, and looks at how they fit, or do
   not fit, the problem of wide area service location.

2 Introduction

   There has been recent interest in mechanisms for discovery of ser-
   vices across the global internet. Such interest has manifested itself
   in numerous papers, standards proposals, and commercial tools. How-
   ever, what is meant by wide area service location seems to vary in
   all cases. This document defines the problem of wide area service
   location explicitly and narrowly. It also looks at how some current
   protocol architecures may or may not be applied to it.

3 Problem Definition

   Wide Area Service Location would allow client software to find ser-
   vices in remote locations in the Internet. Currently, this is very
   difficult to do. It generally requires the client software to be con-
   figured with the network address or domain name of a server. This
   requires the end-user to have knowledge of the network rather than
   merely an understanding of what she wishes to achieve.

   Wide Area Service Location would enable the discovery of services
   based on usage criteria as opposed to explicit knowledge of the name
   or address of the server. The considerations included below express
   the features which Wide Area Service Location should possess and
   issues which it must confront.

     oMulti-criteria. The client desires a service which can be charac-
      terized by a number of attributes. The client should be able to
      express the desired attributes of the service, and get back a
      server whose service meets the criteria. There should be no arbi-
      trary restriction on the type, values, or number of attributes
      which can potentially characterize a service. Some restrictions on
      typing and some convention with respect to the interpretation of
      values will exist in any wide area service location protocol.

     oLocation Independent. The location of the desired server is
      irrelevent and may not be known a priori. That is, the domain
      name, administrative domain and network address of the desired
      service is not generally known in advance and in many cases is not
      pertinent. In some cases, the location of a server may be impor-
      tant, but no more important than any other attribute of the ser-
      vice.

     oAuto Configured. It should be straightfoward to configure new
      clients and servers to use the Wide Area Service Location Proto-
      col. The new service should automatically be discoverable, requir-
      ing little or no setting of addresses or other parameters.


                                                              [Page 2]


Internet Draft                 wasrv arch              February 15, 1998


     oRapid Availability. When a server is first brought on line, it
      should become visible and accessible to clients rapidly.

     oService Based. The attributes provided by the client provide the
      attributes of the service, not the content provided by that ser-
      vice. For example, an attribute for a web server might be support
      of ICP, as this is a characteristic of the web service. Contains
      web page X is not an attribute of a web server, but rather a
      description of the content provided by a web server.

     oAutomated. The service location process should be automated, and
      not rely on interactive input from a user to satisfy a reasonable
      query. However, the protocol should not prevent interactive ses-
      sions.

     oRapid. The service location process should occur as rapidly as
      possible. Usually, it is the precursor to further communciations
      between the client and the server. Service discovery adds to the
      amount of time required to actually access the service.

     oPolicy Support. The agent responsible for satisfying the client's
      service request should be able to inject its own policy into the
      process. This policy may disallow various servers from being used
      by the particular client, for example.

     oWorldwide. The location of a matching server can be anywhere, as
      can be the client. The protocol should be internationalized, sup-
      porting queries and attributes in different languages.

     oScalable. There can be millions of clients, and thousands of
      servers for a particular service.

     oMildly Dynamic. The attributes which characterize the service pro-
      vided by some server do not change on small timescales. However,
      they may change on larger timescales, and this should be handled
      appropriately.

This definition elimnates quite a number of problems which might other-
wise be deemed wide area service location. For example:

     oYellow Pages. The yellow pages service allows you to find pizza
      parlors in San Antonio which deliver, or cleaners in Boise that
      are open on Saturday. While this resembles the wide area service
      problem, its focus differs in many respects. The most important
      distinction is that location (here, geographic) is a key part of
      the selection process. This allows for the use of a global, dis-
      tributed database in each geographic locale. YP is therefore
      focused on locating regional services. Locating wide area


                                                              [Page 3]


Internet Draft                 wasrv arch              February 15, 1998


      services, on the other hand, is based on multiple attributes, and
      is global in scope. Furthermore, there is no single attribute on
      which to hierarchically organize the database.

     oWhite Pages. The white pages service allows you to find some per-
      son or service with a specific name, associated with some organi-
      zation. Like the yellow pages service, it is based on strict hier-
      archies for the names. It lacks the multicriteria selection
      required of yellow pages, however. Its main difference from wide
      area service location is the assumption of a hierarchy of names.
      Service attributes are much flatter, by comparsion, and change
      more frequently than names in a WP database.

     oWeb Pages. The web page location problem is to find a web page
      (which is on some web server, of course) which contains the word
      foo. A slightly more advanced version of this would be to find the
      web page that talks about some subject. This location problem is
      different from the wide area service location problem in that it
      is looking for a document, not a service. The documents are usu-
      ally sorted and indexed based on either content or meta-
      information. The result is that searching is not automated, but
      progresses based on interactive input and trial from a human user.
      Furthermore, web indexing is based on pull of information by web-
      bots. Since webbots have no way of knowing when information on a
      page has changed, the information returned by a search engine is
      often stale and out of date.

     oUser Location. When making an Internet telephone call, it is nec-
      essary to find the address where the called user may be found.
      This address may depend on time of day (I'm at home after 9pm),
      callee preferences (If Bob calls, forward to my cell phone),
      caller preferences (I only want him if he's at work), and status
      (I'm currently on the phone - try my voicemail). This location
      service is different in that the attributes characterizing the
      service to be located (here, the person to be called) change on
      rapid timescales. Furthermore, there is usually a tie to adminis-
      trative location when finding a user. When I want to call John
      Doe, I usually know that John Doe works for Lucent, and so he may
      be found on a machine under their administrative control.

With so many examples of what is not a wide area service location prob-
lem, some example of what does quality are useful:

     oGateway Location. I want to make a call from a PC to someone on
      the PSTN in Zimbabwe. I need a telephony gateway that speaks H.323
      and uses the G.729 speech coder. The gateway should accept credit
      cards for the call.



                                                              [Page 4]


Internet Draft                 wasrv arch              February 15, 1998


     oMedia Server. I need a media server that speaks RTSP, and has all
      the latest Warner Brothers films in MPEG2 format.

     oBank Server. I wish to complete an electronic transaction on the
      Internet. I need to contact some server which will accept Visa
      cards, and then transfer some kind of token representing elec-
      tronic cash to me, which I can then use to purchase an item at a
      web site.

     oConference Bridge. I need a conference bridge that can handle at
      least 20 people, and understands H.261.

4 Other Protocols

   With the abundance of existing protocols for finding things on the
   Internet, it is valuable to comment on why these are not appropriate
   for wide area service location, and why something else is needed.

4.1 Service Location Protocol

   SLP [1] defines mechanisms whereby a client can locate a service
   within an administrative domain. The current architecture is centered
   around the concept of a directory agent, or DA. This device is a
   server which collects information about services provided by various
   service agents (SA's) across the network. The SA's register the ser-
   vices they provide directly with the DA. Clients (also known as user
   agents, or UA's) wishing to locate a service send a query to the DA,
   which then searches its database for matches. The DA then returns the
   list of servers to the client. Clients and SA's must know the IP
   address of the DA. This can be learned in one of several ways:
   through static configuration, through DHCP, through multicast adver-
   tisements from the DA, or through multicast searches performed by the
   client or SA.

   This protocol does not scale beyond a single administrative domain
   for several reasons:

     1.   Registrations of services from SA's to DA's are asynchronous,
          and the soft-state refresh interval is fixed (the recommended
          value is around three hours). This means that if thousands of
          servers attempt to register, the DA may be swamped with bursts
          of messages. As the number of servers grows, this problem
          worsens.

     2.   SA's must know the location of all DA's. In a small adminis-
          trative domain, this is easy. But in a wide area Internet,
          this is virtually impossible. Having fixed tables of DA's does
          not scale well, and is not dynamic enough. Using the multicast


                                                              [Page 5]


Internet Draft                 wasrv arch              February 15, 1998


          searching technique will cause an overload on the network,
          since the scope of such searches is neccesarily unbounded.
          Having DA's advertise their presence works better, but still
          causes traffic. With fixed soft-state refresh intervals, the
          bandwidth used grows linearly with the number of DA's present
          in the network.

     3.   As the number of servers and services grow, the disk space
          required for a DA to store information about all of them is
          excessive. DA's must somehow be able to provide service loca-
          tion for only a subset of services.

4.2 LDAP

   The Lightweight Directory Access Protocol [2] was designed as a thin
   front end for accessing an X.500 database. It's applicability has
   grown, and it is now a more general mechanism for both client and
   administrative access to distributed databases, X.500 or otherwise.

   Its main limitation for wide area service location is its reliance on
   indexing of the database on a single key, and distribution of compo-
   nents of the database across the network based on that key. Usually,
   this key is related to some kind of organizational hierarchy. This
   makes LDAP databases ideal for things like yellow pages and white
   pages. However, in wide area service location, there is no single
   attribute upon which the database can be distributed.

   Furthermore, LDAP requires a great deal of regularity in syntax and
   semantics in order to function properly. All cooperating databases
   and clients must use exactly the same schema. Furthermore, it is not
   feasible to store or search for entries for which the schema is not
   known a priori. This is problematic for wide area service location,
   where many remote services are involved, and where the client may not
   know about the schema. By its nature, the directory supports lookup
   of entities well, but wide area searches by 'type' very poorly. Wide
   area service location must be more flexible, allowing more looser use
   of schema. Furthermore, the schema for any service must be extensible
   in a de-centralized manner.

   While a wide area location system based solely on LDAP requires a
   more robust solution to the problems of server discovery than those
   given in [3] [4], LDAP could be used by clients to make requests of a
   wide area service location system.

4.3 DNS

   DNS, like LDAP databases, are based on a hierarchical organization.
   For DNS, this hierarchy is arranged based on domain name. Unlike


                                                              [Page 6]


Internet Draft                 wasrv arch              February 15, 1998


   LDAP, the queries for the database are based on a single attribute
   value (the domain name) to be matched. This makes its applicability
   to wasrv even less than LDAP. DNS is most useful for white pages type
   of services, which generally rely on a single attribute to match.

   However, unlike LDAP, DNS has some legacy use in service discovery
   where the domain of the service is known a priori. (see [5]). There-
   fore, for those systems that use DNS for wide area service location,
   [6] and [7] provide a discussion on how to accomplish this.

4.4 URN's

   Another possibility for a wide area service location is the
   use/resolution of URNs [8]. URNs can support the multi-criteria,
   location independence, network level and automation requirements.
   However, URNs at this time do not provide for auto configuration,
   instant availability and mildly dynamic requirements needed for a
   wide area location service. Therefore, while we can consider
   use/resolution of URNs at the client/server interface, they are not
   appropriate for the system in its entirety.

4.5 Whois++ or CIP

   Whois++ is another type of distributed database [9]. Unlike LDAP, it
   does not require the use of a strict hierarchy to organize the data-
   base. Each database is indexed into a collection of forward informa-
   tion (called a   centroid ), which is to other databases. Whois++
   servers use the information in centroids to aid query routing by
   returning referrals to clients. The client then uses the referral to
   determine where next to query for desired information.

   This approach has been expanded upon in the Common Indexing Protocol
   [10], which applies to any type of database, not just whois++. Note
   that CIP considers only the server to server "back-end" aggregation
   and distribution of index objects.  Client-server protocol exchanges
   are not considered under the CIP architecture, but are handled with
   "native" protocols (Whois++, LDAP, etc.)

   Since index objects aggregate databases, they may have a place in
   wide area service discovery. However, scalability issues (such as
   lengthening referral chains and index object size) make it likely
   that they would be just one component of an overall architecture.

5 Security Considerations

   Wide area service location must be able to provide functions for
   determining the authenticity of discovered services and their
   attributes. It is clear by its nature as a wide area discovery


                                                              [Page 7]


Internet Draft                 wasrv arch              February 15, 1998


   protocol that confidentiality is not a WASRV requirement.

   The WASRV framework itself should not be easily subvertable. That is,
   messages sent between WASRV agents should be able to be authenticated
   so that attackers cannot easily divert or bring down this wide area
   service.

   The 'autoconfigurability' requirement means that configuration
   requirements for security should be kept to a minimum even if they
   cannot be eliminated entirely.

6 Conclusion

   We have defined the problem of wide area service location, identify-
   ing its key attributes. Examples of service problems which do and do
   not fit our characterization are described. We then discussed some
   existing distributed data retrieval protocols which might be used for
   wide area service location, and shown how they are not appropriate.

7 Full Copyright Statement

   Copyright (C) The Internet Society (1998). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.

   However, this document itself may not be modified in any way, such as
   by removing the copyright notice or references to the Internet Soci-
   ety or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be fol-
   lowed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."



                                                              [Page 8]


Internet Draft                 wasrv arch              February 15, 1998


8 Bibliography

   [1] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service loca-
   tion protocol, Request for Comments (Proposed Standard) 2165, Inter-
   net Engineering Task Force, June 1997.

   [2] T. Howes, S. Kille, and M. Wahl, Lightweight directory access
   protocol (v3), Request for Comments (Proposed Standard) 2251, Inter-
   net Engineering Task Force, Dec. 1997.

   [3] R. Moats, LDAP servers finding other LDAP servers, Internet
   Draft, Internet Engineering Task Force, Nov. 1997.  Work in progress.

   [4] R. Moats, LDAP clients finding LDAP servers, Internet Draft,
   Internet Engineering Task Force, Nov. 1997.  Work in progress.

   [5] A. Gulbrandsen and P. Vixie, A DNS RR for specifying the location
   of services (DNS SRV), Request for Comments (Experimental) 2052,
   Internet Engineering Task Force, Oct. 1996.

   [6] M. Hamilton, P. Leach, and R. Moats, Finding stuff (how to dis-
   cover services), Internet Draft, Internet Engineering Task Force,
   Oct. 1997.  Work in progress.

   [7] M. Hamilton and R. Moats, Advertising services (providing infor-
   mation to support service discovery), Internet Draft, Internet Engi-
   neering Task Force, Oct. 1997.  Work in progress.

   [8] K. Sollins, Architectural principles of uniform resource name
   resolution, Request for Comments (Informational) 2276, Internet Engi-
   neering Task Force, Jan. 1998.

   [9] C. Weider, J. Fullton, and S. Spero, Architecture of the whois++
   index service, Request for Comments (Proposed Standard) 1913, Inter-
   net Engineering Task Force, Feb. 1996.

   [10] M. Mealling and J. Allen, The architecture of the common index-
   ing protocol (CIP), Internet Draft, Internet Engineering Task Force,
   Dec. 1997.  Work in progress.

9 Authors Addresses


   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Rm. 4C-526


                                                              [Page 9]


Internet Draft                 wasrv arch              February 15, 1998


   email: jdrosen@bell-labs.com

   Erik Guttman
   Sun Microsystems
   Bahnstr. 2
   74915 Waibstadt
   Germany
   email: Erik.Guttman@sun.com

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   email: jayhawk@att.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu





























                                                             [Page 10]