Novell's Implementation of SLP

The following sections discuss Novell's implementation of the Service Location Protocol specification.

Novell's User Agents and Service Agents

The Novell Client includes software for User Agents and Service Agents. The software is installed automatically during a client installation when one of the IP protocol options is chosen.

SLP must be available for the client to function and should preferred for use before other Service Name resolving methods (that is, eDirectory, SAP, and so on) by the client. Otherwise, changing most of the SLP configuration parameters will have no functional effect on a Workstation/UA since it is either not available or is not being used to resolve service names.

To configure the parameters, go to the Novell Client Configuration property pages (right-click Network Neighborhood or My Network Places > click Properties > click Services > click Novell Client for Windows NT > click Properties).

SLP Configuration Parameters

Service Location Tab

The following paragraphs describe the options found on the Service Location tab of the Novell Client for Windows NT.

Scope List: Defines what SLP scopes the UA will participate in. Controls 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.

Scope entries can be set in a precedence order by using the up- and down-arrows. Scopes can come from three different sources: Static, DHCP, and Dynamic. As with other SLP settings, Static scopes have a higher preference than DHCP scopes, and DHCP scopes have a higher preference than Dynamic scopes for locating services.

Table 117. Scope List Values

Default Value	List is empty.
Valid Values	Any entry will be accepted, but should match the scope name used with the SAs/DAs you want to communicate with.

Static: Checking the Static check box will prevent the client from dynamically adding scopes discovered from the known active DAs. The active DAs can be checked by executing the SLPINFO command. If the Static check box is not checked, then when the client discovers a DA that participates in a scope that was previously unknown to the client, the client will add the scope to its list in memory and can now query for SLP Services in that scope.

Table 118. Static Values

Default Value	Unmarked (Off)
Valid Values	Marked/Unmarked (On/Off)

Directory Agent List: This parameter controls what DAs a client is statically configured to communicate with. This is not necessarily a complete list of the DAs the client is aware of. You must use SLPINFO with the /D command to be sure of what DAs the client has discovered and their status (Active/Inactive).

Table 119. Directory Agent List Values

Default Value	Empty
Valid Values	Any IP address or DNS-resolvable host name for a NetWare server running SLPDA.NLM

Static: Checking this check box will prevent dynamic DA discovery and only use DAs discovered using the Static or DHCP method.

The UA will not send an initial DA multicast requesting a response from all DAs that can hear the request.

Any DA that multicasts a DA Advertisement (DA_ADVERT) will be ignored. Normally the UA will add any DA that does a DA Advertisement. DAs Advertise when they are first loaded and also periodically based on the Heartbeat parameter.

Table 120. Static Values

Default Value	Unmarked
Valid Values	Marked/Unmarked (On/Off)

Active Discovery: Unchecking this check box requires that the UA contact a DA for an SLP Request. The UA will not multicast the request to SAs. The combination of Static enabled and Active Discovery disabled will entirely prevent the UA from multicasting. Once this setting is disabled, you are required to put at least one entry in the Directory Agent List; otherwise, the UA has no method for querying for SLP services.

Table 121. Active Discovery Values

Default Value	Marked (On)
Valid Values	Marked/Unmarked (On/Off)

Advanced Settings Tab

The following paragraphs describe the options found on the Service Location tab of the Novell Client for Windows NT.

Give Up on Requests to SAs: Timeout in seconds for an SLP Request to an SA. This parameter is not used to time out requests to DAs. There is a separate setting for this.

Table 122. Give Up on Requests to SAs Values

Default Value	15
Valid Values	1 - 60,000 seconds (16.67 hours)

SLP Cache Replies: Every time the UA receives an SLP Service reply from a DA/SA, it will be cached/saved at the UA for the amount of time specified in the SLP Cache Replies parameter. When SLP receives a request it will first check its cache before generating a network packet to a DA/SA. If the cached information can be used to answer the request, it will be. It is not recommended to set the time higher than one minute under normal SLP operations for the following reasons:

During normal SLP communication, duplicate requests should occur within one minute of the original request, making longer caching unnecessary.

The higher the setting, the more memory will potentially be required to cache this information.

Table 123. SLP Cache Replies Values

Default Value	1 minute
Valid Values	1 - 60 minutes

SLP Default Registration Lifetime: This parameter determines the registration lifetime of an SLP Service when an SA registers an SLP Service to a DA. The Novell Client not only includes the UA capabilities, but also the SA capabilities (the same as a server), so it is possible for a client workstation to be registering SLP services with a DA. However, it is unusual for a client workstation to be registering an SLP Service as an SA. Developers can write applications that register SLP Services from a client workstation using the WINSOCK 2 interface. Examples of cases where a client workstation would register an SLP service include:

