The Service Location Protocol and the Macintosh
Open Door Networks, Inc.
September, 1999

Overview: The Service Location Protocol (SLP) is an emerging Internet standard for automatic resource discovery on Internet Protocol (IP) networks. SLP work was initiated by Apple Computer in the late 1980's. As usual, Apple was a bit ahead of its time, and the work languished for years. The recent explosion of interest in the Internet, coupled with the migration of organizations' internal networks (intranets) to IP has rekindled interest in the protocol, which attempts to bring AppleTalk's point-and-click service location features to IP networks.

SLP is used by Open Door Networks' ShareWay IP and AFP Engage! products to provide dynamic browsing and point-and-click access to Macintosh file sharing servers over IP. It is also used by Mac OS 9's IP File Sharing, Network Browser and Navigation Services. Apple's inclusion of SLP in the Mac OS continues the momentum that is building behind the protocol. As with any new protocol, however, limitations and issues exist which will need to be addressed as the protocol, its implementations, and the products that use it mature.

SLP objectives: According to the SLP specification (RFC 2608), SLP "provides a scalable framework for the discovery and selection of network services" and "eliminates the need for a user to know the name of a network host supporting a service." To those familiar with AppleTalk and the Chooser, another way of stating this objective is "to enable the creation of a Chooser-like application which works with Internet rather than AppleTalk protocols" and thus to help maintain AppleTalk's ease of use as Macintosh networks migrate from AppleTalk to IP.

SLP history: The Macintosh's native networking system, AppleTalk, was designed with the Macintosh's principal focus in mind: the end user. Specifically, Apple built a dynamic naming and service location system into AppleTalk. Through the Name Binding Protocol (NBP), services could dynamically register on the network. And through the Macintosh Chooser and equivalent third-party functionality, such services could be browsed for and accessed through Macintosh-standard point-and-click technology.

In the mid 1980s, due mainly to the Mac's success in university environments, Apple realized that a Macintosh implementation of the TCP/IP protocol suite was needed. TCP/IP, designed by and for the research community, had functionality and scalability as its principal goals and paid little attention to ease-of-use. As Apple began implementing and distributing TCP/IP on the Macintosh, it concluded that the TCP/IP protocol suite would need to be enhanced to meet the overall ease-of-use requirements of Macintosh users.

In the late 1980s, Apple approached the Internet Engineering Task Force (IETF), the body responsible for developing Internet-standard protocols. A working group was begun on the subject of service location on IP networks, using the techniques developed in AppleTalk and NBP as a basis. Although the group made some progress, there did not seem to be enough interest in making IP easy to use, and the SLP effort moved slowly.

With the explosion of interest in the Internet and Internet protocols over the past few years, work on SLP has been reinvigorated. SLP version 2 has recently been completed. A number of vendors have implemented SLP and "connectathons" have taken place to enhance interoperability between vendor implementations. Novell recently included an SLP implementation with NetWare version 5.

SLP and the Mac OS: When Apple shipped Mac OS 8.5 in mid-1998, it brought the SLP effort it started nearly ten years earlier to fruition. Mac OS 8.5 included the Network Services Location (NSL) Manager, an API which enables services to register through protocols like SLP and client-side applications to browse for and initiate access to such services. NSL provides a plug-in architecture for service location. The principal plug-in included by Apple with Mac OS 8.5 was an SLP version 1 plug-in.

As with many of its early "enabling technologies," Apple seemed to be counting on third parties to utilize the NSL technology to provide end user solutions. The only use of NSL within Mac OS 8.5 itself was that Personal Web Sharing registered with the NSL Manager. Neither the Chooser nor the Network Browser utilized NSL to present a list of registered services to the end user. Additionally, no end-user documentation discussed NSL or SLP in any way.

Open Door Networks accepted Apple's challenge and provided the first end-user products to take advantage of NSL and SLP. Open Door's president, Alan Oppenheimer, was involved in both the design of AppleTalk and Apple's initial SLP efforts. Open Door's ShareWay IP product, which provides AppleTalk Filing Protocol (AFP) service using IP protocols, registered with NSL to make itself visible through SLP. And Open Door's AFP Engage! product acted as a "Chooser" for SLP-registered servers, displaying a dynamically updating, browseable list from which users could select the server they wished to connect to. Through Open Door's system and SLP, Macintosh file sharing services, including the Mac's built-in File Sharing, became as easy to use over IP as over AppleTalk.

With Mac OS 9, Apple began to fully integrate SLP directly into the Mac OS. Apple licensed ShareWay IP from Open Door, and used the product to provide the IP file sharing feature of Mac OS 9. ShareWay's SLP functionality was of course included. With Open Door's help, Apple also updated Mac OS 9's Network Browser and Navigation Services to support SLP, providing, for the first time, integrated SLP support within the OS itself. Mac OS 9 also included an update of the SLP implementation to SLP v2.

SLP limitations: Like any new system, a number of limitations exist with SLP in its current state. Most of these limitations relate to the scalability of the system. SLP adopted many of the scalability features of AppleTalk, while at the same time trying to improve upon AppleTalk's limitations in large network environments. Many of SLP's scalability features, however, have not yet been fully implemented.

Just as AppleTalk defined the concept of a "zone", in which services could be searched for in a hierarchical manner, SLP defines the very similar concept of a "scope." Unfortunately Apple's implementation of scopes in NSL (called "neighborhoods") is somewhat limiting. In Mac OS 9, for example, the scope in which a particular service is registered is usually set to the search domain (from the TCP/IP control panel) for that service's machine. All services without search domains appear in the same, non-hierarchical list.

SLP also attempted to mimic AppleTalk's ability to provide dynamic naming services without need for any centralized name server or other agent. SLP uses a technique known as IP multicast for this purpose. IP multicast requires the cooperation of IP routers, the devices which connect IP subnets together to form intranets. Most current IP routers implement IP multicast, which is used for such features as IP-based audio and video broadcasting and video conferencing. However IP multicasting may not be completely implemented across some intranets. In the absence of IP multicasting, SLP name lookups will only work within the subnet on which they are performed, or within the groups of subnets over which IP multicast is supported.

In large environments, AppleTalk's independence from centralized name servers was sometimes viewed as a limitation. NBP used multicast to enable independence from name servers, and AppleTalk multicasts could propagate throughout the intranet. SLP attempts to improve upon NBP by optionally allowing names servers, called "directory agents" or DA's. DA's minimize the need to use IP multicast, and can result in significantly less traffic than a completely distributed system like NBP. They can also enhance the protocol's hierarchical scope concept, and provide other services. Unfortunately, at the current time, no commercially supported DA is available, so IP multicast must continue to be used. As SLP momentum continues, however, it is expected that DA's will be available in the near future.

Despite its current limitations, SLP remains very useable for specific tasks, such as dynamic service location on all but the largest of intranets. Even within large intranets, SLP should function well for workgroup-specific service location. And as both Apple and third-parties enhance their implementations, most current limitations should soon be eliminated, providing an IP service location system that is just as easy to use as AppleTalk's.

Summary: After a number of years of inattention, Apple's effort to bring AppleTalk's ease-of-use to Internet protocols is beginning to pay off. The Service Location Protocol shows promise for providing a much-needed means of dynamically browsing for and selecting services in intranet environments. As with most new protocols, limitations and issues remain, and third party implementations are scarce, but the inclusion of SLP in Mac OS 9, coupled with efforts such as Open Door's ShareWay, should serve to further enhance the momentum behind SLP.

Copyright (C) 1999 Open Door Networks, Inc. ShareWay IP and AFP Engage! are trademarks of Open Door Networks, Inc. All other products are trademarks of their respective holders.