Network Services Location Manager Network administrator's guide
This document describes the Network Services Location Manager and tells you how to set up your network to take advantage of it. You should read this document if you are a network administrator or are responsible for setting up or managing network services.
What Is the NSL Manager?
The Network Services Location (NSL) Manager is software that allows applications to advertise and search for network services. In the past, there was no easy way to nd services on a TCP/IP network unless the network administrator identied or listed those services in some way. For example, an administrator might put links to public Web sites on a home page, or let users know about private servers by word of mouth.
The NSL Manager now provides both a way for network services to advertise themselves and a way for applications that require network services to find them automatically. When asked to locate network services by an application, the NSL Manager can use several different protocols to quickly search for and provide a list of available services. The search takes place with a minimum of network traffic. Located services are grouped into network "neighborhoods" based on the network segment in which the services are found and the service location protocols operating in that segment, as represented by NSL plug-ins.
What Computers Have the NSL Manager?
The NSL Manager is available on all computers with a PowerPCTM microprocessor and Mac OS 8.5 (or later) installed. To make sure all the computers on your network can take advantage of the NSL Manager's service advertising and search capabilities, see the section "Setting Up Your Network to Work With the NSL Manager," later in this document.
About NSL Plug-Ins
When the NSL Manager receives a request to advertise or locate a network service, it passes it on to an NSL plug-in that performs the actual registration or search. An NSL plug-in is an extension that makes itself available to the NSL Manager when the NSL Manager is initialized, but resides in memory only when it is responding to a request. You can use the Extensions Manager to enable and disable individual NSL plug-ins.
When the NSL Manager is initialized, each NSL plug-in provides it with the following information: the types of services the plug-in can search for, such as HTTP and FTP; and the protocol the plug-in uses to conduct searches, such as DNS or LDAP.
With Mac OS 9, NSL Manager version 1.1 is accompanied by four plug-ins: Domain Name Service (DNS), Service Location Protocol (SLP), Lightweight Directory Access Protocol (LDAP), and Name Binding Protocol (NBP). Additional NSL plug-ins may become available from Apple Computer, Inc. or third-party developers.
Setting Up Your Network to Work With the NSL Manager
The way you set up your network can affect which services the NSL plug-ins can locate, so you may need to make adjustments to allow hosts to find specific network services. Read the following sections for more information.
Setting Up for DNS Searches
In order for the DNS plug-in to access information about network services, your DNS server must be configured to allow anyone to request and receive zone transfers.
To make network services available to the NSL Manager through the DNS plug-in, you need to manually add text records for network services to the DNS server. The format of the records is as follows:
<hostname> <TTL> TXT <URL>
The following table explains each element of the record.
Field | Contents |
<hostname> | The name of the host being referenced |
<TTL> | The time-to-live for this information |
<URL> | The complete URL for this host (for example, http://www.apple.com/) |
If you use more than one DNS server, make sure you add records for a particular host name to the server responsible for that host and add the names of these servers to the search domain lists in clients' TCP/IP configurations.
Setting Up for SLP Searches and Registrations
The NSL Manager uses the SLP plug-in to find and advertise network services using the Service Location Protocol.
Network services running on the Mac OS can use the NSL SLP plug-in to advertise their availability. (File sharing and Personal Web Sharing, for example, use SLP registration.) SLP service agents are created on the host computer by the SLP plug-in, then these service agents listen for NSL search requests and respond appropriately. On networks that include an SLP Directory Agent (DA) server, the SLP service agents register their services with the DA. NSL search requests are then made directly to the DA, thereby reducing network traffic. (Most of this traffic is on the local subnet.)
For SLP registration and discovery to take place, the advertising and searching hosts must be running the same version of the SLP plug-in. Services advertised by version 1.0 of the plug-in cannot be found by hosts running version 1.1. Similarly, services advertised by version 1.1 of the plug-in cannot be found by hosts running version 1.0.
To register or discover services outside the local subnet, IP Multicast Router capability must be enabled. Note that MacIP does not support multicasting. When advertising a service, the SLP plug-in follows these steps to decide which network neighborhood (SLP scope) to register the service in:
- If the registering application or service specifies a network neighborhood, the SLP plug-in registers the service in that neighborhood.
- If no neighborhood is provided by the registering application or service, the SLP plug-in registers the service in the first domain listed in the Search Domains list of the host's TCP/ IP settings.
- If no search domain is specified in the host's TCP/IP settings, the plug-in tries to derive a neighborhood from the domain of the service's URL. For example, a service with the URL http://me.mydomain.com would be registered in the neighborhood mydomain.com and http://me.sub.mydomain.com would be registered under sub.mydomain.com.
- If none of these steps yields a neighborhood, the plug-in registers the service in the "default" SLP scope, which is listed as the "Local Services" neighborhood (or the localized equivalent).
Setting Up for LDAP Searches
The LDAP plug-in always searches the LDAP server and associated searchbase specified in the LDAP Services fields in the Hosts settings on the Advanced tab of the Internet control panel. Services discovered in this default directory are listed in a neighborhood that has the same name as the LDAP server.
Applications and users can request the plug-in to search additional LDAP directories. Using the Network Browser, for example, a user can browse an LDAP directory by adding a neighborhood that has the same name as the server, in this form:
<servername>%2f<searchbase> (ldap.domain.com%2fc=us, for example)
Note: Choosing an item from the Favorites list in the Network Browser causes all active NSL plug-ins to perform a search. So, when a user chooses an LDAP server from the Favorites list, the DNS plug-in might also respond, generating a "nameserver not responding" message. If DNS browsing is not needed, the user can disable the DNS plug-in using the Extensions Manager control panel.
If a user adds an LDAP neighborhood without including a searchbase in the name, the LDAP plug-in makes two attempts to get data from the server. First, it tries to access the directory without specifying a searchbase. (Version 3 LDAP servers can return data when no searchbase is provided.) If that fails, the plug-in tries again using a searchbase of c=us. For example, if a user adds a neighborhood named ldap.mydomain.com, the plug-in tries these searches:
- ldap://ldap.mydomain.com
- ldap://ldap.mydomain.com/c=us
When you set up an LDAP directory to advertise services to NSL, keep these points in mind:
- The plug-in looks for service URLs (afp://asip.mydomain.com, or http://www.mydomain.com, for example) in both labeleduri and url attributes. For best results, use the labeleduri attribute. See RFC 2079 for more information.
- The directory tree is displayed using distinguished names. When possible, use attributes and names that are easy for a user to interpret, like cn=Joe Smith, rather than less revealing names like userID=123456789.
- If practical, you can improve performance and readability by organizing the directory tree so that service lists contain fewer than 200 entries. The searchbase can, for example, be restructured as
service=printers, ou=HumanitiesBldg, o=school
service=printers, ou=ScienceBldg, o=school
service=printers, ou=AdminBldg, o=school
- You can create a separate branch in the directory specifically for NSL browsing (for example, ldap.mydomain.com/ou=nsl,c=us).
Setting Up for NBP Searches
If AppleTalk is active on a host, AppleTalk zones and AppleShare servers on the network are listed in the neighborhood named "AppleTalk." Security Issues The NSL Manager makes network services that were once difficult to find more readily available to network users. It does not, however, make sites less secure; it just makes it easier for clients to find services that were already available.
If you use DNS to list your intranet's services, you control which services clients can discover through NSL searches. However, any network services that utilize SLP registration are discoverable by the NSL Manager.
For More Information
For more information, see the following sources:
Request for Comments (RFC) Documents Service Location Protocol, RFC #2165
Service Location Protocol, Version 2, RFC #2608
Lightweight Directory Access Protocol, RFC #1777
You can find RFC documents at the following Web address:
Books and Articles
DNS and Bind by Paul Albitz and Cricket Liu, O'Reilly & Associates, Inc. 1994
Inside Macintosh: Networking, Chapter 3, "Name Binding Protocol," viewable at
http://developer.apple.com/techpubs/mac/Networking/Networking-61.html
SLP White Paper, at
http://playground.sun.com/srvloc/slp_white_paper.html
© 1999 Apple Computer, Inc. All rights reserved. Apple, the Apple logo, AppleShare, AppleTalk, Mac, and Macintosh are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. Extensions Manager is a trademark of Apple Computer, Inc. PowerPC is a trademark of International Business Machines Corporation, used under license therefrom.