Contact Us Contact Us

SLP-Service Location Protocol

  Software Depot
Electronic download
Frequently asked questions
Product details and specifications
Select
Overview

This Release Notes covers the following topics:

How to Obtain SLP

SLP is available on HP-UX for 11i as a web upgrade at the following web site:
https://www.hpe.com/us/en/software.html/

Overview of SLP

The 'Service Location Protocol' (SLP) is an emerging Internet standard network protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks. This protocol is designed to simplify the discovery and use of network resources such as printers, Web servers, fax machines, video cameras, files systems, backup devices (tape drives), databases, directories, mail servers, calendars.

Traditionally, in order to locate services on the network, users of network applications are required to supply the host name or network address of the machine that supplies a desired service. SLP eliminates the need for a user to know the name of a network host supporting a service. Rather, the user supplies the desired type of service and set of attributes or keywords, which describe the service. Based on that description, the Service Location Protocol resolves the network address of the service of the user. slp uses Uniform Resources Locators (URL's) to locate services.

SLP implementation on HP-UX is based on SLP Version 2.0 and adheres to RFC2608. Please look at Known Problems for deviations from RFCs.

SLP implementation on HP-UX is based on OpenSLP version 0.8.0 developed by Caldera Systems, Inc. Table 1 summarizes the bundle version number of SLP supported on the HP-UX 11i v1 operating system.

Table 1: SLP Bundle Version Number

Product Version
Number
      Operating System      Bundle Version
Number  
    Release Date  
1.0 (Revision: 1.2)           HP-UX 11i v1  B.11.11.1.0.1.2  January 2007

Benefits of Using SLP

Following are the benefits of using SLP:

Dynamic Service Tracking

When service instances are added on a network,they are quickly visible to clients. When they are removed they are no longer visible. For example, when a printer or a fax machine is added to a network, they are quickly visible to the clients. When these devices are removed, it is no longer visible. 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 user's office. A service may be tracked by specifying the values of the attributes. As services are replaced or taken out of service, User Agents will discover alternate or replicated servers and continue operation.

Ease of Administration

Administrators do not need to help clients find new services or to remove services when they no longer are available. As services are replaced or taken out of service, User Agents will discover alternate or replicated servers and continue operation.

Ease of Development

SLP's well defined APIs and protocolsemantics allow service developers to rapidly provide network services.

Components of SLP

Basically, the SLP product consists of three components. Namely, the Service Agent, the Directory Agent and the User Agent.

Service Agents (SA): The applications that provide services, need to register information regarding the services they provide with the service agents and directory agents if they exist on the network.

Directory Agents (DA): This is a process, which collects service advertisements from the SA's or applications providing the services and stores them in it's local database. The DA can provide this service information to the clients trying to discover this service information.

User Agents (UA): The SLP User Agent is a software entity that is looking for the location of one or more services. SLP can eliminate the need for users to know the names of network hosts. With SLP, the user only needs to know the description of the service they are interested in. Based on this description, SLP is then able to return the URL of the desired service.

How SLP Works

Consider the example of a user wanting to use the Printer services on a network.

The following events occur on the server side:

As the printer is initialized and is in the ready mode the printer's URL is registered with the SA server and the DA server. The URL can have an IP address or the domain name. Services advertise themselves by registering with a Directory Agent. They can include in the registration, a list of all the key-words 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. This is done in order to 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.

The following events occur on the client side:

The client can query for a printer service with particular attributes, such as Postscript printer, including the scope information. The client then connects to the printer with the chosen attribute values within the scope defined and processes the print instruction.

Defining Scopes

Services are grouped together using 'scopes'. These are strings, which identify services that are administratively identified. A scope could indicate a location, administrative grouping, and proximity in a network topology or any other category. Service Agents and Directory Agents are always assigned a scope string. A User Agent is normally assigned a  scope string, through which the User Agent will be able to discover that particular grouping of services. This allows a network administrator to 'provision' service to users. If the User Agent is configured with no scope, it will discover all available scopes and allow the client application to issue requests for any service available on the network.

slp daemon

The slpd daemon provides the Service Agent and the Directory Agent functionality along with the ability to maintain a consistent state with respect to the locations of other SLP agents on the network. The SLP library (libslp.sl) provides UA functionality internally on a per process basis without the need to communicate with slpd running on local machines. This means that in certain cases, the slp daemon does not always have to be loaded on every machine. This helps to minimize the overhead for SLP for those machines that will only need UA capabilities.

The slpd daemon must be running on all machines that will be registering services. In other words, slpd is required on all machines that run applications and make calls to one of the following SLP APIs, SLPReg(), SLPDeReg().

The slpd daemon is the process that accepts registration requests for services from Service Agents and maintains this information internally. It then provides this service information to the clients UA's when queried. slpd also allows older applications which are not SLP-enabled to advertise the services. An option is provided to specify the file which contains the static registrations. By defaults it reads static registrations from the /etc/slp.reg file. If you expect the registrations for this file to be available to other machines, you must run slpd. The slpd daemon is required for automatic DA and scope discovery to work correctly. If you do not run slpd, then DA's and scopes can only be discovered via DHCP or the /etc/slp.conf file.

NOTE: Due to the lack of a standard DHCP API, DA discovery via DHCP is not yet supported.

The slpd daemon is not needed if a machine will only be requesting services. In other words, slpd does is not required on machines if a call will never be made to SLPReg(), SLPDeReg(). The slpd daemon is not needed on a machine if manual or DHCP DA or scope discovery is sufficient.

Configuring SLP

The options required for configuring slp daemon slpd are provided through a configuration file. By default /etc/slp.conf is the configuration file used by SA and DA. These options basically include DA configuration, Static Scope Configuration, UA Configuration and Tracing options. These options determine the behavior of "slpd" and UA to an extent.

An example SLP configuration file is available in /etc/slp.conf with the SLP distribution. See the man page slp.conf(4) for explanations of the various options and its semantics. Also see the slpd manpage for overview of slpd functionality.

Options provided for starting the SLP daemon

slpd [-d] [-c config file] [-r registration file] [-l log file] [-p pid file]

Options
 

[-d]  Don't detach from the controlling tty
[-c config file]  Option to change the file that slpd uses to read configuration information. Defaults to /etc/slp.conf.
[-r registration file]  Option to change the file that slpd reads to obtain static registrations. Defaults to /etc/slp.conf.
[-l log file]  Option to change the file that receives slpd log messages. Defaults to /var/log/slpd.log.
[-p pid file]  Option to change the file that holds the slpd process id. Defaults to /var/run/slpd.pid.

A script has been provided to start, stop and restart slpd and also to dump the database. The usage of this script is described below :

slpdc start  Starts the slpd.

The command line options to be passed to slpd
can be specified as:

slpdc options

slpdc stop Stops slpd
slpdc restart Restarts slpd
slpdc dump Dumps the database.

Deliverables

This software depot contains:

slpd SLP daemon. It encapsulates the functionality of SA server and DA server defined in RFC2608
libslp.1 Shared library containing all the SLP APIs mentioned in RFC2614. It encapsulates the UA functionality
libslpattr.1 Shared library providing the predicate functionality to SLP daemon (but not yet fully tested)
/etc/slp.conf A configuration file set to default values
/etc/slp.reg A static registration file (empty)
slpdc A script to start/stop/restart slpd and to dump valid registrations

The documentation for Service Location Protocol include manpages for slpd(1),libslp(3n), slp.conf(4), slp.reg(4), SLPerror(3n), and slp_syntax(7).

This software depot is a swinstallable depot. The installation of this depot is similar to any other swinstallable depot.

Static Registration

The SLP implementation allows legacy service applications that are not SLP-enabled (i.e., applications that were not compiled to use the SLP library) to participate in the SLP framework. Thereby allowing UA's to dynamically discover these legacy services. A file is used to provide the service information of these non-SLP-enabled applications. The default file being,/etc/slp.reg. This default file is read during the startup by slpd, and is re-read when ever a SIGHUP signal is received. The default file can be overwritten via the -r command line option of the slpd command.

For more information on how to set up the static registration file, see the slp.reg manpage.

Troubleshooting

The log information by default is written by slpd into the /var/run/slpd.log file. The log file can be specified during slpd start time using -l command line option. Options are provided in the slp.conf file to specify the various information that can be logged in the slp.log file.

The Configuration file options for logging are:

net.slp.traceDATraffic  To control controlling printing of messages about traffic with DAs.
net.slp.traceMsg To control printing of details on SLP messages.
net.slp.traceReg To control printing of dumps of all registered services upon registration and deregistration.
net.slp.traceDrop To control printing details when a SLP message is dropped.

Known Problems

Features yet to be Implemented

  • Asynchronous Request Handling
  • Incremental Registration
  • Authentication
  • UTF-8 support
  • SLPv1 interoperability

Features Not Tested

  • Predicate support

Divergence from RFC2614

Allows scopelist to be NULL or empty string

The configuration file parameters that are not supported in this version are:

  • net.slp.serializedRegURL
  • net.slp.multicastTimeouts
  • net.slp.DADiscoveryTimeouts
  • net.slp.multicastTimeouts
  • net.slp.datagramTimeouts
 
Additional product information
Product #: HPUXSLP
Version: 1.0
Software specification: HP-UX 11i v1(SLP_B.11.11.1.0.1.2_HP-UX_B.11.11_32+64.depot)
Select