The Service Location Protocol (SLP) is an Internet Engineering Task Force (IETF) standards track protocol that provides a framework to allow network applications to discover the existence, location, and configuration of network services in enterprise networks. SLP is described in detail in the IETF Request for Comments (RFCs):
RFC 2165 - Service Location Protocol, Version 1
RFC 2608 - Service Location Protocol, Version 2
RFC 2609 - Service Templates and Service Schemes
RFC 2614 - An API for Service Location Protocol
OpenSLP is a continuation of the SLP implementation and was started at Caldera International Inc. Caldera is the OpenSLP project maintainer and contributor of the original code base. OpenSLP is installed as part of the VM Server and VM Client installations. For information on running OpenSLP, see Section 1.1.4. For further information on installing and configuring OpenSLP, see,
http://www.openslp.org/doc/html/UsersGuide/index.html
http://www.openslp.org/doc/html/faq.htm
http://www.openslp.org/doc/html/ProgrammersGuide/index.html
There are several instances where you need to modify the OpenSLP configuration for Caldera Volution Manager. Configuration changes in the file, /etc/slp.conf. Use the following information to determine if you need to modify the OpenSLP configuration for your implementation.
If you plan to implement more than one VM Server in your network each server has to be configured with a separate OpenSLP scope. The OpenSLP scope allows you to logically partition your network. For information on configuring more than one scope, see Section 2.7.
VM Clients use OpenSLP to find the VM Server. VM Clients must be able to communicate with an SLP Directory Agent (DA) located on the VM Server to find DENS and the computer creation services. For information on specifying the DA Address, see see,Section 1.1.9 in the subsection, Section 1.1.9.1.3. These instruction also apply if your are managing clients outside your firewall, over a router, outside the domain of your VM Server, or on a separate subnet.
OpenSLP is an open standard technology that allows systems to discover services available for use on the network. Since it is not a proprietary technology, OpenSLP can provide a cross- platform service location solution.
OpenSLP eliminates the need for users to know the names of network hosts. With OpenSLP, the users need only know the description of the service they want to use. Based on this description, OpenSLP is then able to return the URL of the requested service.
Without OpenSLP, users of network applications are required to supply the hostname or network address of the system that provides the requested service. For example, a new employee might need to ask others for the name of a postscript printer to use during printer setup. If there is no other users around with a postscript requirement, finding this information out requires a request to the Help Desk. Using OpenSLP, the printer setup program displays a description (including location) of the printers that work with postscript. The new employee can complete printer setup without logging a request to the Help Desk or following a trail around the office to the network expert that might have this information.
OpenSLP reduces the need for software applications to prompt users for hostnames or to read hostnames from configuration files.
Without OpenSLP the only ways to know the hostname of the LDAP server to use in the call to ldap_init() is to read it from a configuration file. The configuration file must be created at install time and updated as the location of the LDAP server changes. Keeping this configuration file up to date becomes a real problem especially when the LDAP application is installed on a laptop that connects to various networks.
With OpenSLP, the developer uses OpenSLP to obtain the hostnames and attributes of LDAP servers that are displayed to the user at install time and again if the user wants to connect to a different LDAP server.
OpenSLP does not always eliminate the need to prompt users for information. However, it does allow the software developer to present a descriptive list of services that can be understood by the user.
In OpenSLP an agent is a software entity that processes OpenSLP protocol messages. There are three types of OpenSLP agents:
User Agents (UA)
A software entity that is looking for the location of one or more services.
Service Agent (SA)
A software entity that provides the location of one or more services.
Directory Agent (DA)
A software entity that acts as a centralized repository for service location information.
OpenSLP agents communicate using 11 types of messages. These messages provide the framework for service location. The dialog between agents is usually limited to simple exchanges of request and reply messages.
Table B-1. Message Types
| Message | Description |
|---|---|
| Service Request (SrvRqst) | Sent by UAs to SAs and DAs to request the location of a service. |
| Service Reply (SrvRply) | Sent by SAs and DAs containing information about a service that is no longer available. |
| Service Registration (SrvReg) | Sent by SAs to DAs containing information about a service that is available. |
| Service Deregister (SrvDeReg) | Sent by SAs to inform DAs that a service is no longer available. |
| Service Acknowledge (SrvAck) | A generic acknowledgement that is sent by DAs to SAs as a reply to SrvReg and SrvDeReg messages. |
| Attribute Request (AttrRqst) | Sent by UAs to request the attributes of a service. |
| Attribute Reply (AttrRply) | Sent by SAs and DAs in reply to a AttrRqst. The AttrRply contains the list of attributes that were requested. |
| Service Type Request (SrvTypeRqst) | Sent by UAs to SAs and DAs requesting the types of services that are available. |
| Service Type Reply (SrvTypeReply) | Sent by SAs and DAs in reply to a SrvTypeRqst. The SrvTypeRply contains a list of requested service types. |
| DA Advertisement (DAAdvert) | Sent by DAs to let SAs and UAs know where they are. |
| SA Advertisement (SAAdvert) | Sent by SAs to let UAs know where they are. |
OpenSLP is a unicast and a multicast protocol. Unicast messages are sent to one agent at a time or from one host directly to another. Multicast messages are sent to all agents that are listening at the same time. The default for OpenSLP transport is multicast. Multicast traffic from a given group is forwarded by the routers on your network to all subnets that have at least one system that is interested in receiving the multicast for the group.
Broadcasting is not used with OpenSLP unless there are no routers on your network. Network routers filter almost all broadcast traffic. Therefore, broadcast messages that are generated on one subnet are not routed or forwarded to any other subnets connected to the router (from the router's perspective, a subnet is all systems connected to one of its ports). If you have a simple network that does not contain a router or a router that does not support multicasting, multicasting might not work. If that is the case, enable broadcast via /etc/slp.conf.
For more information on common problems and questions, see http://www.openslp.org/doc/html/faq.html.
One of the most important parts of the OpenSLP specification is the standard Application Programmers Interface (API). the OpenSLP API is an interface that allows programmers to use OpenSLP in their applications to locate services. With the API OpenSLP would be little more than a specification. With the API, developers can add OpenSLP-based features to their programs.
Table B-2 lists the major OpenSLP API function calls. For a complete list, see http://www.openslp.org/doc/html/ProgrammersGuide/index.html.
Table B-2. OpenSLP API Function Calls
| Function Call | Description |
|---|---|
| SLPReg() | Registers a service URL and service attributes with SLP. |
| SLPDeReg() | Deregisters a previously registered service. |
| SLPFindSrvs() | Finds services based on service type or attributes. |
| SLPFindAddrs() | Obtains a list of attributes for services registered with SLP. |
| SLPFindSrvTypes() | Obtains a list of the types of services that have been registered with SLP. |