An NT Domain Controller running NDS4NT and a local eDirectory replica.

A Client workstation running the Compatibility Mode client (CMD) where the workstation is advertising a SAP (for example, 0x0640). CMD will convert the SAP to SLP and register it with any DAs the client has discovered.

Where a third-party application is using WINSOCK to intentionally register an SLP Service.

When the Registration Lifetime of an SLP Service expires, the DAs it is registered with will remove this entry from its database. This is also used to determine when an SA (on a workstation or a server) needs to re-register a service with its DAs.

Table 124. SLP Default Registration Lifetime Values

Default Value	10,800 seconds
Valid Values	60 - 60,000 seconds

SLP Maximum Transmission Unit: Exactly the same as the TCP/IP MTU, which is the maximum size that an SLP packet can have. This setting is used to restrict the size of the SLP packets so that it does not exceed the capability of the infrastructure and does prevent resource-intensive packet fragmenting and reassembly.

Table 125. SLP Maximum Transmission Unit Values

Default Value	1,400 bytes
Valid Values	576 - 4,096 bytes

SLP Multicast Radius: This parameter specifies the maximum number of subnets (number of routers plus 1) that SLPs multicasts can travel across. A value of 1 prevents multicasting from crossing any router. This is implemented in the Time To Live (TTL) setting of the UDP/TCP packet.

TTL is decremented by one of two conditions:

The packet crosses a router.

The packet is buffered in a router for more than 1 second.

Table 126. SLP Multicast Radius Values

Default Value	32 hops
Valid Values	1 - 32 hops

Use Broadcast for SLP Multicast: This parameter forces the SLP UA to use broadcast (all bits turned on in the Host ID portion of the address) where it would have normally used multicast.

This has the following different behaviors from multicast:

Broadcast will not cross a router, so this limits the packet to the originating subnet.

It might cause additional bandwidth usage because the packet will now need to be repeated from every switch port. Some switches are capable of tracking multicast registrations and would only forward a multicast packet from the switch ports that are registered for that multicast address.

Table 127. Use Broadcast for SLP Multicast Values

Default Value	Off
Valid Values	On/Off

Use DHCP for SLP: This parameter determines whether the SLP UA will attempt to locate a DHCP server that can provide SLP Scope and DA configuration information. Even if the workstation's IP address is statically configured, SLP can still receive an SLP Scope and DA configuration from a DHCP server. The DHCP requests for SLP information are sent only as part of the SLP UA/SA initialization. SLP information is requested using the DHCP INFORM request and is sent in addition to the initial BOOTP Request (if the client is configured to obtain its IP address via DHCP/BOOTP). All SLP DHCP response information is combined, then SLP contacts each DA that has been configured by DHCP to determine the scopes supported by each DA.

Administrators who plan to never use DHCP to administer SLP information should set this parameter to Off to reduce the minimal traffic the broadcast for a DHCP server will require.

Table 128. Use DHCP for SLP Values

Default Value	On
Valid Values	On/Off

Wait Before Giving Up on DA: Timeout in seconds for an SLP Request to a DA. This parameter is not used to time out requests to SAs. There is a separate setting for this.

Table 129. Wait Before Giving Up on DA Values

Default Value	5
Valid Values	1 - 60,000

Wait Before Registering on Passive DA: If an SA running on the workstation receives an unsolicited DA Advertisement (that is, either the DA just started or the DA issued a heartbeat), the SA will need to register whatever services it offers. This parameter is used to specify a range that the SAs will attempt to register their services to prevent the SAs on a network from all attempting to register with the DA at the same time. As mentioned earlier, the client workstation may need to use SLP to advertise Services it provides. This is unusual, but it may change in the future as applications begin to take advantage of this new advertising method.

Table 130. Wait Before Registering on Passive DA Values

Default Value	2 seconds
Valid Values	1 - 60,000 seconds

The Novell Directory Agent

The Service Location Protocol (SLP) Directory Agents support SLP 1. Enhanced features let network administrators better control the collection and dissemination of network service information through SLP.

Table 131. Directory Agent Features

