| NetWare has traditionally used SAP, a Novell-proprietary protocol, to discover and advertise various services on an IPX network. NetWare 4 uses SAP to discover and advertise NDS tree names , for instance. With NetWare 5 and higher, servers running IP use SLP instead of SAP. This is also the case when in environments that include non-NetWare-based DS servers. Given that more and more networks are using IP as their main networking protocol (even in pure NetWare environments), SAP will eventually disappear and be completely replaced by SLP. Furthermore, in a mixed operating system environment, SLP must be used. Information about SAP has been widely available for quite some time; therefore, it is not discussed here any further. However, the following sections provide a brief review of SLP terms and concepts. TIP The following Novell TIDs provide information on implementing and configuring SLP : -
#10025313 ” Frequently Asked Questions about SLP -
#10014396 ” SLP Terms and Configuration Reference -
#10014467 ” Configuring a LAN/WAN Infrastructure for SLP -
#10059981 ” Configuring SLP with a SCOPED directory agent ( DA ) -
#10014466 ” Configuring SLP for a NetWare Client -
#10027163 ” Configuring SLP for a NetWare Server -
#10062474 ” SLP Design and Implementation Guidelines
SLP Agents SLP supports a framework in which client applications are modeled as user agents (UAs), and service agents (SAs) advertise services. A third entity, called a directory agent (DA), provides scalability to the protocol. These agents are used to register, maintain, and locate services on a network: -
SAs ” An SA runs on every server that is running SLP. Applications on this server register with the SA, and that information is stored 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. -
UAs ” A UA makes requests for service information. A UA is most likely to be a client that is looking for a service. The client can be a server application. For example, NDS makes requests for SLP service information when the server is brought up. -
DAs ” A DA stores and disseminates service information for the network. In Novell's implementation of SLP, the DA uses NDS as the data store for this information. An SA registers its services with a DA, and a UA requests service information from the DA. The SA registers its services for a specific period of time, called the service lifetime . If the SA does not re-register, or refresh, the service before this lifetime expires , the service is purged. NOTE DAs are optional in an SLP implementation, but UAs and SAs are not.
The SLP framework allows the UA to directly issue requests to SAs. In such a case, the request is multicast (because the UA does not know, initially, where the service is located). SAs receiving a request for a service that they advertise unicast a reply containing the service's location (see Figure 2.19). The multicast address that a UA sends to is 224.0.1.22. Note that this multicast packet is sent to every network and router that has multicasting enabled. Therefore, the UA may receive more than one response because every SA that receives this packet responds with service information if it has what the UA is asking for. Figure 2.19. Communication methods between a UA, a DA, and SAs. 
In larger networks, one or more DAs are generally used in order to reduce the amount of SLP- related multicast traffic attributed to service location queries. The DA functions as a central repository, or cache in this environment. SAs send register messages containing all the services they advertise to DAs and receive acknowledgements in reply. UAs unicast requests to DAs instead of to SAs if any DAs are known. UAs and SAs discover DAs two ways. First, they issue a multicast service request (to address 224.0.1.35), looking for the DA service when they start up. Second, the DA multicasts an unsolicited advertisement periodically (but infrequently), which the UAs and SAs listen for. In either case, the agents receive a DA advertisement, thus learning the whereabouts of DAs. NOTE SLP uses the following two multicast addresses: DAs listen on both UDP and TCP port number 427 for multicast traffic addressed to it.
SLP Services SLP services are applications that run on a host (server or client) that other hosts on the network can access. Common examples of services include NDS, RCONAG6.NLM , and TIMESYNC.NLM running on a NetWare 6 server. When a NetWare 6 server starts up, these services (applications) register themselves with SLP and make themselves available to the network. From a high-level viewpoint, the information that SLP maintains about a service is the service name and the IP address or DNS name of the host (normally a server) that is running this service. Each service on the network has a unique uniform resource locator (URL). This URL contains the details of the service, such as the IP address (or the DNS name or both) and port of the server on which this service is running and the version of SLP that this server is running. Table 2.7 lists some of the common NetWare 6.5 URL name prefixes and what they represent. Table 2.7. Common NetWare 6.5 SLP Service URL Prefixes and Their SAP Equivalents | SLP SERVICE URL | SAP EQUIVALENT (HEX) | WHAT IT REPRESENTS | | bindery.novell | 0004 | NetWare server. | | ldap.novell | N/A | LDAP service. | | ndap.novell | 0278 | DS on a server ”one entry for each NDS partition on a server. | | nlsmeter.novell | N/A | Software-usage-metering database manager. | | nwserver.novell | N/A | A special server-centric service. This SLP service was designed to list any service that might potentially be available and eliminate the need for a separate service entry (and thus DS object) for every service the server offers. For example, the rconsole.novell , bindery.novell , srs.novell , rms.novell , and other third-party services would all be detectable from this single SLP service. At the time of this writing, however, no applications have been rewritten to take advantage of this, and only the NetWare server itself registers with this service. | | portal.novell | N/A | iManager service. | | rconsole.novell | N/A | RCONAG6 running on a server (for RconsoleJ). | | rms.novell | 8202 | NDPS Resource Management Service (RMS). | | sapsrv.novell | N/A | IPX services on a NetWare 5 or higher server, available via the SCMD driver. IPX services from NetWare 4 are not registered. | | securerconsole.novell | N/A | Secure RCONAG6 service (NetWare 6 and higher). | | smdr.novell | 023F | Storage Management Data Requester (SMDR). | | srs.novell | 0282 | NDPS Service Registry Services (SRS); NDPS Broker NLM. | | timesync.novell | 026B | TimeSync service. |
The following is sample output of a DISPLAY SLP SERVICES console command on a NetWare 6.5 server: DISPLAY SLP SERVICES Usage: display slp services [<service type>/<scope>/<predicate query>]/ Example 1: 'display slp services' Example 2: 'display slp services bindery.novell//(svcname-ws==abc*)/' Searching Network . . . service:nwserver.novell:///NETWARE6A service:nwserver.novell:///NETWARE_51 service:portal.novell://10.6.6.1:8008/NETWARE6A service:securerconsole.novell:///10.6.6.1:2036; NETWARE6A.XYZCorp.com service:rconsole.novell:///10.6.6.1:2034; NETWARE6A.XYZCorp.com service:rconsole.novell:///10.55.66.77:2034;netware_51 service:timesync.novell://10.6.6.1 service:timesync.novell://10.55.66.77 service:smdr.novell://10.6.6.1:413/NETWARE6A service:ldap.novell:///10.6.6.1:389 service:bindery.novell:///NETWARE6A service:bindery.novell:///NETWARE_51 service:ndap.novell:///EDIR-NW51. service:ndap.novell:///eDir-to-eDir.DirXML-Guide-NW.EDIR-NW51. service:nlsmeter.novell://10.6.6.1:21571/NETWARE6A Displayed 15 URL's.
SLP Scopes When more than one DA is used, services (and SAs) advertised by the several DAs are collected together into logical groupings called scopes . The scope names are simply text strings assigned by the network administrator. A scope could indicate a location, an administrative grouping, or proximity in a network topology or some other category. A UA is normally assigned a scope name (in which case the UA will only be able to discover that particular grouping of services). This allows a network administrator to provision services to users. Alternatively, the UA may be configured with no scope at all (that is, it is unscoped). In that case, it will discover all available scopes and allow the client application to issue requests for any service available on the network. SAs and DAs are always assigned scope names. In Novell's implementation, a scope is simply a container within NDS for SLP services that have been registered with a DA. The SLP Scope Unit container object is the actual storage container for SLP service information. Each Scope Unit container holds all the SLP service objects for a specific scope. It is possible to replicate this container into other partitions within the tree or within federated trees. Associated with the Scope Unit container is the attribute Scope Name . The SA and UA use Scope Name to define what scopes they are to work with. SLP scopes are either scoped or unscoped: -
An unscoped scope is a general default scope. It is a grouping of all service URL information that is not tied to a particular scope. In SLP version 1, the default scope is called the unscoped scope . In SLP version 2, it is called the default scope . -
A scoped scope is a Scope Unit container that has been defined with a specific Scope Name attribute value. NOTE NetWare 5 implements SLP v1, as defined in RFC 2165. The latest support pack updates the SLP support to SLP v2, as defined in RFC 2608. NetWare 6 and later versions support SLP v2 out of the box. The related module names are SLP.NLM and SLPTCP.NLM . For non-NetWare platforms, such as Unix or Linux, the eDirectory installation process installs OpenSLP , an open -source implementation of SLP (see www.openslp.org ). This application is called slpuasa and is found in the NDSslp package. On Windows, the program is slpd.exe , and it is installed in the %WINDIR%\system32\Novell\eDir\OpenSLP folder.
NOTE If a network requires more than one scope and you want to set up a default scope container, create a scope called Default Scope . Do not use the unscoped scope in this configuration. This will make the transition to SLP version 2 easier.
If you are using SLP v1 on a network that has many services, you need to set up multiple scopes. This is due to the 64KB limit of SLP reply packet and service information. When a UA requests information about a specific service from a DA, it sends an SLP service type request, asking for all services of the same type (such as bindery.novell ). The DA responds with a single UDP reply packet. If there are so many bindery.novell services registered in SLP that they do not all fit within one UDP packet, the DA sets an overflow bit. The UA then opens a TCP connection with the DA and asks for all the bindery.novell services again. 64KB of data is all the DA can send to the client via a TCP connection. This is because in SLP version 1.0, the Length field in the SLP response packet header is only 16 bits, allowing for up to 64KB of service data. If there is more than 64KB of a certain service type, the list is truncated. The work around is to implement multiple scopes serviced by different DAs. A better solution, however, is to upgrade to SLP v2, where the length field has been expanded to 24 bits, thus allowing for up to 16MB of response data. For more information about the SLP packet structure, see www.networksorcery.com/enp/protocol/slp.htm. NOTE The following is a list of how many of the common service types will fit into a 64KB response packet: | Service | Number per response packet | | bindery.novell | 700 “1,100, depending on the size of partition and tree names. | | ndap.novell | Around 1,200, depending on the size of partition names. | | saprrv.novell | Around 550 IPX services. |
|
