SLPv2 Overview

At its most fundamental level, SLP is an electronic GPS for network services. So how does it work? Services on the network register themselves with an SLP agent running on a NetWare server. When a client needs to locate a particular service on the network, it queries the SLP agent, which, in turn, provides the client with the address of the service. Furthermore, in NetWare 6, SLP works with eDirectory to help bring together the IP infrastructure services, such as eDirectory trees, DNS servers, NetWare servers, and various network protocol gateways. This enables clients to discover services by querying a central database rather than the whole network.

In this SLP overview, we will begin by exploring the family of Name Service Providers supported by NetWare 6. Then we will focus on SLP as the preferred provider and dive into more detail regarding its architecture. Finally, we will discover Directory Agents, User Agents, and Server Agents, and learn how they communicate with each other to provide network services to NetWare 6 clients.

NetWare 6 Name Service Providers

SLP is not the only Name Service Provider supported by NetWare 6. In fact, five different providers deliver name resolution services to Novell clients. Following is a brief description of SLP's Name Service Provider family:

• eDirectory This is the patriarch of name resolution. As the central database of all network services, eDirectory provides a list of corresponding servers that host network-wide applications, protocols, and services. In addition, eDirectory can resolve fully qualified server names if the server resides in the eDirectory tree. Unfortunately, eDirectory cannot behave as an independent service provider. In fact, eDirectory itself is a service; it must be discovered by another Name Service Provider before it can be used to resolve network names.

• Domain Name System (DNS) As we learned earlier in this chapter, DNS resolves fully qualified eDirectory server names to their corresponding IP addresses. Unlike eDirectory, DNS can act independently of any other name service provider provided that the client is configured with the IP address of the DNS server. Unfortunately, DNS cannot dynamically discover services that are started or stopped on the network. You must manually add and remove service names to IP address mappings as services are added or removed. This shortcoming makes DNS a bad choice as the primary name service provider.

• NWHOST NWHOST is the NetWare host file that lists service names and associated IP addresses. It is elegant in its simplicity. Unfortunately, host file service providing is not a viable strategy for medium- or large-size networks. Imagine how unwieldy the NWHOST file would become on a Novell network with 10,000 clients.

• Dynamic Host Configuration Protocol (DHCP) DHCP is a very simple name service provider that allows preconfigured clients to initially establish connections and set various client parameters (such as preferred tree and preferred context). Like DNS, DHCP is not powerful enough to be your primary service provider.

• Service Location Protocol (SLP) This brings us to the final and most powerful name service provider supported by NetWare 6 SLP. SLP combines the following strengths of the other four service providers: central management through eDirectory integration, fully qualified IP address mapping, and the ability to push centralized configurations to network clients. And to make things even better, SLP provides dynamic discovery of network services so that you don't have to configure it once it is running. For all of these reasons, SLP is the preferred method of network service discovery.

NetWare 6 uses SLPv2. As we learned earlier, SLPv2 offers numerous enhancements over the SLPv1 version used in previous releases of NetWare. Table 4.7 is a short list of the network services autodiscovered by SLPv2.

In summary, SLPv2 provides two primary benefits to NetWare 6 networks: management and fault tolerance. SLPv2 centralizes network management by autoregistering changes in network architecture whenever a workstation or protocol is reconfigured. In addition, SLPv2 enhances fault tolerance because it enables clients to find services regardless of whether they are running on primary or secondary servers.

Table 4.7. Services Discovered by SLPv2 in NetWare 6

SERVICE	DESCRIPTION
Nls.meter.novell	Ensures all network connections are licensed.
bindery.novell	Provides NetWare 6 file system access. (This service is not related to NetWare 3 bindery services.)
ndap.novell	Represents the eDirectory partition.
timesync.novell	Ensures time synchronization on the network.
portal.novell	Provides enterprise portals that allow access to secure network information through a web browser.
smdr.novell	Provides backup and restore services to NetWare 6 clients.

SLPv2 Architecture

SLP employs a relatively "flat" architecture. At its most basic level, SLP clients and servers communicate directly with each other and pass name resolution and service availability data. With eDirectory integration, SLP can use the power of a centralized Directory Agent to provide central distribution of network services and to improve bandwidth utilization on large, enterprise networks.

SLP uses three software agents to store information about services available on your TCP/IP network:

• User Agent (UA) A UA is present on every SLP client and server. UAs work on behalf of client applications to retrieve information about network services. By default, UAs query Service Agents (SA) for service location information. However, you can improve the sophistication of this architecture by configuring UAs to use a central Directory Agent (DA).

• Service Agent (SA) A SA is found on every network device that hosts a service. When a service is started or stopped, it communicates with the SA to register and de-register itself. UAs then query SAs to determine service availability and locations. Remember that SAs are primarily used on smaller networks because they employ multicast communications.