Feature	Description	NetWare	Windows NT/2000
Directory-enabled operation	Directory mode uses eDirectory to store SLP service information.This leverages existing eDirectory standards for configuring eDirectory tree structures, for a central point of administration, and for the ability of eDirectory to replicate service information. eDirectory replication services allow Directory Agent-to-Directory Agent communication. This is unique in SLP implementations and it facilitates global distribution of SLP database information. eDirectory replica services give the Directory Agent the ability to access global services from a local replica. In Directory mode, you use ConsoleOne.	X	X
Local mode	Standalone operation. The SLP Directory Agent operates without using eDirectory. This lets network administrators use SLP Directory Agents in network segments that need the performance but don't need to share the service information globally (Windows NT Directory Agent Only). Use the SLP Directory Agent property pages on the Windows NT or Windows 2000 computer. For more information, see Managing Properties for Local Mode.		X
Private mode	When operating in Private mode, the SLP Directory Agent only accepts SLP service registrations and requests from SLP agents configured with the SLP Directory Agent's IP address. In Private mode, the SLP Directory Agent does not multicast its presence on the network and does not answer multicast requests. For more information, see Setting Up Private Mode.		X
Proxy scope support	The SLP Directory Agent acts as proxy for scopes hosted by other SLP Directory Agents. This lets network administrators distribute service information from other SLP scopes, usually not visible to a local network segment, without having to enable network directory support. For more information, see Setting Up a Proxy Scope.		X
Service filtering support	The SLP Directory Agent can be configured with service filters that control the service information to and from SLP agents in the network. Additional filters can control the SLP service information that is stored in the network directory for global distribution. These filters provide single-point administration of the services made available through the SLP (Windows NT/2000 Directory Agent only). For more information, see Setting Up Scope Filters .	X	X

Using the Novell Windows NT Directory Agent

Scopes

In SLP, a scope is simply a list of SLP services that have been registered with a Directory Agent.

Using Scopes in Directory Mode

In Directory mode, when a Directory Agent is created, it registers the SLP Scope Unit container object, which is the actual storage container for SLP service information. Each Scope Unit container holds all the SLP Service objects for a specific scope. You can replicate this container into other partitions within the tree or within federated trees.

As mentioned earlier, the Scope Unit has an attribute called the Scope Name. This Scope Name is used by the Service Agent and User Agent to define what scopes they are to work with. SLP scopes allow network administrators to organize SLP services into groups. The Service Agent determines into which groupings the services on that the server will be registered. By default, all SLP services are registered in the unscoped scope. When clients send SLP requests to a Directory Agent, they can specify a scope for the Directory Agent to use in order to find the service they are looking for. If no scope is specified by the client, the Directory Agent will look in the Unscoped table to find the requested service.

A Directory Agent can service multiple scopes and a Service Agent can register services in multiple scopes. The registered services can be replicated between sites by using eDirectory.

Using Scopes in Local Mode

Scopes configured in Local mode operate similarly to scopes configured for Directory mode with the exception that the scopes are stored locally instead of in eDirectory. By default, all SLP services are registered in the unscoped scope. We recommend that you configure at least one scope.

For more information about configuring scopes in Local mode, see Adding a New Scope.

Using Scopes to Handle the 64 KB Limitation Issue

A total of 64 KB of data is all the Directory Agent can send to the client via a TCP connection. If there is more than 64KB of a certain service type, the list will be cut short. The reason for this is that in SLP 1, the length field in the SLP response packet header is only 16 bits, allowing up to 64 KB of service data.

Table 132 lists the common service types that fit into a 64 KB response packet.

Table 132. Common Service Types

Service	Number per Response Packet
NDAP.Novell	About 1,200, depending on the length of the partition names
Bindery.Novell	700 - 1,100, depending on the length of the server names
MGW.Novell	About 1,200
SapSrv.Novell	No more than 540

Understanding Scope Filtering

SLP uses scopes to logically group services according to administration, usage, or service type criteria. By dictating the scopes that SLP User Agents and Service Agents participate in, you can control the service information users see. Unfortunately, that level of control is not sufficient for large and sophisticated network environments. To give you better control over the collection and distribution of service information, use the additional filtering capabilities provided as part of the SLP Directory Agent configuration and management tools.

When administering scopes, you can configure registration, response, and directory filters for each scope.

Registration filters restrict or control the service information that is accepted and stored by the Directory Agent for a given scope.

Response filters restrict or control the service information that is returned to specific users or groups of users.

Directory filters control whether the service information that is registered with the Directory Agent (subject to the registration filters) is also stored in the corresponding Scope Unit container object.

The Registration, Response, and Directory filters are configured on a per-scope basis. This lets you separately control the type of information stored in each scope.

Filtering

The SLP Directory Agent can be configured with service filters that control the service information to and from SLP agents in the network. Additional filters can control the SLP service information that is stored in the network directory for global distribution. These filters provide single-point administration of the services made available through SLP (Windows NT/2000 Directory Agent only).

