Network Working Group E. Guttman
Request for Comments: 2608 C. Perkins
Updates: 2165 Sun Microsystems
Category: Standards Track J. Veizades
June 1999 Service Location Protocol, Version 2
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet need little or no static configuration
of network services for network based applications. This is
especially important as computers become more portable, and users
less tolerant or able to fulfill the demands of network system
Table of Contents
1. Introduction 31.1. Applicability Statement . . . . . . . . . . . . . . . 32. Terminology 42.1. Notation Conventions . . . . . . . . . . . . . . . . . 43. Protocol Overview 54. URLs used with Service Location 84.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 94.2. Naming Authorities . . . . . . . . . . . . . . . . . 104.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 105. Service Attributes 106. Required Features 126.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13
E. Acknowledgments 50F. References 51G. Authors' Addresses 53H. Full Copyright Statement 541. Introduction
The Service Location Protocol (SLP) provides a flexible and scalable
framework for providing hosts with access to information about the
existence, location, and configuration of networked services.
Traditionally, users have had to find services by knowing the name of
a network host (a human readable text string) which is an alias for a
network address. SLP eliminates the need for a user to know the name
of a network host supporting a service. Rather, the user supplies
the desired type of service and a set of attributes which describe
the service. Based on that description, the Service Location
Protocol resolves the network address of the service for the user.
SLP provides a dynamic configuration mechanism for applications in
local area networks. Applications are modeled as clients that need
to find servers attached to any of the available networks within an
enterprise. For cases where there are many different clients and/or
services available, the protocol is adapted to make use of nearby
Directory Agents that offer a centralized repository for advertised
This document updates SLPv1 [RFC 2165], correcting protocol errors,
adding some enhancements and removing some requirements. This
specification has two parts. The first describes the required
features of the protocol. The second describes the extended features
of the protocol which are optional, and allow greater scalability.
1.1. Applicability Statement
SLP is intended to function within networks under cooperative
administrative control. Such networks permit a policy to be
implemented regarding security, multicast routing and organization of
services and clients into groups which are not be feasible on the
scale of the Internet as a whole.
SLP has been designed to serve enterprise networks with shared
services, and it may not necessarily scale for wide-area service
discovery throughout the global Internet, or in networks where there
are hundreds of thousands of clients or tens of thousands of
User Agent (UA)
A process working on the user's behalf to establish
contact with some service. The UA retrieves service
information from the Service Agents or Directory Agents.
Service Agent (SA) A process working on the behalf of one or more
services to advertise the services.
Directory Agent (DA) A process which collects service
advertisements. There can only be one DA present per
Service Type Each type of service has a unique Service Type
Naming Authority The agency or group which catalogues given
Service Types and Attributes. The default Naming
Authority is IANA.
Scope A set of services, typically making up a logical
URL A Universal Resource Locator .
2.1. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 .
Syntax Syntax for string based protocols follow the
conventions defined for ABNF .
Strings All strings are encoded using the UTF-8 
transformation of the Unicode  character set and
are NOT null terminated when transmitted. Strings
are preceded by a two byte length field.
<string-list> A comma delimited list of strings with the
string-list = string / string `,' string-list
In format diagrams, any field ending with a \ indicates a variable
length field, given by a prior length field in the protocol.
3. Protocol Overview
The Service Location Protocol supports a framework by which client
applications are modeled as 'User Agents' and services are advertised
by 'Service Agents.' A third entity, called a 'Directory Agent'
provides scalability to the protocol.
The User Agent issues a 'Service Request' (SrvRqst) on behalf of the
client application, specifying the characteristics of the service
which the client requires. The User Agent will receive a Service
Reply (SrvRply) specifying the location of all services in the
network which satisfy the request.
The Service Location Protocol framework allows the User Agent to
directly issue requests to Service Agents. In this case the request
is multicast. Service Agents receiving a request for a service which
they advertise unicast a reply containing the service's location.
+------------+ ----Multicast SrvRqst----> +---------------+
| User Agent | | Service Agent |
+------------+ <----Unicast SrvRply------ +---------------+
In larger networks, one or more Directory Agents are used. The
Directory Agent functions as a cache. Service Agents send register
messages (SrvReg) containing all the services they advertise to
Directory Agents and receive acknowledgements in reply (SrvAck).
These advertisements must be refreshed with the Directory Agent or
they expire. User Agents unicast requests to Directory Agents
instead of Service Agents if any Directory Agents are known.
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
| User | | Directory | |Service |
| Agent | | Agent | | Agent |
+-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
User and Service Agents discover Directory Agents two ways. First,
they issue a multicast Service Request for the 'Directory Agent'
service when they start up. Second, the Directory Agent sends an
unsolicited advertisement infrequently, which the User and Service
Agents listen for. In either case the Agents receive a DA
+---------------+ --Multicast SrvRqst-> +-----------+
| User or | <--Unicast DAAdvert-- | Directory |
| Service Agent | | Agent |
+---------------+ <-Multicast DAAdvert- +-----------+
Services are grouped together using 'scopes'. These are strings
which identify services which are administratively identified. A
scope could indicate a location, administrative grouping, proximity
in a network topology or some other category. Service Agents and
Directory Agents are always assigned a scope string.
A User Agent is normally assigned a scope string (in which case the
User Agent will only be able to discover that particular grouping of
services). This allows a network administrator to 'provision'
services to users. Alternatively, the User Agent may be configured
with no scope at all. In that case, it will discover all available
scopes and allow the client application to issue requests for any
service available on the network.
+---------+ Multicast +-----------+ Unicast +-----------+
| Service | <--SrvRqst-- | User | --SrvRqst-> | Directory |
| Agent | | Agent | | Agent |
| Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y |
+---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+
In the above illustration, the User Agent is configured with scopes X
and Y. If a service is sought in scope X, the request is multicast.
If it is sought in scope Y, the request is unicast to the DA.
Finally, if the request is to be made in both scopes, the request
must be both unicast and multicast.
Service Agents and User Agents may verify digital signatures provided
with DAAdverts. User Agents and Directory Agents may verify service
information registered by Service Agents. The keying material to use
to verify digital signatures is identified using a SLP Security
Parameter Index, or SLP SPI.
Every host configured to generate a digital signature includes the
SLP SPI used to verify it in the Authentication Block it transmits.
Every host which can verify a digital signature must be configured
with keying material and other parameters corresponding with the SLP
SPI such that it can perform verifying calculations.
SAs MUST accept multicast service requests and unicast service
requests. SAs MAY accept other requests (Attribute and Service Type
Requests). SAs MUST listen for multicast DA Advertisements.
The features described up to this point are required to implement. A
minimum implementation consists of a User Agent, Service Agent or
There are several optional features in the protocol. Note that DAs
MUST support all these message types, but DA support is itself
optional to deploy on networks using SLP. UAs and SAs MAY support
these message types. These operations are primarily for interactive
use (browsing or selectively updating service registrations.) UAs
and SAs either support them or not depending on the requirements and
constraints of the environment where they will be used.
Service Type Request A request for all types of service on the
network. This allows generic service browsers
to be built.
Service Type Reply A reply to a Service Type Request.
Attribute Request A request for attributes of a given type of
service or attributes of a given service.
Attribute Reply A reply to an Attribute Request.
Service Deregister A request to deregister a service or some
attributes of a service.
Service Update A subsequent SrvRqst to an advertisement.
This allows individual dynamic attributes to
SA Advertisement In the absence of Directory Agents, a User
agent may request Service Agents in order
to discover their scope configuration. The
User Agent may use these scopes in requests.
In the absence of Multicast support, Broadcast MAY be used. The
location of DAs may be staticly configured, discovered using SLP as
described above, or configured using DHCP. If a message is too large,
it may be unicast using TCP.
A SLPv2 implementation SHOULD support SLPv1 . This support
1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.
2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
SLPv1 UAs MUST be reconfigured to have a scope if possible.
3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.
4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
requests with SLPv2 replies.
5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
way. That is, incoming requests from agents using either version
of the protocol will be matched against this common set of
6. SLPv2 registrations which use Language Tags which are greater
than 2 characters long will be inaccessible to SLPv1 UAs.
7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
messages which conform to SLPv1 service type string syntax, ie.
they MUST NOT return Service Type strings for abstract service
8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
URLs with abstract service types. They only match Service URLs
with concrete service types.
SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will
not receive replies from SLPv1 SAs. In order to interoperate UAs and
SAs of different versions require a SLPv2 DA to be present on the
network which supports both protocols.
The use of abstract service types in SLPv2 presents a backward
compatibility issue for SLPv1. It is possible that a SLPv1 UA will
request a service type which is actually an abstract service type.
Based on the rules above, the SLPv1 UA will never receive an abstract
Service URL reply. For example, the service type 'service:x' in a
SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'.
If the request was made with SLPv2, it would return the attributes of
4. URLs used with Service Location
A Service URL indicates the location of a service. This URL may be
of the service: scheme  (reviewed in section 4.1), or any other
URL scheme conforming to the URI standard , except that URLs
without address specifications SHOULD NOT be advertised by SLP. The
service type for an 'generic' URL is its scheme name. For example,
the service type string for "http://www.srvloc.org" would be "http".
Reserved characters in URLs follow the rules in RFC 2396 .
4.1. Service: URLs
Service URL syntax and semantics are defined in . Any network
service may be encoded in a Service URL.
This section provides an introduction to Service URLs and an example
showing a simple application of them, representing standard network
A Service URL may be of the form:
The Service Type of this service: URL is defined to be the string up
to (but not including) the final `:' before <addrspec>, the address
<addrspec> is a hostname (which should be used if possible) or dotted
decimal notation for a hostname, followed by an optional `:' and
A service: scheme URL may be formed with any standard protocol name
by concatenating "service:" and the reserved port  name. For
example, "service:tftp://myhost" would indicate a tftp service. A
tftp service on a nonstandard port could be
Service Types SHOULD be defined by a "Service Template" , which
provides expected attributes, values and protocol behavior. An
abstract service type (also described in ) has the form
The service type string "service:<abstract-type>" matches all
services of that abstract type. If the concrete type is included
also, only these services match the request. For example: a SrvRqst
or AttrRqst which specifies "service:printer" as the Service Type
will match the URL service:printer:lpr://hostname and
service:printer:http://hostname. If the requests specified
"service:printer:http" they would match only the latter URL.
An optional substring MAY follow the last `.' character in the
<srvtype> (or <abstract-type> in the case of an abstract service type
URL). This substring is the Naming Authority, as described in Section
9.6. Service types with different Naming Authorities are quite
distinct. In other words, service:x.one and service:x.two are
different service types, as are service:abstract.one:y and
4.2. Naming Authorities
A Naming Authority MAY optionally be included as part of the Service
Type string. The Naming Authority of a service defines the meaning
of the Service Types and attributes registered with and provided by
Service Location. The Naming Authority itself is typically a string
which uniquely identifies an organization. IANA is the implied
Naming Authority when no string is appended. "IANA" itself MUST NOT
be included explicitly.
Naming Authorities may define Service Types which are experimental,
proprietary or for private use. Using a Naming Authority, one may
either simply ignore attributes upon registration or create a local-
use only set of attributes for one's site. The procedure to use is
to create a 'unique' Naming Authority string and then specify the
Standard Attribute Definitions as described above. This Naming
Authority will accompany registration and queries, as described in
Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA
to allow for Internet-wide interoperability.
4.3. URL Entries
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Reserved | Lifetime | URL Length |
|URL len, contd.| URL (variable length) \
|# of URL auths | Auth. blocks (if any) \
SLP stores URLs in protocol elements called URL Entries, which
associate a length, a lifetime, and possibly authentication
information along with the URL. URL Entries, defined as shown above,
are used in Service Replies and Service Registrations.
5. Service Attributes
A service advertisement is often accompanied by Service Attributes.
These attributes are used by UAs in Service Requests to select
The allowable attributes which may be used are typically specified by
a Service Template  for a particular service type. Services
which are advertised according to a standard template MUST register
all service attributes which the standard template requires. URLs
with schemes other than "service:" MAY be registered with attributes.
Non-standard attribute names SHOULD begin with "x-", because no
standard attribute name will ever have those initial characters.
An attribute list is a string encoding of the attributes of a
service. The following ABNF  grammar defines attribute lists:
attr-list = attribute / attribute `,' attr-list
attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
attr-val-list = attr-val / attr-val `,' attr-val-list
attr-tag = 1*safe-tag
attr-val = intval / strval / boolval / opaque
intval = [-]1*DIGIT
strval = 1*safe-val
boolval = "true" / "false"
opaque = "\FF" 1*escape-val
safe-val = ; Any character except reserved.
safe-tag = ; Any character except reserved, star and bad-tag.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
escape-val = `\' HEXDIG HEXDIG
bad-tag = CR / LF / HTAB / `_'
star = `*'
The <attr-list>, if present, MUST be scanned prior to evaluation for
all occurrences of the escape character `\'. Reserved characters
MUST be escaped (other characters MUST NOT be escaped). All escaped
characters must be restored to their value before attempting string
matching. For Opaque values, escaped characters are not converted -
they are interpreted as bytes.
Boolean Strings which have the form "true" or "false" can
only take one value and may only be compared with
'='. Booleans are case insensitive when compared.
Integer Strings which take the form [-] 1*<digit> and fall
in the range "-2147483648" to "2147483647" are
considered to be Integers. These are compared using
String All other Strings are matched using strict lexical
ordering (see Section 6.4).
Opaque Opaque values are sequences of bytes. These are
distinguished from Strings since they begin with
the sequence "\FF". This, unescaped, is an illegal
UTF-8 encoding, indicating that what follows is a
sequence of bytes expressed in escape notation which
constitute the binary value. For example, a '0' byte
is encoded "\FF\00".
A string which contains escaped values other than from the reserved
set of characters is illegal. If such a string is included in an
<attr-list>, <tag-list> or search filter, the SA or DA which receives
it MUST return a PARSE_ERROR to the message.
A keyword has only an <attr-tag>, and no values. Attributes can have
one or multiple values. All values are expressed as strings.
When values have been advertised by a SA or are registered in a DA,
they can take on implicit typing rules for matching incoming
Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is
disallowed. A DA or SA receiving such an <attr-list> MUST return an