• Directory Agent (DA) A DA creates a catalog of available services by collecting information from multiple SAs. DAs avoid most of the multicast traffic associated with SAs by using unicasts. DAs create a level of centralized hierarchy and therefore allow SLP to scale in larger network environments.

As we learned earlier in this section, SLP works best when it is integrated with eDirectory. Furthermore, the flat architecture described earlier is inadequate for scalability and traffic management in large networks. Fortunately, SLP does support certain levels of hierarchy. This support is accomplished by organizing SLP services into groups called scopes.

The cool thing about SLP scopes is that they are integrated into eDirectory as manageable objects, and also then viewable in ConsoleOne. Creating these groups of services speeds up the access to requested services while reducing the number of packets on the wire. For example, some services may be regularly registered on machines in ACME's NORAD department and have no use to anyone outside that location. Thus, you could configure the DA on a server in the NORAD department with a specific scope for that container only. Then clients in the NORAD location will be configured with the IP address of the DA for that area.

SLPv1 and SLPv2 scopes are basically the same. However, they differ in one very significant way:

• SLPv1 default scope is UNSCOPED.

• SLPv2 default scope is DEFAULT.

The DEFAULT scope has no special properties and can be renamed according to the naming standards of the organization. There is one important caveat, however in SLPv2, DAs, SAs, and UAs cannot communicate with SLPv1 UNSCOPED scopes. Fortunately, the Novell implementation makes SLPv2 compatible with SLPv1 by ensuring that DAs, SAs, and UAs can all communicate with v1 and v2 scopes. The only requirement is that all SLPv1 scopes be given a name.

So how do SLPv2 DAs, UAs, and SAs communicate with each other? Let's take a closer look.

REAL WORLD

Although default SLPv1 scopes are called UNSCOPED, they are in fact a scope. The UNSCOPED scope is actually an unnamed scope that serves as a superset of all other scopes created in an eDirectory tree. As such, SLPv1 unnamed scopes cannot communicate with SLPv2 NAMED scopes. Furthermore, you cannot have a DA loaded with both an UNSCOPED scope and a NAMED scope at the same time. Sound confusing? Well, actually it all works out just fine as long as you name your SLPv1 and SLPv2 scopes.

SLPv2 Communications

SLP is basically a communication protocol in which DAs, UAs, and SAs communicate with each other to identify and locate available services on the network. However, the method of communication between these SLP Agents differs dramatically with small or large networks. Let's take a quick look at how SLPv2 communicates at both ends of the network spectrum.

Small Network: SLPv2 Communication Without a Directory Agent

A small network with fewer than 25 servers gains negligible advantage from an SLP DA. In this scenario, all SLP communication can be handled by the SAs and UAs with local segment IP multicast. Without a central DA, NetWare 6 Services register themselves with the SA running on their host server. Therefore, the SA knows about the services and can respond to specific client's requests.

Following is a step-by-step description of how SLPv2 communication operates in a small network (follow along in Figure 4.22):

1. The Novell Client running on a workstation makes a request through the client's UA for eDirectory authentication.

2. The client's UA sends a multicast request on the network.

3. All SAs within the UA's network segment receive the multicast.

4. Each SA that knows the location of the authentication service responds directly to the UA client with the IP address of the service. This communication is accomplished through a unicast because it is directed at a single client.

5. Each SA that is unaware of the location of the authentication service ignores the multicast and goes about its business.

Figure 4.22. SLPv2 communications without a Directory Agent.

Large Networks: SLPv2 Communications with a Directory Agent

In a large network, SLP requires DAs to provide scaling and remote connectivity support. If the network is architected to be a rather flat system, then a single DA may be sufficient. Unlike the smaller networks, there is little IP multicast in this architecture. Furthermore, DHCP can be used to configure each client UA with the IP address of the Directory Agent. This way DA information can be stored in eDirectory and replicated throughout the global network.

Following is the flow of SLPv2 communications with a Directory Agent (follow along with Figure 4.23):

1. A Novell client requests eDirectory authentication services through the workstation's UA.

2. The UA sends a unicast request directly to the DA that has been configured in its SLP settings.

3. Because all SAs send service location information to the DA, the DA responds to the UA with the IP address of the authentication service through a unicast.

Figure 4.23. SLPv2 communications with a Directory Agent.

In this section, we discovered a lot about Name Service Providers, SLPv2 architecture, and communications with or without Directory Agents. Now we will venture off the easy path into a much more sophisticated configuration lesson. Next, you will learn how to configure SLPv2 DAs, SAs, and UAs with NetWare 6's new and exciting Web management tool iManager.

And while you're at it, don't forget our new NetWare 6 motto: "iManage, therefore I am."