Using INCLUDE and EXCLUDE Filters

Registration, response, and directory filters are specified using the INCLUDE and EXCLUDE filter directives.

The INCLUDE filter directive specifies criteria that the service registration or request must comply with to store or retrieve service information in the specified scope.

The EXCLUDE filter directive specifies criteria that prohibit any compliant service registration or request from occurring for the specified scope.

The filters associated with a scope consist of one or more INCLUDE and EXCLUDE filter directives. For a service registration or request to be processed, it must match at least one INCLUDE filter directive and not match any EXCLUDE filter directives configured for the scope. If any INCLUDE directives are configured, only service registrations and requests matching at least one INCLUDE directive are processed; all others are denied. If no INCLUDE directives are configured, all service registrations and requests are processed subject to any EXCLUDE filter directives.

The criteria for an INCLUDE or EXCLUDE filter directive are specified by one or more filter operations. Filter operations allow the administrator to filter the type of service, the specific service URLs, a service registration's lifetime, or the address of the sending or requesting host in the network. If you specify multiple filter operations in a single filter directive, all filter operations must evaluate to TRUE for the filter directive to be TRUE. Only one of each type of filter operation can be included in a single filter directive.

If the IP address of the sending or requesting host is used as filter criteria, it is specified in dotted decimal notation (for example, 137.65.143.195). Subnet masks can be associated with an IP address by appending a slash (/) followed by the subnet mask. The subnet mask can be specified using either dotted decimal notation or by specifying the number of contiguous bits that constitute the mask (for example, 137.65.143.0/255.255.252.0 and 137.65.143.0/22 are equivalent). If a subnet mask is specified, the mask will be applied to both the address specified in the ADDRESS filter operation and the host IP address being checked before any filter evaluations are made.

Filter Syntax

The ABNF (RFC 2234) for the registration, response, and directory filters is defined below:

Registration Filter = 1*(include_directive / exclude_directive) Response Filter = 1*(include_directive / exclude_directive) Directory Filter = 1*(include_directive / exclude_directive) include_directive ="INCLUDE("filter_operation")" exclude_directive = "EXCLUDE("filter_operation")" filter_operation = [address_operation] [type_operation] [lifetime_operation] [url_operation] address_operation = "(ADDRESS" equality_operator *1( ipv4_number / ipv4_number "/" subnet_mask )")" lifetime_operation = "(LIFETIME" filter_operator seconds")" type_operation = "(TYPE" equality_operator [wild] service_type [wild]")" url_operation = "(URL" equality_operator [wild] service_url [wild]")" service_url = service: URL as defined by RFC 2609 service_type = abstract-type ":" url_scheme / concrete-type abstract_type = type_name ["." naming_auth] concrete_type = protocol ["." naming_auth] type_name = resname naming_auth = resname protocol = resname url-scheme = resname wild = "*" reserved = "(" / ")" / "*" / "\" escaped = "\" reserved resname = ALPHA [1*(ALPHA / DIGIT / "+" / "-" )] ipv4_number = 1*3DIGIT 3("." 1*3DIGIT) subnet_mask = ipv4_number / 1-32 equality_operator = "==" | "!=" filter_operator = "==" / "!=" / ">" / "<" seconds = 1-65535

Examples of INCLUDE and EXCLUDE Filter Directives

Below are examples of INCLUDE and EXCLUDE filter directives to help you understand how to implement the filter feature.

Registration Filters

Allow only services of types ndap.novell or bindery.novell with a lifetime greater than 5,000 seconds from servers on the 137.65.140.0 subnet to be stored by the SLP Directory Agent. The ADDRESS operation values for both INCLUDE directives are equivalent. The first registration filter uses dotted decimal notation for the subnet address and the second registration filter specifies the number of bits in the subnet mask.

INCLUDE((TYPE == ndap.novell)(ADDRESS == 137.65.140.0/255.255.252.0)) INCLUDE((TYPE == bindery.novell)(ADDRESS == 137.65.140.0/22)) EXCLUDE ((LIFETIME < 5000))

Response Filters
Prevent only workstations on the 137.65.140.0 subnet (except the workstation with IP address 137.65.143.155) from accessing information held by the SLP Directory Agent.

INCLUDE((ADDRESS == 137.65.140.0/255.255.252.0)) EXCLUDE((ADDRESS == 137.65.143.155))

Directory Filters
The first two directory filters allow only services of types ndap.novell and bindery.novell to be stored in the Scope Unit container object associated with this scope. The second two directory filters allow only services with the URLs specified to be stored in the Scope Unit container object associated with this scope.

