SLP Terms and Configuration Reference

  • 7002142
  • 09-Dec-2008
  • 26-Apr-2012

Environment

Formerly tid # 2951567

Situation

SLP Terms and Configuration Reference

Resolution

This is one document in a series of documents that are designed is to provide network administrators with the settings and other configuration parameters associated with Service Location Protocol (SLP) and the configuration of User Agents, Server Agents, and Directory Agents. This document will be periodically updated as new information becomes available or settings change in newer versions. Other related documents include:

Frequently Asked Questions about SLP
SLP Terms and Configuration Reference
Configuring a LAN/WAN Infrastructure for SLP
Configuring SLP for a NetWare Client
Configuring SLP for a NetWare Server
SLP Design and Implementation Guidelines



SLP Terms:

Directory Agent (DA)
An module that significantly extends the ability of SLP. Provides the following new functionality over a non-DA SLP environment:

1. Allows registration of SLP services to central, partitionable (by Scope) SLP Service databases.
2. Can eliminate the need for UAs to multicast/broadcast to locate SLP Services and request SLP Service attribute information.
3. Allows the replication of the SLP Service database using the SLP Scope objects in NDS. NDS provides very efficient and reliable data replication with minimal synchronization times. This is particularly useful when trying to send SLP Service information across WAN links or other limited bandwidth routes.

A DA can be enabled on a server by loading SLPDA.NLM.

Dynamic Host Configuration Protocol (DHCP)
SLP information for both SAs and UAs can be received via the industry standard DHCP protocol. The DHCP Tags that can be used to issue SLP configuration information is given below:

63 - (12, 13, 14) - CMD settings
78 - Directory Agent List. Valid entries are DNS names or IP addresses.
79 - SLP Scope. If this is not set, it will assume the UNSCOPED scope.

Other key Novell Client DHCP Tags are:

85 - Preferred Server
86 - Preferred Tree
87 - Name Context

Novell's implementation of SLP was based on the current DHCP drafts as of the NW5 Service Pack 2, SLP was designed to receive DHCP parameters from the NetWare 5 DHCP server.  It is possible to configure other DHCP servers to hand out option 78 and 79 if the vendor allows the creation of the options and you manually enter the hex data that the NW5 client is looking for.

Migration Agent (MA)
Term used to describe NetWare 5 Servers that are loading SCMD with the /BS or /G switch (the functionality of using these switches is the same since NW5SP1A). These servers are capable of "routing" NCP traffic from IPX to Pure IP (sometimes called Native IP or NCP on IP). Considered loaded/enabled when SCMD.NLM is loaded with a /BS or /G switch (NOTE: Novell engineering is currently planning on using the  /BS as the standard in the future, administrators should plan on using this switch).

NCP
NetWare Core Protocol. NCP is an OSI Network Layer protocol (not Physical or Data Link) that Novell has developed to provide an interface to Server functions. A simple way to understand this, is that any request that is processed by a Core NetWare Service (i.e. File, NDS, Printing, etc...) will be an NCP request.

Server Agent (SA)
Is used to register SLP services with other SAs/DAs. Considered loaded/active on a NW5 server when SLP.NLM and SLPTCP.NLM are loaded.

SLP Scope
An SLP Scope is way or partitioning the SLP database. An SLP service registers itself in at least one SLP Scope. The SLP database is replicated by Scope. When performing any SLP queries, it always against a specific Scope. A good analogy is to compare the SLP Scope to the NDS Tree. Whenever you make an NDS request, it is always against a particular NDS Tree. NDS data is also replicated only among servers who are members of that tree (The analogy is not perfect here because you do have more granularity with the tree since you can further subdivide containers into different NDS partitions).  It is recommended that there be no more than 10,000 services registered per scope.


A UA will only request SLP services for the Scope(s) it has configured on the SLP Scope List. So the SLP Scope will control what DAs and SAs the UA will communicate with for SLP Service queries (if the SA/DA is not in a scope specified at the UA, the UA will not send a request or accept a response from it). The exception to this is if there is NO Scope specified, then the UA will participate in the UNSCOPED Scope. This is similar to concept of Public Community in SNMP where the host is configured by default to participate in the Public Community for both Monitor and Control. It requires an explicit configuration to change the SNMP Monitor and Control Community to something other than Public.

SLP Service
Entries in an SLP database for a particular Scope. Are registered by SAs and DAs. These are a direct replacement for what used to be SAP entries. The following is a list of the SLP Services and their SAP equivalents (if there is one):

SLP Service      SAP Equiv    Description
----------------------------------------------------------------------------------------------------------------------
bindery.novell     SAP 0004     NetWare Server
directory-agent                       SLP Directory Agent (DA)
mgw.novell                             SLP Migration Agent (MA)
ndap.novell        SAP 0278      NDS Server
rconsole.novell                       Java IP Rconsole
rms.novell           SAP 8202    NDPS Resource Management Service (RMS)
sapsrv.novell                          NetWare 5 Servers with IPX CMD loaded
srs.novell            SAP 0282    NDPS Service Registry Services (SRS)

SLP Time Window
SLP SAs and DAs have several timed events. Checking on whether to execute these timed events can be very server processor/resource intensive if performed frequently. Novell SLP Engineering developed the concept of an SLP Time Window to reduce the processor and other server resource usage needed to constantly check the time. The SLP timed events are scheduled in 128 second windows. SLP Services are re-registered in the SLP Time Window prior to when they would have expired. The following is an example to illustrate how this is used:

On eDir 8.8.2
1. An SA has registered an bindery.novell service with a DA at exactly 9:00:00 am.

2. The SA's default registration lifetime is 3600 seconds so the bindery.novell service will expire at 10:00:00 am.

3. The SA's SLP Time Window began at the exact same time that service was registered (i.e. 9:00:00 am).

4. The SA will schedule timed events to occur by the 128 second timed windows, so in this case it will be 3584 seconds later or 9:59:44.

5. At 9:59:44, the SA will attempt to re-register the bindery.novell service to prevent it from expiring on the DA.

On eDir 8.7.3 - The Time Window is 9 minutes, NOT 1 hour.

User Agent (UA)
The "client" functionality of SLP. Is used to contact SAs and DAs to locate services that are registered in the SLP scope.

Additional Information

Formerly known as TID# 10014396