SLP defines three types of agents:
Functionality of SLP Directory Agents is not provided for Linux* or Solaris* systems.
User Agents work in behalf of client applications to retrieve service URLs and attributes of desired network services. Client applications can request all URLs of a specific service type or narrow the search by requesting only services of a certain type with specific attributes.
If no Directory Agents are available to the User Agent, the SLP request is sent to multiple services (multicast) using the Service Location General Multicast Address (224.0.1.22, see RFC 2165). All Service Agents holding service information that satisfy the request unicast the reply (using UDP or TCP) directly to the requesting User Agent.
If a Service Agent has the requested service information, it replies. If multiple Service Agents reply, the User Agent combines the replies before presenting them to the client application. If a Directory Agent is available, the User Agent unicasts the SLP request to the Directory Agent rather than sending a multicast request. The Directory Agent always unicasts a reply even if the answer indicates that no services are available.
User Agents send the following SLP requests:
Table 115. SLP Requests Sent by User Agents
User Agents process the following SLP replies:
Table 116. SLP Replies Processes by User Agents
Novell provides implementations of User Agents for NetWare, Windows 95/98, Windows NT, and Windows 2000.
Service Agents (defined by RFC 2609) work in behalf of network service applications to passively advertise service URLs representing the services provided. Network service applications register the service URL and attributes that define their network service with the Service Agent.
The Service Agent maintains a local database of registered service information. The Service Agent does not broadcast or multicast the registered services on the network but passively waits for SLP requests to be multicast from User Agents.
If Directory Agents are present, the Service Agent registers the services with each Directory Agent.
Service Agents send the following SLP requests:
Service Registration: Registers a service URL and its attributes with a Directory Agent.
Service Deregistration: Deregisters a service URL and its attributes from a Directory Agent.
Service Agents process the following SLP requests:
Service Type Request: Returns all held service types.
Service Request: Returns the service URLs of a specific type.
Attribute Request: Returns the attributes of a specific service URL.
DA Advert: Sent by Directory Agents to indicate their existence.
Novell provides implementations of Service Agents for NetWare, Windows 95/98, Windows NT, and Windows 2000.
The Directory Agent maintains a database of service URLs representing network services. Service Agents acting in behalf of network applications register service URLs with the Directory Agent.
Multiple Directory Agents can be deployed in a network. Service Agents register their service URLs with each known Directory Agent, maintaining consistent service information among all Directory Agents.
RFC 2165 does not define a protocol for synchronizing service information between Directory Agents. To compensate, Novell SLP Directory Agents support a feature known as Directory mode.
Directory Agents configured for Directory mode use Novell eDirectory as a common, distributed, replicated data store through which multiple Directory Agents can share service URLs. This enables Directory Agents to report service URLs that were registered with other Directory Agents, configured in Directory mode, as well as report the services registered by local Service Agents.
Such reporting reduces network traffic by eliminating the need for Service Agents to register with every Directory Agent in the network. This reduction is particularly advantageous for large enterprise networks with WAN backbones.
Novell provides implementations of Directory Agents for NetWare, Windows NT, and Windows 2000. Directory Agents running on NetWare operate only in Directory mode. Directory Agents running on Windows NT or Windows 2000 can operate in Directory mode or Local mode. A Directory Agent operating in Local mode does not share service information with other Directory Agents. It operates autonomously, as defined by RFC 2165.
The Directory Agent is responsible for processing the following SLP protocol messages:
These SLP messages enter, delete, or query for service URLs and associated attributes in the Directory Agent's service database.
For more information on these message types, refer to RFC 2165.
To register service URLs and their attributes with Directory Agents, Service Agents send Service Registrations. Each service URL includes a lifetime which, if it expires, causes the Directory Agent to delete the service from its database.
The Service Agent must refresh the service registration at least once during the service's lifetime. The service lifetime ensures that the Directory Agent can eventually purge its service cache of service URLs registered by Service Agents that do not deregister their service URLs.
To remove a service URL and its attributes from the Directory Agent service cache, Service Agents send Service Deregistrations to Directory Agents. This action can occur if the network application is terminating or if the Service Agent is being shut down.
To obtain a list of active service types on the network, User Agents send Service Type Requests to Service Agents (multicast) or Directory Agents (unicast). Service Agents and Directory Agents return their known service types with a Service Type Reply, which is unicast to the requesting User Agent.
Service Requests are sent by User Agents to Service Agents (multicast) or Directory Agents (unicast) in search of service URLs representing desired services. Service URLs matching the request criteria are returned in a Service Reply, which is unicast to the requesting User Agent.
Service Requests can be general in nature and request all URLs of a specific service type, or they can contain a predicate that specifies that only services of a certain type with specific attributes be returned.
To retrieve one or more attributes of a specific service URL, User Agents send Attribute Requests to Service Agents (multicast) or Directory Agents (unicast).
The Attribute Request can be general, requesting that all attributes be returned. Also, the Attribute request can contain an Attribute Select list, identifying one or more specific attributes to be returned.
The requested attributes are returned in an Attribute Reply that is unicast to the requesting User Agent.
To periodically notify Service Agents and User Agents of Directory Agents' existence, Directory Agents multicast Directory Agent Advertisements. Directory Agents also return Directory Agent Advertisements in response to Service Requests for the directory-agent service type.
Directory Agent Advertisements contain:
If multicasts are not enabled or allowed in a network, User Agents and Service Agents can be configured with the network addresses of Directory Agents. In such a case, the User Agent and Service Agent query (with a Service Request of type directory-agent) the Directory Agent for its Directory Agent Advertisement.
For a complete description of User Agent, Service Agent, and Directory Agent synchronization, see RFC 2165.
An SLP scope is a defined group of network services. Scopes enable one or more groups of users to easily use network services.
To define a scope, you can use criteria that help you organize and administer network services. If you have configured users to use a specific set of scopes, you can effectively assign a set of available services to those users.
You can create scopes to reflect departments in your company, for example:
With these scopes, you can configure users in the Human Resources department to use the Human Resources scope. Also, you can configure users in the Accounting department to use the Accounting scope. Users requiring services in both departments can be configured to use both scopes.
Likewise, services can be grouped according to geographical location. You can define an SLP scope for each city or country where your company has an office. You can configure users in each locality to use the scope defined for their office. If a user needs access to services in multiple sites, you can configure that user to use the scopes of all necessary sites.
In addition to dividing services according to organizational and geographical criteria, you can define scopes to hold common services that multiple groups must share. This feature allows users to locate shared services while keeping their unique services locally.
Another reason to use scopes is to enhance the scalability and performance of SLP. Service registrations are organized and stored according to the scope in which they have been registered. Directory Agents are configured to service one or more scopes. If all services in a network are contained in a single scope, and hence a single service cache, the amount of service information can become unwieldy and difficult to manage. Response times might suffer because of the immense amount of data that must be searched to satisfy a request.
Therefore, in large network environments, it is better to group the services into scopes and then assign one or more Directory Agents to service the scopes applicable to the users that will be utilizing the Directory Agent.
Service Location Protocol 1 (RFC 2165) defines the default operating configuration of User Agents, Service Agents, and Directory Agents to be unscoped, meaning that no scopes are configured. This means that all services are maintained as if in a single scope that has no name.
Additionally, special rules apply when registering with, or requesting services from, unscoped agents. In particular, all services regardless of scope should be registered with unscoped Directory Agents. But if an unscoped request is made to an unscoped agent, only those services registered as unscoped can be returned. On the other hand, a scoped request will return all services from the requested scope as well as all unscoped services matching the request criteria.
When both scoped and unscoped agents are used in the same network, results are often confusing and sometimes inconsistent. Therefore, Service Location Protocol 2 (RFC 2608) removed unscoped operation from the Service Location Protocol and redefined the default operating configuration to use a default scope named Default.
To eliminate the confusion associated with mixing unscoped and scope agents in a single network and to facilitate eventual migration to SLP 2, we recommend that users always configure SLP to use scopes.
For the following reasons, generally use scopes to organize SLP service:
Fundamental to the successful organization, deployment, and administration of SLP in a network, scopes are a valuable tool in controlling the availability of services in the network