When NetWare began using TCP/IP as its default protocol, Novell took the opportunity to drop SAP and begin using SLP to identify and locate network services.

In a previous article (
Migrating from IPX to IP in NetWare 5.1
), I looked at some of the challenges that face those implementing NetWare 5.1 with TCP/IP. In this article, we will look at another of these factors: the Service Location Protocol (SLP).

From SAP to SLP

On IPX-based NetWare networks, clients and servers use the Service Advertisement Protocol (SAP) to locate network services. SAP provides a simple way of locating devices on the network with minimum intervention from administrators. Every 60 seconds, each server announces its availability to the other servers on the network. In addition to these server-to-server communications, clients use SAP to locate network services. Easy though it may be to configure, SAP's communications are based around broadcasts, which is its one major failing.

SLP's Function

The main function of SLP is to let clients locate an NDS server that can perform authentication. Once the client is authenticated, location of services normally becomes a function of the NDS rather than SLP.

In a small network, SAP's broadcasted announcements are not too much of a problem; but in larger networks, they can represent a large chunk of network traffic. Although Novell made a number of efforts to improve SAP, the company never managed to reduce the SAP broadcasts by any great extent; so, when TCP/IP became the default protocol for NetWare networks, the opportunity to drop SAP altogether presented itself. In place of SAP, Novell elected to use SLP as a means to identify and locate network services.

It would be unfair to suggest that SLP is a complex system, but it does have more considerations than SAP. To understand how SLP provides service locations, we must first look at the three software components that make the process happen:

User Agent (UA)Loaded on every server and workstation on the network. When the workstation or server wants to locate a service on the network, the UA will, depending on the SLP configuration, query the Service Agents or Directory Agents on the network for information about the location and availability of a given service.

Service Agents (SA)Loaded only on those devices that provide a service to the network. The services that are provided by a computer are registered with the SA so that when it is queried by UAs, it can respond with the correct information.

Directory Agents (DA)In a custom SLP configuration, used to centralize the information that is normally provided by the SAs. Rather than clients querying SAs individually for a list of available services, DAs can respond to clients with a complete list of network resources and thereby reduce the amount of traffic generated by requests for services. Clients can then use the information provided by the DA to communicate with the server providing the service.

The SLP Process

With SLP, rather than using broadcasts to make requests to servers, clients use multicasts, instead. When a client wishes to locate a service, it sends its request to a multicast address on which all the SAs on the network are listening. If a server can satisfy the request from the client, it replies to the client using a direct unicast. Although the multicast traffic is only marginally better than the broadcast traffic produced by SAP, the periodic announcements of services is not needed, thereby preventing the "60-second buzz" of SAP networks. Even so, in larger internetworks, these multicasts can still cause problems. This is where Directory Agent SLP components start earning their money.

DAs function by providing a centralized resource for the collection of service information. When DAs are used, SAs register their services with DAs, and UAs query the DAs directly for service information.