Subject: service discovery scenarios

From: Erik Guttman <[email-masked]>
Date: Thu, 6 Jan 2000 20:42:06 +0100 (MET)

Myron,

I suggest the following text for section 3.4.  I am listing the 
canonical service discovery scenarios. 

3.4 Scenarios for service discovery

3.4.1 Discover Printer

3.4.1.1  Overview

  Networked enabled printers allow various clients to submit print
  jobs.  There are different printing protocols possible (raw tcp,
  lpd, ipp, etc.)  Further, printers vary in a number of ways (their
  location, status and capabilities).  Printer discovery is important
  for both printing clients as well as 'printing managers' - that is,
  software which manages all printers of a particular kind on the
  network.

3.4.1.2  Key Points

  Printer discovery must allow a printing client to discover the
  location of a printer and enough information about the print
  job submission protocol to be able to submit jobs.  Further
  printer discovery must discriminate between printers which are
  useful and those which are not.  A printer which is located in
  a remote facility (across a continent) is not useful, nor is a
  printer which can't print in color, on transparencies, etc. if
  that is what the client needs to do.  Printer discovery has to
  be timely - so that when a printer comes on line, a print 
  client or a print manager application can discover the printer
  in a timely way.

3.4.1.3  Protocol Requirements

  Printer discovery implies the following requirements for service
  discovery.

    - The service discovery mechanism has to allow for discriminating
      queries.  A client has to be able to discover a printer for which
      it has a driver, for instance.

    - Service discovery has to be able to discover the characteristics
      of an advertised service.  A print client or a print manager has
      to be able to find out the configuration and possibly even status
      of the printer to be able to adequately provide information to the
      print client or print manager which is searching for appropriate
      print servers.  This information may be used for a user interface
      or by a program so the format of the information has to be standardized.

    - Service discovery has to be able to be done in a 'timely way.'  That
      is, within a short number of seconds after activating a print server,
      a user who is actively browsing for printer should be able to see the
      device appear in a browser window, or a printer manager should be
      able to begin managing the print server.

3.4.2 Discover File Access Server

3.4.2.1  Overview

  File sharing is done using different protocols.  A file sharing client
  is only interested in file sharing services which use the access protocol
  it is capable of.   File sharing is typically done by human users - in
  this case attributes of the file access server have to be discovered
  so the human user can select which server to access.  File sharing is
  done on a 'session basis' so timely rediscovery of selected file servers
  is necessary.

3.4.2.2  Key Points

  File sharing is a key application of personal computing.  There are a 
  variety of file access protocols available (NFS, Novell file access
  protocol (?), AppleShare, NetBIOS/SMB, etc.) A client must be able to 
  discover those file systems which exist on a network, which the client 
  can get access to, that support the file access protocol the client is 
  capable of using.  

  Further, existing service discovery mechanisms for file 
  access servers (from Novell, Apple and Microsoft proprietary protocols)
  allow the user to discover something about the file system they would
  access.  This include the name of the file system, a human readable
  description of it as well as a 'group' or 'groups' that the file system
  was shared to.  Since there may be many 'peers' in a network of personal
  computing devices, it is critical that some grouping is possible, so
  that users can locate file access servers that are meaningful to them
  (located nearby, shared by colleagues close to them in the organization,
  shared by those who will allow the user access to the files, file systems
  whose content is of a general kind, etc.)  Further, grouping file access
  servers is important to allow the service discovery activity to be 
  scalable in a network containing many systems capable of (or actively)
  providing file access service.  This scalability consideration is 
  different than the previous point (where grouping services prevents
  too much information to select from).  In this case, scalability 
  implies that requests will only be received and processed by a subset
  of the file access servers which advertise their services (or by a 
  subset of the 'service discovery protocol infrastructure' to be more
  general).  This will prevent service discovery from being a burden to
  the network.  This is an extremely important point:  Experience has
  shown that service discovery for services which are shared by many
  personal computers in larger networks can have disastrous effects.
  AppleTalk, Novell networks and Microsoft networks all suffer in 
  performance for this reason.

  Finally, file access is typically done on a 'session'
  basis.  That is, when a user decides to access a file system, he or
  she wants access to it over time.  If the file system is not available
  for a time, the user wants to get access to it again when the file 
  system is again available.  If the client system is moved or deactivated,
  the user wants to be able to discover the same file system again when
  the client device is again able to locate the previously discovered
  and selected file access server.

