Service Location Protocol
Articles and Tips:
01 Jul 1998
One of the most anticipated features of NetWare 5 is pure IP, the NetWare 5 architecture that provides NetWare Core Protocol (NCP) services over the TCP/IP stack natively (without any IPX header or services). Pure IP uses an array of IP-related protocols to provide these NCP services. For example, pure IP uses Service Location Protocol (SLP), a service discovery mechanism that allows NetWare 5 clients to locate servers and services that are Service Advertising Protocol (SAP) dependent during the bootup process.
This article explains when applications on NetWare 5 clients use SLP to locate services. This article also describes how SLP works and how devices that use SLP communicate.
WHEN DO APPLICATIONS ON NETWARE 5 CLIENTS USE SLP?
NetWare 5 provides several methods to discover services, including the following:
Novell Directory Services (NDS) Query. The preferred method for an application to locate a service is through NDS, which provides authentication and security services for devices that can be registered as NDS objects.
Domain Naming System (DNS) Lookup. An application that is not NDS aware can use DNS to locate a service.
Dynamic Host Configuration Protocol (DHCP) Query. The NetWare 5 client software uses DHCP to locate an NDS tree and server when the client is configured to use DHCP services. DHCP offers three new options for obtaining NDS tree, server, and context information from a NetWare DHCP server daemon (the DHCP server processes running on a NetWare 5 server).
Lightweight Directory Access Protocol (LDAP) Lookup. NetWare 5 provides LDAP support when an application specifically sends an LDAP query.
SLP Query. NetWare 5 clients in a pure IP environment use SLP to discover the preferred NDS tree and server when the clients are not configured to use DHCP services. Although SLP can be used as a more fully functional mechanism to discover services, the best implementation is to use SLP only during the bootup process.
The application itself determines which discovery method to use. For example, an NCP-based application queries NDS directly to locate a service. However, another application could use an LDAP query to locate a service.
The NetWare 5 client software has two options for locating an NDS tree and server in a pure IP environment: DHCP or SLP. The NetWare 5 client software uses DHCP if you have configured the client to use DHCP services. For example, you can configure the client to obtain an IP address from a DHCP server. The NetWare 5 client software uses SLP if you have not configured the client to use DHCP services.
Note: Note. In NetWare's IPX/SPX-based communications architecture, the NetWare client software issues a SAP broadcast (also known as a Get Nearest Server request) during the bootup process to locate services. When a NetWare 5 network is configured to support only pure IP, however, the NetWare 5 client software cannot use SAP to locate services. (Of course, losing SAP is not really a bad thing because devices that use SAP continually broadcast their services on the network.)
NetWare 5 includes a compatibility mode feature, which enables SLP to register services that are SAP dependent. When a service that relies upon service discovery is loaded on a NetWare 5 server, the server reroutes the SAP broadcast to SLP. The service can then be registered by a service agent or by a directory agent, and a user agent can locate this service. (These agents are shown in Figure 1 and are described in the next section.)
Figure 1: Applications can discover services through a service agent directly or through a directory agent.
SLP OVERVIEW
Defined in Request for Comments (RFC) 2165, SLP is a service discovery method for TCP/IP-based communications. SLP includes several processes. (See Figure 1.)
User agents
Service agents
Directory agents
Scopes
User Agents
A user agent initiates a discovery on behalf of an application. The NetWare 5 client software contains a user agent that is enabled by default and is launched during the bootup process. In a pure IP environment, SLP is the client software's preferred method to locate an NDS tree and server when this client software does not support DHCP.
Service Agents
A service agent works on behalf of a service to respond directly to a user agent's query for specific services. You can also configure a service agent to register the service with one or more directory agents. A user agent queries a service agent directly if no directory agent exists or if a directory agent does not respond to discovery queries.
Directory Agents
A directory agent collects and maintains information about service agents. A directory agent responds to a user agent's query only if the directory agent maintains information about the requested service.
If you use directory agents on a NetWare 5 network, the NetWare 5 client software queries the directory agent for service information during the bootup process. To configure a NetWare 5 server as a directory agent, you load an optional NetWare Loadable Module (NLM). However, you do not configure every server as a directory agent. You configure one local server as a directory agent, which provides service information for many other NetWare 5 servers.
Scopes
A scope can be thought of as a collection of services within a logical group. You might want to implement a scope for a very large installation to create a group of directory agents and services registered with these directory agents.
SLP NETWORK DESIGN
You may not use every SLP process on your company's network. The processes you use depends on which SLP network design you choose. The SLP network design you choose, in turn, depends on the size and complexity of your company's network. Essentially, you determine the number of services running on the network, and you choose the best SLP network design to handle these services. You can choose one of the following SLP network designs:
Small service radius
Medium service radius
Large service radius
Small Service Radius
You can use the small service radius design for an installation that supports 50 servers or less. In this design, user agents query service agents to locate services. (See Figure 2.) If you use a small service radius design on a NetWare 5 network, you simply keep the default settings for NetWare 5 and the NetWare 5 client software.
Figure 2: By default, NetWare 5 uses the small service radius design.
Medium Service Radius
In a large installation, however, you may not want hundreds of service agents replying to queries from user agents. In this case, you can load the directory agent on one NetWare server. When service agents for NetWare 5 servers discover that a directory agent is available, these service agents register with the directory agent. The directory agent then replies to queries from user agents. (See Figure 3.)
Figure 3: Service agents register with a directory agent to reduce traffic on a large network.
By default, the NetWare 5 client software can locate and use a directory agent if one exists on the NetWare 5 network. You do not have to reconfigure the NetWare 5 client software to use a directory agent.
Large Service Radius
You can use the large service radius design for a very large installation that has services spanning WAN links. In this design, you group services in scopes. For example, if your company had two offices--one in London and one in Paris--you could configure two scopes: a London scope and a Paris scope. (See Figure 4.) When a user in the London office requested a service, the request would indicate which scope contains the requested service. In this way, you would prevent SLP queries from being sent over a WAN link, which is typically a low-bandwidth, high-latency link that is not designed to handle excessive traffic.
Figure 4: If you define an SLP scope, the service agents in the scope automatically register with the appropriate directory agent.
You can also use the large service radius design to reduce the load on a particular directory agent: You separate services into scopes and set up a directory agent for each scope, ensuring that a single directory agent does not have to handle all SLP queries.
The large service radius design can become quite complex: You can assign several scopes to a particular directory agent, and you can assign several directory agents to one scope.
SLP COMMUNICATIONS
SLP communications can use User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) with registered port 427. Although most SLP communications use UDP, TCP can be used for bulk information transfer--that is, traffic generated by a single request with multiple replies. (If you use an access filter or a security filter on routers or gateways, you must remove the filter on port 427 to enable SLP communications to work properly.)
SLP uses a combination of several types of communications:
Directory agent discovery multicast packets (224.0.1.35)
SLP general multicast packets (224.0.1.22)
Internet Group Message Protocol (IGMP) multicast packets
Unicast packets (station address)
Locating a Directory Agent
During the bootup process, an SLP device sends a directory agent discovery multicast packet, looking for a directory agent. If the service agent locates a directory agent, the service agent uses unicast packets to communicate with that directory agent. (I have been examining SLP communications on a network running the beta 3 version of NetWare 5. I have noticed an anomaly on Windows 95 workstations: They send an initial SLP broadcast during the bootup process. This anomaly should be fixed when NetWare 5 ships.)
If your company's network doesn't support multicast packets or DHCP services, broadcast communications or static configurations can be used to discover directory agents. For example, if your company has a large network, you might have disabled multicast forwarding on routers to control traffic. In addition, you might have manually assigned IP addresses, eliminating the need for DHCP services.
Broadcast communications are, however, an undesirable way to implement SLP because a broadcast is considered a local operation and typically isn't allowed to propagate throughout an entire internetwork. As a result, using a broadcast reduces the radius in which services can be discovered to the local network only. A device cannot discover services on the other side of a router, unless the router forwards broadcast packets.
If no directory agent exists, the user agent sends an SLP general multicast packet to locate the requested service (rather than the directory agent). (See Figure 5.)
Figure 5: The user agent that sent this SLP general multicast packet is looking for an NDS tree called I2_TREE. (The beta 2 version of NetWare 5 uses the service type NDS.Novell, but the beta 3 version and the shipping version of NetWare 5 use NDAP.Novell.)
Joining a Multicast Group
SLP devices join a multicast group during the bootup process by sending an IGMP multicast packet on the network. Based on the IGMP multicast packets that IP routers receive from SLP devices, these routers decide whether or not to forward multicast packets to particular subnetworks. IP routers forward multicast packets only to subnetworks in which other devices have joined the multicast group. In this way, SLP uses multicast groups to reduce traffic.
SLP in Action on a NetWare 5 Network
To get a better idea of how SLP works, let's take a look at the NetWare 5 client software's bootup process. (This information is based on the beta 2 version of the NetWare 5 client software.) If the NetWare 5 client software is using SLP to discover services on a network that does not use directory agents or scopes, this client software completes the following bootup process:
The client software's user agent sends an SLP directory agent discovery multicast packet.
The client software's user agent sends an SLP general multicast packet for the migration gateway. (The migration gateway offers a gateway service between pure IP and pure IPX configurations on a NetWare 5 network.)
The client software's user agent sends an SLP general multicast packet to discover the preferred NDS tree and server. (See Figure 5.)
The client software's DHCP stack sends DHCP attempts. (These attempts were unanswered on my network because a DHCP daemon process is not running on the network.)
The service agent replies.
SERVICE TYPES
If you use a network analyzer, such as Novell's LANalyzer for Windows 2.2, to examine SLP communications, you will notice that SLP uses URLs to define resources. (See "New Decodes for Novell's LANalyzer for Windows 2.2.") This method of defining resources creates more flexible communications and naming mechanisms that take advantage of existing technology. For example, when a user agent sends an SLP query to find the preferred NDS tree and server, either a service agent or a directory agent replies with the following information:
service:ndap.novell:///I2_tree.
The IP address of the service provider (the NDS server, in this example) is located in the attributes of the reply.
Devices can also use SLP to discover other types of services, such as the following services:
service:lpr:// (Line Printer service)
service:http:// (HyperText Transfer Protocol)
service:nfs:// (Network File System)
CONCLUSION
The NetWare 5 client software on most NetWare 5 networks that are configured to use pure IP will automatically discover services. If you must configure SLP for a large network, you should keep in mind that SLP is the bootup protocol that replaces SAP broadcasts. SLP is not a fully functioning naming and discovery protocol like NDS. SLP has definite limitations and should be considered a stepping stone for the NetWare 5 client software to attach to the network. After the NetWare 5 client software is attached to the network, NDS provides service discovery and registration information for all other network operations by default.
Laura Chappell researches, writes, and lectures on protocol performance, troubleshooting, and optimization. Laura also presents customized training courses on network analysis. You can reach Laura via e-mail at chappell@imagitech.com.
Special thanks to Todd Rupper and Jim Erwin of Novell for their keen technical reviews and help in writing this article.
NetWare Connection,July 1998, pp. 32-37
New Decodes for Novell's LANalyzer for Windows 2.2
If you use Novell's LANalyzer for Windows 2.2, you can download the latest decodes from ImagiTech Inc.'s World-Wide Web site. With this update, LANalyzer for Windows 2.2 can decode the following protocols:
Service Location Protocol (SLP)
Dynamic Host Configuration Protocol (DHCP), including the DHCP services that come with NetWare 5
NetWare Core Protocol (NCP)/Transmission Control Protocol (TCP) (connection-oriented NCP over TCP/IP)
NCP/User Datagram Protocol (UDP) (connectionless NCP over UDP/IP)
Simple Mail Transfer Protocol (SMTP)
To update LANalyzer for Windows 2.2, you complete the following steps:
Download the LZFWIP.ZIP file from http://www.imagitech.com.
Decompress the LZFWIP.ZIP file, and then copy the .DLL files into the LZFW directory on your workstation's hard drive.
Copy the LZFW.INI file into the Windows directory on your workstation's hard drive.
NetWare Connection,July 1998, p. 36
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.