What is SLP, Service Location Protocol?

(Last modified: 22Jan2003)

This document (10024590) is provided subject to the disclaimer at the end of this document.


What is SLP, Service Location Protocol?


SLP stands for Service Location Protocol. For NetWare 5.0, SLP version 1 was implemented, based on RFC 2165.

SLP is used by a client or server on a network to find the IP address of another client or server on the network that it would like to communicate to. An example of this would be a client logging into the network. In an IP network, the client needs to know the IP address of a server to which it can connect and perform NDS authentication. SLP is one of the ways that can be used to provide this IP address to the client. A host (client) can also use the following to find services on the network:

' Hosts file

' DHCP (to assign a default NDS context, Server, and Tree)

' DNS Names

The word "services" is used often in the context of SLP. Services are applications running on a host (server or client) which other hosts on the network can access. Common examples of services would be NDS, REMOTE.NLM, NDPS, and SCMD running on a NetWare 5 server. When the NetWare 5 server loads, these services (applications) will register themselves with SLP and make themselves available to the network. From a high level viewpoint, the information that SLP maintains is simply the service name and the IP address of the host (normally a server) that is running this service.

Each service on the network has a unique URL (Uniform Resource Locator). This URL contains the details of the service such as the IP address of the server on which this service is running and the version of SLP that this server is running. Here are some of the common NetWare 5 URL names and what they represent:

NDAP.Novell Represents an NDS partition in the tree.
Bindery.Novell Represents NDS running on a particular server.
SRS.Novell Represents NDPS
Rconsole.Novell Represents RCONSOLE running on a server.
Sapsrv.Novell Represents IPX Services on a server.

A sample URL would be: "service:bindery.novell///NW5_SERVER1" Within this URL would be the details of this service. For this example, the attributes would contain all the bound IP addresses on NW5_SERVER1. Every NetWare 5 server will register a bindery.novell service. The bindery.novell service represents the fact the NDS is running on this server.

SLP defines three agents that are used to register, maintain, and seek service information on a network.

' Service Agent (SA) ' A Service Agent runs on every server that is running SLP. Applications on this server will register with the SLP SA and store this in local cache memory. The SA also listens for service requests. If a request is received that matches a service that is registered, the SA will respond to that request

' User Agent (UA) ' A User Agent makes requests for service information. A UA will most likely be a client that is looking for a service, however, a NetWare 5 server can also act as a UA. An example of a UA on a server would be NDS. NDS makes requests for SLP service information when the server is brought up.

' Directory Agent (DA) ' A Directory Agent stores and disseminates service information for the network. The DA uses NDS as the data store for this information. An SA will register its services with a DA and a UA will request service information from the DA. The SA will register its services for a specific period of time called the 'Service Lifetime'. If the SA does not re-register the service before this lifetime expires, the service is purged out.

By default SLP uses multicasting to find an SA or a DA on a network. The multicast address that SA's listen for is and the multicast address that DA's listen for is A UA will send a multicast request to the address when it is looking for a service. This multicast packet is sent to every network and router that has multicasting enabled. In this case every SA that receives this packet will respond with service information if it has what the UA is asking for. A UA and SA will send a multicast packet to in an at.tempt to discover a DA. Every DA that receives this will respond. Once the UA or SA locate a DA, they will then send Unicast packets directly to the DA.

Without a DA in the network, a UA and SA will communicate something like this:

-' A Service on server such as NDS will register with the SLP SA on this server.
-' A UA, usually a client, will send a multicast request for this service.
-' The SA gets the SLP request and sends a unicast packet directly back to the UA letting it know that the requested service is running on this server.
-' The client will then send a unicast request to the SA for the details of the NDS service.
-' The SA will then send all the attributes (details) of the NDS service to the UA with another unicast packet. At this point SLP's job is complete.
-' The UA now has the information (IP address) of the server on which to authenticate into NDS with via TCP/IP..


Document Title: What is SLP, Service Location Protocol?
Document ID: 10024590
Solution ID: 1.0.48599059.2486300
Creation Date: 07Jan2000
Modified Date: 22Jan2003
Novell Product Class:NetWare


The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.