The Service Location Protocol (SLP) was originally an Internet Engineering Task Force (IETF) standards track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks. Traditionally, in order to locate services on the network, users of network applications have been required to supply the host name or network address of the machine that provides a desired service. Ensuring that users and applications are supplied with the correct information has, in many cases, become an administrative nightmare.
Protocols that support service location are often taken for granted,
mostly because they are already included (without fanfare) in many
network
operating systems. For example, without Microsoft's SMB service
location
facilities, "Network Neighborhood" could not discover services
available
for use on the network and Novell NetWare would be unable to locate
eDirectory trees. Nevertheless, an IETF sponsored protocol for service
location was not
standardized
until the advent of SLP. Because it is not tied to a proprietary
technology, SLP provides a service location solution that could become
extremely important (especially on Unix) platforms.
RFC 2165 - Service Location Protocol, Version 1
RFC 2608 - Service Location Protocol, Version 2
RFC 2609 - Service Templates and Service Schemes
RFC 2614 - An API for Service Location Protocol
Consider the following example of a new employee setting up his
workstation
to use one of the department printers. Here's a dialog between this new
employee (Newbie), and his
coworker (Stan), who's been
around for a while:
Traditional
Newbie: "Hey Stan, the setup program is asking me for the name of our printer. What should I type in?"
Stan: "Which printer do you want?"
Newbie: "The big one by the copier."
Stan: "I've heard it doesn't work well with postscript applications. You'll have to use the one down the hall."
Newbie: "Ok. What should I type in."
Stan: "Actually, I don't know; I use the one by the copier. You'll probably have to call the IS help desk."
Newbie: <groan> ...With SLP
A setup program uses SLP to display to the user the description (including location) of the printers that work with postscript. The user selects one that is close to his office. The SLP service returns all necessary addressing information directly to his device setup application.
Consider the following example of a software engineer who is writing
an LDAP-enabled application.
Traditional
Currently, the only way to know the hostname of the LDAP server to use in the call to ldap_init() is to read it from a configuration file. The configuration file must be created at install time and updated as the location of the LDAP server changes. Keeping this configuration file up to date becomes a real problem, especially when the LDAP application is installed on a laptop that connects to various networks.With SLP
The developer uses SLP to obtain the host names and attributes of LDAP servers that are displayed to the user at install time, and again if the user desires to connect to a different LDAP server.
As illustrated in the example above, SLP does not always eliminate the need to prompt users for information. However, it does allow the software developer to present a descriptive list of services that can be understood by the user.
User Agent (UA)
The SLP User Agent is a software entity that is looking for the location of one or more services. Usually implemented (at least partially), as a library to which client applications link, it provides client applications with a simple interface for accessing SLP registered service information.Service Agent (SA)
The SLP Service Agent is a software entity that advertises the location of one or more services. SLP advertisement is designed to be both scalable and effective, minimizing the use of network bandwidth through the use of targeted multi-cast messages, and uni-cast responses to queries.Directory Agent(DA)
The SLP Directory Agent is a software entity that acts as a centralized repository for service location information. Both Service Agents and User Agents make it a priority to discover available Directory Agents, as using a Directory Agent minimizes the amount of multi-cast messages sent by the protocol on the network.
Service Request (SrvRqst)
Message sent by UA's to SA's and DA's to request the location of a service.Service Reply (SrvRply)
Message sent by SA's and DA's in response to a SrvRqst message. The SrvRply contains the URL of the requested service.Service Registration (SrvReg)
Message sent by SA's to DA's containing information about a service that is available.Service Deregister (SrvDeReg)
Message sent by SA's to inform DA's that a service is no longer available.Service Acknowledge (SrvAck)
A generic acknowledgment that is sent by DA's to SA's in response to SrvReg and SrvDeReg messages.Attribute Request (AttrRqst)
Message sent by UA's to request the attributes of a service.Attribute Reply (AttrRply)
Message sent by SA's and DA's in response to a AttrRqst. The AttrRply contains the list of attributes that were requested.Service Type Request (SrvTypeRqst)
Message sent by UA's to SA's and DA's requesting the types of services that are available.Service Type Reply (SrvTypeRply)
Message by SA's and DA's in response to a SrvTypeRqst. The SrvTypeRply contains a list of requested service types.DA Advertisement (DAAdvert)
Message sent by DA's to let SA's and UA's know where they are.SA Advertisement (SAAdvert)
Message sent by SA's to let UA's know where they are.
For obvious reasons, network routers filter almost all broadcast
traffic. This means that broadcasts that are generated on one subnet
will not be
forwarded, or "routed" to any of the other subnets connected to the
router
(from the router's perspective, a subnet is all machines connected to
one
of its ports). Multicast messages, on the other hand, are forwarded by
routers. Multicast traffic from a given group is forwarded by routers
to all
subnets
that have at least one machine that is interested in receiving the
multicast
for that group.
Service Registration
Service Request/Reply
The following is a list of the major SLP API function calls (more
information
can be found in the OpenSLP
Programmer's
Guide or RFC 2614):
SLPReg()
Registers a service URL and service attributes with SLP.SLPDeReg()
Deregisters a previously registered service.SLPFindSrvs()
Finds services based on service type or attributes.SLPFindAttrs()
Obtains a list of attributes for services registered with SLP.SLPFindSrvTypes()
Obtains a list of the types of services that have been registered with SLP.
Security
SLPv2 has been designed to be a secure protocol. When properly
implemented, SLPv2 can ensure integrity and authenticity of data being
transmitted
between SLP agents. See RFC
2608, section 9.2 for more information.
Scalability
SLPv2 was designed to be a scalable solution for enterprise service
location. It is not intended to be a solution for the global
Internet.
However, as an enterprise solution, SLP can be configured to use
"scopes"
(see RFC 2608 section 11) and SLP
Directory Agents
in
ways that should allow it to scale well in very larger networks. More
concrete evidence of SLPv2 scalability will become available when SLP
is
more widely used.
Implementations
The following is a list of known SLP implementations:
OpenSLP
An OpenSource project that aims to provide a full SLPv2 implementationSun Microsystems
Offers a "reference implementation" of SLPv2 that is available under the Sun Community LicenseNovell NetWare
SLPv2 is implemented by Novell NetWare servers in NetWare versions 5 through 7.
Axis Communications
Uses SLP in its thin server products