Chapter 1 Overview of SLP

The Service Location Protocol (SLP) provides a portable, platform-independent framework for the discovery and provisioning of SLP-enabled network services on IP intranets. This chapter provides an overview of the SLP architecture and describes the Solaris SLP implementation.

• "SLP Architecture"

• "How SLP Is Implemented"

SLP Architecture

This section describes the fundamental operation of SLP, its constituent parts, and what these parts do for your enterprise. SLP facilitates the following:

• Client application requests for network service location information

• Advertisement of services

• Organization of services and users into logical or functional groups

• Managed recovery from primary server failures

SLP provides all of these services automatically, with little or no configuration. Additionally, you can configure SLP to assist with administration and tune SLP operation, if needed.

For instance, you can enable SLP logging mechanisms to monitor and troubleshoot the SLP operation on your network. You can tune certain properties to synchronize timing on SLP message exchanges between agents. Additionally, you can suppress SLP multicasts to reduce network congestion. Further, you can provision services by placing certain SLP agents, called, directory agents, strategically throughout the enterprise by creating groupings of users, called scopes, through which you can tailor service provisioning to meet the needs of your enterprise.

Summary of the SLP Design

In SLP, various software-based agents represent user applications and network services. SLP maintains information about the nature and location of enterprise services, so that the information about the SLP entities on the enterprise is automatically updated. Additionally, SLP is capable of advertising services that are not SLP-enabled using proxy registrations (see Chapter 7, Incorporating Legacy Services).

SLP Agents and Processes

The following table describes the agents and processes that make up the SLP framework.

Table 1-1 SLP Agents and Processes

Directory Agent	The directory agent (DA) is an optional SLP agent that stores and maintains a cache of service advertisements sent by the service agent (SA). When deployed, the DA resolves user agent (UA) service requests. The DA responds to active solicitations from the SA and UA for directory advertisements. Consequently, the SA and UA discover the DAs and scopes (see below) with which they are associated. A DA sends periodic unsolicited advertisements through which UAs and SAs discover the DA within shared scopes.
Service Agent	The service agent (SA) maintains service advertisements for a networked service. If no DA is available, the SA answers multicast service requests from UAs. If a DA is available, the SA registers and, optionally, deregisters services with DAs that support its scopes.
User Agent	The user agent (UA) acts on behalf of the user application and queries for the identity of its corresponding scopes, directory agents, and service advertisements.
Scope	A scope is a grouping of UAs and SAs arranged either administratively, topologically, or in another organizational manner. You can use scopes to tailor how you provision service access across the enterprise (see Chapter 5, Configuring Scopes).
SLP daemon (slpd)	In the Solaris implementaion of SLP, slpd is a daemon process that acts as either a DA or an SA server. Service processes on a host register their service advertisments with slpd rather than maintaining the advertisements individually. These service processes contain an SA client library that communicates with slpd, acting as the SA server. slpd forwards all registrations and deregistrations to DAs, and times out expired service advertisements. slpd also maintains a table of available DAs by performing active and passive DA discovery. Through these mechanisms, DA information is provided to UA clients. UA clients use slpd on their host only for DA information. Each SLP host automatically has an slpd daemon. You can optionally configure slpd as a DA.
Legacy Services	A legacy service is a networked service that is not SLP-enabled. Legacy services can be supported, provided that a proxy registration is created for them. Proxy registrations enable you to register non-SLP-enabled services with SLP. SLP-based clients can then discover legacy services (see Chapter 7, Incorporating Legacy Services).
Service Advertisements	A service advertisement is a URL and a collection of attribute/value list pairs that describe a service. All service advertisements have a lifetime. After the lifetime expires, the service advertisement is no longer valid, unless reregistered.
Service URL	A service URL is used to advertise the network location of services. It contains the service type name, host name, or network address of the system hosting the service, optional port number, and other information necessary to use the service.

The following figure shows the basic agents and processes that implement the SLP architecture.

Figure 1-1 SLP Basic Agents and Processes

The figure above also represents a default deployment of SLP in which no configuration has been done. Only two agents are required, the UA and SA. The SLP framework allows the UA to multicast requests for services to the SA. When the SA receives requests for a service that it advertises, it unicasts a reply to the UA containing the service advertisement.

The following figure shows the basic agents and processes that implement the SLP architecture when a DA is deployed in the framework.

Figure 1-2 SLP Architectural Agents and Processes Implemented with a DA

In more complex enterprises, one or more DAs are used. The DA serves as a cache for registered service advertisements. SAs send register messages (SrvReg) that list all the services they advertise to DAs and receive acknowledgments in reply (SrvAck). The service advertisements are refreshed with the DA, or they expire according to the lifetime set for the advertisement. Once a UA discovers a DA, UAs unicast requests to DAs rather than multicasting requests to SAs.

For more information about Solaris SLP messages, refer to Appendix A, SLP Message Types.

How SLP Is Implemented

In the Solaris SLP implementation, the SLP SAs, UAs, DAs, SA servers, scopes, and other architectural components (listed in Table 1-1) are mapped partially into slpd and partially into application processes. The SLP daemon, slpd, organizes certain off-host SLP interactions. The SLP daemon:

• Employs passive and active directory agent discovery for all UAs and SAs on the local host

• Maintains a table of DAs and keeps it current for the use of the UAs and SAs on the local host

• Acts as a proxy SA server for legacy service advertisements (proxy registration)

• Can be configured to act as a DA

For more information about the SLP daemon, see slpd(1M).

In addition to slpd, the UA and SA client libraries (libslp.so for C/C++ and slp.jar for Java) provide UA and SA clients with access to the SLP framework. The client libraries:

• Provide communication to register and deregister service advertisements between SA clients and slpd

• Provide UA clients with the capability to make UA requests

• Provide communication of DA accessibility information between slpd and UA clients

In the following figure, the SLP client library in the Service Provider Program implements SA functionality. The Service Provider Program uses the SLP client library to register services with slpd, and to deregister them. The SLP client library in the Service Client Program implements UA functionality. The Service Client Program uses the SLP client library to issue multicast and unicast (to DAs) service requests and to query slpd for information on DAs. The slpd process takes care of all SA functionality, such as answering multicast requests, registering with DAs, and so on.

Figure 1-3 SLP Implementation

Enabling SLP

SLP is enabled by running the SLP daemon, slpd. The supported interface for starting slpd is the /etc/init.d/slpd script, which starts the daemon only if the SLP configuration file, /etc/inet/slp.conf, exists. The Solaris operating environment includes the file /etc/inet/slp.conf.example. Rename this file to /etc/inet/slp.conf to enable SLP at boot time.