3.4.2.3  Protocol Requirements

  File access server discovery implies the following requirements:

  - Clients can discover the location of file access servers which 
    support the file access protocol they support.

  - Clients can discover only those file access servers which are
    in a 'group' they are interested in.  This grouping has to be
    possible along a variety of different conceptual lines (location,
    organizational - like which department, or functional - like a
    general description of the servers such as "reference library"
    or "mailing list archives".)  This is possible in Novell, AppleTalk
    and Microsoft networks.  It should be possible on IP networks in
    general.

  - The groupings listed above must be able to limit the effects
    of the file access protocol on the network.  This allows for
    scalable service discovery in a larger network.

  - Clients can discover some information about file systems that 
    they could choose to access (the name of the file system, a 
    description of it and whether the user has access permission, 
    at the very least).
 
  - Clients should be able to rediscover the file system over time
    so that the user can discover the same file access service 
    even if that service goes down and comes back up, or if the 
    client device moves or goes down, then is once again on a
    network where the file access server is present.  

3.4.3 Discover Manageable Device

3.4.3.1  Overview

  One important application of service discovery is the discovery of
  manageable devices by a 'management' system.  Conversely, manageable
  devices may need to discover their manager.  The relationship between
  manager and managed system is different than is the case in most
  service discovery applications since the manageable device is in
  many respects a service with respect to the manager, but there is
  usually only one manager and many manageable systems.

3.4.3.2  Key Points

  The management system (manager) needs to be able to discover devices
  which support appropriate management services (management agents).
  Currently this discovery is done in many networks by having the
  manager scan all addresses in order to determine the location and
  existence of all agents.  This does not scale well to larger address
  spaces.

  Managers need to discover agents in a timely way.  That is, when an
  agent is activated, a manager needs to be able to discover it within 
  a short number of seconds.

  Managers often need to discover a set of agents which have a certain
  configuration.  For instance, only those agents running on a certain
  hardware platform, with a certain software version.  This allows the
  manager to determine the population of agents which need an upgrade
  immediately.  This is not to say that the service discovery mechanism
  should replace the management protocol (whereby the manager can 
  interrogate the agent and obtain or set specific management information).
  The facility to find only specific agents allows the manager to 
  discriminate among agents on the network so that it can interrogate
  only that subset that are relevent.  This is important for scaling
  management software to larger networks where there may be many many
  agents.  This is even important on smaller networks where a specialized
  manager is only able to manager a very specific subset of all devices.

3.4.3.3  Protocol Requirements

  The service discovery mechanisms for managers to find agents
  (and thereby manageable devices) require the following:

  - Managers have to be able to find all agents they can manage.

  - Managers have to have the ability to discover agents shortly
    after they are activated.

  - Managers have to be able to discover only the subset of agents
    that are relevant.  This means that managers have to be able to
    discover agents on the basis of their hardware, software or other
    device specification or status.  To some extent the service discovery
    protocol has to return information about the agent to the manager,
    but this enhances the manager-agent relationship.  It does not replace
    the management protocol which can do specific management operations
    (including very specific structured queries of an agent by a manager).
 
3.4.4 Discover Service Discovery Infrastructure

3.4.4.1  Overview

  Service discovery protocols have two modes:  The first is used in a
  zeroconf environment.  The protocol in this case may not scale very
  well in a larger environment.  The second mode is to be used in a 
  configured network.  In this case, the service discovery protocol
  must scale well.  Clients discovering services and servers offering
  services have to be able to discover 'service discovery infrastructure'
  when it is present and transition to its use.  Further, configuration
  must be able to be supplied to clients and servers so that they will
  use the service discovery infrastructure scalably and appropriately.

3.4.4.2  Key Points

  Service discovery infrastructure has to be able to be discovered
  quickly, and by all clients and servers which are using a service
  discovery protocol.   This allows for a transition from an ad hoc
  (multicast or broadcast based protocol) to one which is suitable 
  for larger networks.  

  This service discovery infrastructure provides a concentration of
  service discovery information so that point to point messages can
  be exchanged instead of all service discovery messages having to be
  either multicasted (either solicitations or advertisements).

  Clients and servers using a service discovery protocol in a zeroconf
  environment have to be able to obtain configuration.  This configuration
  will enable the clients and servers to use specific portions of the
  service discovery infrastructure, or to use it in a particular way.
  This allows, for instance, services to be advertised according to a
  particular policy, as belonging to a particular department, in a 
  particular location or network, etc.  Similarly, clients obtaining
  configuration will only discover services which they are directed 
  to, such as services in their department, hotel room, etc.

3.4.4.3  Protocol Requirements

  Requirements arising from discovery of service discovery infrastructure
  include:

  - Service discovery infrastructure provides a transition from zeroconf
    service discovery protocol use to scalable and configured service
    discovery protocol use.

  - Service discovery infrastructure has to be discoverable by clients
    and servers which use a service discovery protocol automatically,
    and reasonably quickly.  The clients and servers have to use this
    infrastructure if it becomes available to ensure scalable behavior.

  - Configuration of clients and servers using a service discovery 
    protocol has to be able to be done dynamicly.  This way clients
    and servers will obtain the necessary configuration to operate
    effectively in larger networks according to the service deployment
    policy employed in the network the system is present in.