# An Introduction to SLP

### Whitepaper (DRAFT), Caldera Systems, Inc

### What Is SLP?

Service Location Protocol is an IETF standards track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks. Traditionally, in order to locate services on the network, users of network applications have been required to supply the host name or network address of the machine that provides a desired service. Ensuring that users and applications are supplied with the correct information has, in many cases, become an administrative nightmare.

Protocols that support service location are often taken for granted, mostly because they are already included (without fanfare) in many network operating systems. For example, without Microsoft's SMB service location facilities, "Network Neighborhood" could not discover services available for use on the network and Novell NetWare would be unable to locate NDS trees. Nevertheless, an IETF service location protocol was not standardized until the advent of SLP. Because it is not tied to a proprietary technology, SLP provides a service location solution that could become extremely important (especially on Unix) platforms.

### About this Document

Like all Internet Engineering Task Force (IETF) standards, Service Location Protocol (SLP) is described in great detail by documents called Request For Comments (RFC). IETF RFCs are usually lengthy, very detailed, and written in using precise language and notations. This document, on the other hand, was written to give an overview presentation of SLP. This document will, by nature, omit important details that would be interesting to the more technical reader. For these, the reader is referred the following 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

### SLP for Users and Administrators

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 he is interested in. Based on this description, SLP is then able to return the URL of the desired service.

Consider the following example of a new employee setting up his workstation to use one of the department printers:

> Traditional
> New employee: "Hey Stan, the setup program is asking me for the name of our printer. What should I type in?"
> Stan: "Which printer do you want?"
> New employee: "The big one by the copier."
> Stan: "I've heard it does not work well with postscript applications. You'll have to use the one down the hall."
> New employee: "Ok. What should I type in."
> Stan: "Actually, I don't know; I use the one by the copier. You'll probably have to call the IS help desk."
> New employee: <groan> ...

> With SLP
> A setup program uses SLP to display to the user the description (including location) of the printers that work with postscript. The user selects one that is close to his office.

### SLP for Software Developers

In many cases, SLP can eliminate the need for software applications to prompt users for host names, or to read host names from configuration files.

Consider the following example of a software engineer who is writing an LDAP-enabled application.

> Traditional
> Currently, the only way 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 SLP
> The developer uses SLP to obtain the host names and attributes of LDAP servers that are displayed to the user at install time and again if the user desires to connect to a different LDAP server.

> As illustrated in the example above, SLP 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.

### Agents

In order to understand the rest of this document (as well as all other SLP documentation), you will need to know about SLP agents. In SLP an agent is a software entity that processes SLP protocol messages. There are three types of SLP agents:

> User Agent (UA)
> The SLP User Agent is a software entity that is looking for the location of one or more services.

> Service Agent (SA)
> The SLP Service Agent is a software entity that provides the location of one or more services.

> Directory Agent(DA)
> The SLP Directory Agent is a software entity that acts as a centralized repository for service location information.

### Messages

In order to be able to provide a "framework" for service location, SLP agents communicate with each other using eleven (11) different types of messages. The dialog between agents is usually limited to very simple exchanges of request and reply messages.

> Service Request (SrvRqst)
> Message sent by UAs to SAs and DAs to request the location of a service.

> Service Reply (SrvRply)
> Message sent by SAs and DAs in reply to a SrvRqst. The SrvRply contains the URL of the requested service.

> Service Registration (SrvReg)
> Message sent by SAs to DAs containing information about a service that is available.

> Service Deregister (SrvDeReg)
> Message sent by SAs to inform DAs that a service is no longer available.

> Service Acknowledge (SrvAck)
> A generic acknowledgment that is sent by DAs to SAs as a reply to SrvReg and SrvDeReg messages.

> Attribute Request (AttrRqst)
> Message sent by UAs to request the attributes of a service.

> Attribute Reply (AttrRply)
> Message sent by SAs and DAs in reply to a AttrRqst. The AttrRply contains the list of attributes that were requested.

> Service Type Request (SrvTypeRqst)
> Message sent by UAs to SAs and DAs requesting the types of services that are available.

> Service Type Reply (SrvTypeRply)
> Message by SAs and DAs in reply to a SrvTypeRqst. The SrvTypeRply contains a list of requested service types.

> DA Advertisement (DAAdvert)
> Message sent by DAs to let SAs and UAs know where they are.

> SA Advertisement (SAAdvert)
> Message sent by SAs to let UAs know where they are.

### Unicast, Multicast and Broadcast

SLP is a unicast and a multicast protocol. This means that the messages described in the previous section can be sent to one agent at a time (unicast) or to all agents (that are listening) at the same time (multicast). A multicast is not a broadcast. In theory, broadcast messages are "heard" by every node on the network. Multicast differs from broadcast because multicast messages are only "heard" by the nodes on the network that have "joined the multicast group".

For obvious reasons network routers filter almost all broadcast traffic. This means that broadcasts that are generated on one subnet will not be "routed" or forwarded to any of the other subnets connected to the router (from the router's perspective, a subnet is all machines connected to one of its ports). Multicasts, on the other hand, are forwarded by routers. Multicast traffic from a given group is forwarded by routers to all subnets that have at least one machine that is interested in receiving the multicast for that group.

### Agent Dialog Examples

Agent Initialization

Service Registration

Service Request/Reply

### SLP API

One of the most important parts of the SLP specification is the standard Application Programmers Interface (API). The SLP API is an interface that allows programmers to use SLP in their applications to locate services. Without the API, SLP would be little more than a specification. With the API, developers can add easily add SLP based features to their programs.

The following is a list of the major SLP API function calls (more information can be found in "OpenSLP Programmers Guide" or RFC 2614):

> 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.

### Additional Information

Technical readers probably have additional questions that are beyond the scope of this document.

Security
SLPv2 has been designed to be a secure protocol. When properly implemented SLPv2 can ensure integrity and authenticity of data being transmitted between SLP agents. See RFC 2608 section 9.2 for more information.

Scalability
SLPv2 was designed to be a scalable solution for enterprise service location. It is not intended to be a solution for the global Internet. However as an enterprise solution, SLP can be configured to use "scopes" (see RFC 2608 section 11) and DAs in ways that should allow it to scale well in very large networks. More concrete evidence of SLPv2 scalability will become available when SLP is more widely used.

Implementations
The following is a list of SLP implementations:

> OpenSLP
> An OpenSource project that aims to provide a full SLPv2 implementation

> Sun Microsystems
> Offers a "reference implementation" of SLPv2 that is available under the Sun Community License

> Novell NetWare
> SLPv1 replaces SAP as the service location protocol of choice in NetWare 5.0 IP networks

> Axis Communications
> Uses SLP in its thin server products