[an error occurred while processing this directive]
|
| Deploying SLP |
|
| Deployment Guide |
|
|
||||||
|
||||||
|
||||||
|
||||||
|
 |
Deploying SLP As A Secondary Name-To-Address Resolution Mechanism to DNS |  |
 |
|
|||
|
|
|
|
| There are two technologies involved in connecting users up to the network services they need-name-to-address resolution and dynamic service discovery. Name-to-address resolution eliminates the need to know the network IP address of a service in order to access the service, greatly simplifying network usage. Dynamic service discovery, on the other hand, provides users with a list of services that meet the characteristics that users specify. For example, a user might ask for all the simple mail transfer protocol (SMTP) servers on a particular floor of a building. Dynamic service discovery can be either of two types, ad-hoc or assisted. Name-to-address resolution and dynamic service discovery technologies are coming together. Technologies originally designed to accomplish name-to-address resolution are being extended to perform dynamic service discovery functions, and dynamic service discovery techniques are being used to perform name-to-address resolution. This merging of technologies is causing confusion among network services developers and network administrators in deciding which technologies to use to accomplish name-to-address resolution and service discovery. This document is intended to help clear up the confusion with recommendations as to which technologies to use to perform these tasks. |
|||
|
|||
|
Choosing The Right Tool | |
|
|
|||
|
|
|
|
| Domain Name Services (DNS) and Service Location Protocol (SLP) are both name-to-address resolution technologies. Whether you use DNS, SLP, or some other technology depends on the specific task at hand. In making the choice, it is helpful to separate the tasks dealing with name-to-address resolution from those dealing with dynamic service discovery. The following sections discuss recommendations for implementing name-to-address resolution, ad-hoc service discovery and assisted service discovery. Name-to-Address Resolution Users invoke name-to-address resolution technologies when they know the name of a service they wish to use but do not know the network address of that service. Name-to-address resolution is the primary purpose of DNS; however, a number of other technologies are also used today to determine a network address from its name. These technologies include Novell® Directory Services® (NDS®), host files, SLP and Dynamic Host Configuration Protocol (DHCP). DNS has several important advantages:
In addition, all the basic infrastructure and services offered by Novell products are fully functional when DNS is used as the name-to-address resolution mechanism. However, DNS has two inherent disadvantages:
SLP on the other hand provides:
However, SLP has a disadvantage:
As a result, Novell recommends using DNS as the primary name-to-address resolution mechanism and SLP as a secondary name-to-address resolution mechanism. Novell also recommends not propagating SLP data between remote sites if it can be avoided. That's because using remote SLP information can lower reliability and predictability in the system, and it may generate unnecessary traffic between remote sites. For Ad-Hoc Service Discovery Ad-hoc service discovery permits users to find services on the network with little or no prior configuration required. A service advertises its presence on the network allowing users to discover that service without having prior knowledge of it and without administrator intervention. Examples of technologies that support ad-hoc service discovery are SLP, Service Advertising Protocol (SAP), Jini, Salutations and Simple Service Discovery Protocol (SSDP). Novell recommends SLP as the primary ad-hoc service discovery mechanism for IP networks. SLP is particularly effective when used to discover services that are in close proximity to the requesting user. Novell recommends that SLP-based advertising be confined to operate within limited geographical areas, that is, you should not replicate SLP information across remote sites. For sites with large numbers of advertising entities, you should deploy an SLP Directory Agent (DA) to improve the efficiency of handling SLP requests. You may also deploy a second SLP DA at a site to provide fault tolerance. Using SLP for ad-hoc service discovery has two advantages:
SLP does, however, have two disadvantages:
For Assisted Service Discovery Assisted service discovery requires network administrators to perform some kind of setup to enable users to find services. With their understanding of how users search for certain services, network administrators can configure the service information to facilitate searches. This logical organization of service data by administrators enables users to discover-reliably and easily-the services available to them both locally and globally. Technologies used to support assisted service discovery include NDS, DNS and Web pages. NDS eDirectory provides powerful search capabilities. NDS trees constructed with logical or geographical organization are particularly well suited for searches. Network administrators can improve the quality of searches by populating NDS objects' attributes with meaningful information, such as the objects' "location" attribute. The Web is also well suited for global searches. Most users are familiar with the different search engines available on the Web and the processes required to advertise sites. An important advantage of the Web is that it offers network administrators great flexibility in configuring Web pages to guide users through customized searches. Location-based service discovery though the Web is an example of using the Web for assisted service discovery. Assisted service discovery mechanisms provide three major advantages:
These techniques, however, all have
|
|||
|
|||
|
Guidelines For NetWare Developers | |
|
|
|||
|
|
|
|
This section provides guidelines
for developers who are developing NetWare services in implementing
name-to-address resolution and service discovery mechanisms. The
intent of these guidelines is to NetWare Must Not Require SLP for Full Functionality All the basic NetWare infrastructure and services, such as storage, printing and NDS, must be fully functional when SLP is not available on the network. This requires that developers develop services without hard dependencies on SLP for name-to-address resolution or service discovery. The services should rely solely on DNS for name-to-address resolution. With respect to service discovery, services should employ secondary discovery mechanisms, or at least allow for manual configuration and thus enable a gentle reduction of functionality. Use Winsock To Access Name-To-Address Resolution and Service Discovery Functionality Winsock supports APIs to access name-to-address resolution and service discovery functionality. Developers of NetWare services and components should use Winsock to implement name-to-address resolution and service discovery functionality. Novell Will Support SLPv2 SLPv2 is a significant improvement from the first version of the SLP specification. As a result, Novell will provide a fully compliant SLPv2 implementation in NetWare 6 and closely follow future protocol enhancements. |
|||
|
|||
|
Guidelines For Network Administrators | |
|
|
|||
|
|
|
|
This section offers some implementation
guidelines to assist network administrators in setting up Use SLP for Local Ad-Hoc Service Discovery SLP is well suited for local ad-hoc service discovery, but in setting up SLP remember that Novell recommends that SLP data not be propagated to remote sites. Network administrators can ensure conformance to this recommendation by configuring the appropriate routers to disallow SLP multicast traffic outside their geographic locations. Constraining SLP traffic in this manner eliminates the need to manage SLP scopes in most cases. One or more DAs can be deployed at large sites to improve the response time of SLP queries. The nature of the applications running in some environments, however, may require that SLP information be shared across remote sites. As a result, Novell will continue to support the tools to enable and manage these exceptional environments. In these cases, however, network administrators should evaluate whether it is more prudent to make an exception to the local propagation constraint recommendation or to upgrade the applications in the environment to eliminate SLP dependencies. Configure Name-to-Address Resolution List Network administrators may choose one or more mechanisms to perform name-to-address resolution and ad-hoc service discovery in their environments. They should configure all clients and servers to use the same mechanisms and in the same order. Based on which mechanisms they choose, network administrators should instruct users in when to use long DNS names and when to use short SLP names. For example, administrators could instruct users to use long DNS names when trying to communicate with services located in remote locations and to use short SLP names for services that are located locally. Helpful documentation
|
|||
|
|||
|
Additional Information | |
|
|
|||
|
|
|
|
For additional information on day-to-day management of Novell NetWare, product features, Q&A, etc. please see the following links:
© Copyright 2001. Novell, Inc. All rights reserved. Novell, the Novell logo, NetWare, Novell Directory Services and NDS are registered trademarks of Novell, Inc. in the United States and other countries. |
|||
|
|||
