- The advertisement of services by service agents
- The organization of services into directories managed by directory agents
- Obtaining service information for User Agents from the SLP framework, without prior configuration
- Providing a means for services to inform client applications of their capabilities and configuration requirements
Applications running at a computer are represented by a user agent which understands the service and resource needs of the application, and each network service is represented by a service agent which makes it available to user agents. Current applications and services which are not written to utilize the features of Service Location Protocol can be represented by SLP proxies which perform the same function as a user or service agent. SLP dynamically maintains service attributes, so that a User Agent may obtain current information. Services may be located automatically by applications, or presented to the user in a service browser. Slp supports existing applications and may easily allow advertisement and discovery of new services.
SLP also offers support for allowing network resources to be collected together into administrative domains called "scopes". Resources under a common administrative control are good candidates for inclusion in the same scope. User agents are typically configured (dynamically by DHCP, or as derived from initial computer setup) with the name of their administrative scope. Afterwards, each user agent includes its configured scope in service requests, which enables access to services configured to operate within that scope. Scopes may also indicate geographic proximity or network topology.
Service Location is also designed for both interactive and non-interactive use. As user agents are deployed that can manage their applications needs automatically, they can take advantage of the robust and ifficient mechanism afforded by Service Location. As services are replaced or taken out of service, such User Agents will simply discover alternate or replicated servers and continue operation. On the other hand, interactive use of Service Location gives the user the most complete possible information about the services available and configured for use within their local intranet.
- Service Agents, which advertise service handles
- Directory Agents, which collect together service handles in internetworked enterprises ("intranets")
- Maintaining the directory of advertised services
- Discovering available Directory Agents
- Discovering the available types of Service Agents
Services are described by configuring values for the attributes which are possible for that service. For instance, a printer can be described as a Postscript printer, a printer that has blue paper available, or a printer on the same floor as the users office. A user agent selects the appropriate printer by specifying the keywords and attribute values that it needs in a request message to a Directory Agent and awaiting a reply. In small installations, there may be no Directory Agents, and then the request message would be sent directly to the Service Agents.
Services advertise themselves by registering with a Directory Agent, and including in the registration a list of all the keyword and attribute-value pairs that describe their service. The registrations include a lifetime after which the service information is to be removed by the Directory Agent, to avoid cases where service hardware breaks but the service continues to be advertised forever. Explicit deregistration can also remove service information as part of a Service Agent's orderly shutdown procedure. Finally, Service Agents may register current attribute information periodically, allowing User Agents to ascertain their status, load, temperature, or other dynamic characteristics.
- Service Reply, sent to User Agents to provide a service handle
-Service Deregistration, sent when a Service Agent wishes to discontinue service or remove certain attributes from a registration
-Service Acknowledgement, acknowledging receipt of a registration or deregistration
- Attribute Request, used by User Agents to find out information about a type of service or characteristics of a particular service
-Attribute Reply, providing the requested information
- Directory Agent Advertisement, One of three ways to indicate to all Service Agents and User Agents the presence of a Directory Agent
- Service Type Request, Helpful when cataloging all available services for a browser
- Service Type Reply, providing the information to the browser
Services are classified by their Service Types. Each Service Type defines the available keywords and attributes which Service Agents have available to describe themselves. A browser can determine all the kinds of services available to its User Agents by discovering the Service Types available to it, and then querying for all the information advertised by Service Agents of that Service Type.
- Directory Agent Advertisements (multicast on the link)
- DHCP options - Multicast Service Request
If there are no Directory Agents, then the User Agent is limited to finding the Service Agents on the same link or adjacent links. This is probably fine for many small installations, but Directory Agents have to be used for scalable application of the Service Location Protocol to larger installations with multiple networks. In the rest of this paper, we assume the existence of Directory Agents.
- Character set problems worked out in a standard way
- Compatibility with browser operation
- Possibility for use of Service Location with address families other than IP (for instance, IPv6, IPX or Appletalk)
- AND operators
- OR operators
- common comparators {=, >, <, >=, <=}
- substring matching
Although not part of the Service Location Protocol itself, creating new Service Agents will be as easy as filling out a form for the particular network service. The form only needs to contain the available attributes and keywords for the service, for selection and assignment by the administrator. In many cases Service Agents can register with SLP programmatically, assigning values for the attributes based on the service's own configuration information. SLP then takes care of the registration (advertisement) and enables the establishment of connections between client applications and services.
New service types can be defined as necessary. Even experimental service types can be deployed for limited use, and later publicized for general use. This is accomplished with the use of SLP's Naming Authority features. Most common Service Types use, by default, the service template (scheme) definitions standardized by IANA, the Internet Assigned Numbering Authority. To define alternative service types is as easy as configuring Directory Agents to use scheme definitions known to any alternative Naming Authority, which would typically be a name known to the local administration. For instance, for special user administrative services at a particular enterprise (say, Sun Microsystems), one could define a "service:usradm.Sun" Service Type. Of course, client applications making use of service handles of this type would have to be able to use the network protocol of the "usradm" service, in order to communicate with it, and further be able to parse the information contained in the URLs of the special service type. That is inherent in the natural operation of any client/server protocol.
Lastly, Service Location is easier to use and administer because it is a lightweight protocol, and places few demands on the system resources of the host computers using it.
Another area of clear superiority is its natural way of offering dynamic registration and deregistration of services, so that directory agents can properly reflect the current availability of network services instead of whatever was correct at the last point in time when a system administrator had time to type in updates. This automatic population of directories is, so far, unique to Service Location Protocol.
Finally, SLP has various features which allow it to scale gracefully to larger intranets. Unlike other service discovery protocols (such as Netbios, Appletalk and Novell's Service Advertising Protocol) SLP minimizes the use of broadcast and multicast in the network. In a network where a Directory Agent has been deployed, all requests are sent point to point and all state information is centralized. SLP does not have a single point of failure, however, as DAs may be replicated and require no initial configuration to immediately become useful.
Each approach is currently useful for solving different problems. SLP takes care of the intranet resource discovery needs, and DNS SRV helps external customers. DNS SRV records do not offer the ability for selective acquisition of service handles. Users cannot expect to find a particular kind of service, since all services of the same type are lumped together into similar SRV records. In addition, only a service address may be obtained. Unlike the Service Location Protocol, service access information and service attributes may not be obtained with DNSSRV. Administratively, DNS, because of its critical nature, should not be used for extraneous directory operations. Resolving names into IP addresses is at the heart of the network operations of most sites, and separate functions should be kept separated from such essential operations. Moreover, directory updates are more heavyweight for DNS than for SLP, especially because there are typically more users than services at a site. Clearly, using DNS makes it unfeasible to represent hightly dynamic services, such as sessions or varying information, such as status or loads. Since DNS depends upon hierarchy for the structure of its namespace, and hierarchy is much less important or nonexistent in SLP, services can be more naturally administered in SLP, and directory services for SLP operations can be naturally broken into separate administrative domains in a way not naturally available to DNS. SLP agents are much smaller and easier to manage than DNS is.
SLP allows discovery with no a prior configuration. LDAP requires the address of the directory to start and knowledge of the directory schemas that LDAP uses.
SLP allows nonstrandart attributes and new versions of the standardized service type templates, sothey can evolve.
Even with all these advantages, SLP will not likely be able to displace the current deployment of LDAP, especially for those uses which are best suited to X.500 as opposed to service location. Thus, we are exploring the ways in which SLP can best offer support to simplify the administration of LDAP directories, and to enable SLP to return information obtained from LDAP directories as needed.
It is our belief that Service Location Protocol is the best choice for future management of networked services, and that this superiority will continue to widen as the world of computing increasingly becomes the world of access to network services and resources.
Last updated 5/14/97