INCLUDE((TYPE == ndap.novell)) INCLUDE (TYPE == bindery.novell))

or

INCLUDE((URL == service:ndap.novell:///GLOBAL_PARTITION1.CORP_TREE.)) INCLUDE (URL == service:ndap.novell:///GLOBAL_PARTITION2.CORP_TREE))

When the Directory Agent is operating in Local mode, the registration, response, and directory filters are stored in the local system's registry and are persistent across system boots.

When the Directory Agent is operating in Directory mode, the registration, response, and directory filters are stored as part of the Scope Unit directory object defining the filtered scope. The Scope Unit object has a Registration Filters, Response Filters, and Directory Filters attribute. These attributes are multi-valued of type SYN_CI_STRING. Each INCLUDE and EXCLUDE filter directive is stored as a separate string in the Registration Filters, Response Filters, or Directory Filters attribute.

Using the Service Location Protocol Directory Agent

The following scenarios show some of the many options for deploying SLP.

Scenario 1: Remote Site with a Mixed NetWare and Windows NT Environment

Scenario 2: Remote Office with Windows NT Servers Only

Scenario 3: Using the Directory Agent for a Small Group of Users

Scenario 4: Restricting SLP Information

Scenario 5: Synchronizing SLP Information Over a WAN Link

Scenario 6: Replicating SLP Information to a Remote Site

Scenario 7: Running a Directory Agent in Local Mode

Scenario 8: Using the Proxy Feature

Scenario 1: Remote Site with a Mixed NetWare and Windows NT Environment

Problem: A remote office is running NT servers and NetWare clients with no NetWare servers. The administrator wants the clients to see all the network services from a local server, avoiding sending on-demand service queries over the slow link.

Solution: The Directory Agent can be installed on a Windows NT server to allow the clients to see all the network services from a local server without causing on-demand traffic over the slow link.

Scenario 2: Remote Office with Windows NT Servers Only

Problem: A remote office is running NT servers, and the administrator wants local clients to see only a limited set of services.

Solution: Use the new Directory Agent and its filter or proxy capabilities to configure the Directory Agent to only see a specific set of services.

Scenario 3: Using the Directory Agent for a Small Group of Users

Problem: An administrator wants to configure a Directory Agent for a group of users and wants that Directory Agent to manage only a small subset of services, not all SLP services on the network.

Solution: The administrator defines exactly which services are allowed to register with that Directory Agent. Then, by statically assigning the Directory Agent's address to those users, the administrator controls which services are seen by those users.

Scenario 4: Restricting SLP Information

Problem: An administrator wants to restrict the users who can query SLP information from a Directory Agent.

Solution: Set the filters on the Directory Agent for Windows NT to define who can obtain information from the Directory Agent. This identification is determined by the IP address.

Scenario 5: Synchronizing SLP Information Over a WAN Link

Problem: An administrator wants to synchronize SLP service information over a WAN link, but one side of the link uses eDirectory without any NetWare servers.

Solution: Run the Directory Agent on a Windows NT server and configure the Directory Agent to service the eDirectory scope containers included in the network eDirectory replication design.

Scenario 6: Replicating SLP Information to a Remote Site

Problem: An administrator wants to replicate SLP service data to a remote site without using eDirectory as the replication method.

Solution: The Directory Agent is installed on a Windows NT server at the remote site and is configured to proxy the data in another Directory Agent's scope. The Directory Agent scope that contains the original service information is known as the Scope Authority. The Directory Agent at the remote site is configured to look at a Scope Authority and can replicate the data to the remote site by using standard SLP requests to the Directory Agent.

Scenario 7: Running a Directory Agent in Local Mode

Problem: An administrator needs SLP on the network to find printers and other services. The administrator needs a Directory Agent to handle unicast requests since multicast packets are disabled on the network, and unicast is more efficient in bandwidth use.

Solution: Run the Directory Agent for Windows NT in a Local mode of operation. The services are only stored in memory and not in a Directory Service. This means that the Directory Agent can be run on Windows NT without the Novell Client or eDirectory.

Scenario 8: Using the Proxy Feature

Problem: An administrator of a development group notices that services are going up and down. The administrator wants a more active method of making sure the service information in SLP is accurate instead of relying on the default service lifetime protocol.

Solution: Use the proxy feature in the Directory Agent for Windows NT to configure the Directory Agent to poll another Directory Agent or Service Agents's scope. Configure the Directory Agent with Service Agent IP addresses as the Scope Authorities. This causes the Directory Agent to poll each Service Agent at a configured interval, querying for all active services.