RFC 2608
Service Location Protocol, Version 2
Network Working Group E. Guttman Request for Comments: 2608 C. Perkins Updates: 2165 Sun Microsystems Category: Standards Track J. Veizades @Home Network M. Day Vinca Corporation 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 Notice Copyright (C) The Internet Society (1999). All Rights Reserved.Abstract
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 administration.Table of Contents
1. Introduction 3 1.1. Applicability Statement . . . . . . . . . . . . . . . 3 2. Terminology 4 2.1. Notation Conventions . . . . . . . . . . . . . . . . . 4 3. Protocol Overview 5 4. URLs used with Service Location 8 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 9 4.2. Naming Authorities . . . . . . . . . . . . . . . . . 10 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 10 5. Service Attributes 10 6. Required Features 12 6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13
6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . 14
6.3. Retransmission of SLP messages . . . . . . . . . . . 15
6.4. Strings in SLP messages . . . . . . . . . . . . . . . 16
6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . 16
7. Errors 17
8. Required SLP Messages 17
8.1. Service Request . . . . . . . . . . . . . . . . . . . 19
8.2. Service Reply . . . . . . . . . . . . . . . . . . . . 21
8.3. Service Registration . . . . . . . . . . . . . . . . . 22
8.4. Service Acknowledgment . . . . . . . . . . . . . . . . 23
8.5. Directory Agent Advertisement. . . . . . . . . . . . . 24
8.6. Service Agent Advertisement. . . . . . . . . . . . . . 25
9. Optional Features 26
9.1. Service Location Protocol Extensions . . . . . . . . . 27
9.2. Authentication Blocks . . . . . . . . . . . . . . . . 28
9.2.1. SLP Message Authentication Rules . . . . . . . 29
9.2.2. DSA with SHA-1 in Authentication Blocks . . . 30
9.3. Incremental Service Registration . . . . . . . . . . 30
9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . 31
10. Optional SLP Messages 32
10.1. Service Type Request . . . . . . . . . . . . . . . . 32
10.2. Service Type Reply . . . . . . . . . . . . . . . . . 32
10.3. Attribute Request . . . . . . . . . . . . . . . . . . 33
10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . 34
10.5. Attribute Request/Reply Examples . . . . . . . . . . . 34
10.6. Service Deregistration . . . . . . . . . . . . . . . 36
11. Scopes 37
11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . 37
11.2. Administrative and User Selectable Scopes. . . . . . . 38
12. Directory Agents 38
12.1. Directory Agent Rules . . . . . . . . . . . . . . . . 39
12.2. Directory Agent Discovery . . . . . . . . . . . . . . 39
12.2.1. Active DA Discovery . . . . . . . . . . . . . 40
12.2.2. Passive DA Advertising . . . . . . . . . . . . 40
12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . . 41
12.4. DA Scope Configuration . . . . . . . . . . . . . . . 41
12.5. DAs and Authentication Blocks. . . . . . . . . . . . . 41
13. Protocol Timing Defaults 42
14. Optional Configuration 43
15. IANA Considerations 44
16. Internationalization Considerations 45
17. Security Considerations 46
A. Appendix: Changes to the Service Location Protocol from
v1 to v2 48
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 48
C. Appendix: DAAdverts with arbitrary URLs 49
D. Appendix: SLP Protocol Extensions 50
D.1. Required Attribute Missing Option . . . . . . . . . . 50
E. Acknowledgments 50
F. References 51
G. Authors' Addresses 53
H. Full Copyright Statement 54
1. 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
services.
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
services.
2. Terminology
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 given host. Service Type Each type of service has a unique Service Type string. 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 administrative group. URL A Universal Resource Locator [8].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 [9]. Syntax Syntax for string based protocols follow the conventions defined for ABNF [11]. Strings All strings are encoded using the UTF-8 [23] transformation of the Unicode [6] 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 following syntax: 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 Advertisement (DAAdvert). +---------------+ --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 both. 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
be updated.
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 [22]. This support
includes:
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
registered services.
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
types.
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
this service.
4. URLs used with Service Location
A Service URL indicates the location of a service. This URL may be
of the service: scheme [13] (reviewed in section 4.1), or any other
URL scheme conforming to the URI standard [8], 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 [8].
4.1. Service: URLs
Service URL syntax and semantics are defined in [13]. 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 services. A Service URL may be of the form: "service:"<srvtype>"://"<addrspec> The Service Type of this service: URL is defined to be the string up to (but not including) the final `:' before <addrspec>, the address specification. <addrspec> is a hostname (which should be used if possible) or dotted decimal notation for a hostname, followed by an optional `:' and port number. A service: scheme URL may be formed with any standard protocol name by concatenating "service:" and the reserved port [1] name. For example, "service:tftp://myhost" would indicate a tftp service. A tftp service on a nonstandard port could be "service:tftp://bad.glad.org:8080". Service Types SHOULD be defined by a "Service Template" [13], which provides expected attributes, values and protocol behavior. An abstract service type (also described in [13]) has the form "service:<abstract-type>:<concrete-type>". 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 service:abstract.two:y.
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 appropriate services. The allowable attributes which may be used are typically specified by a Service Template [13] 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 [11] 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 integer comparison. 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 requests. 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 INVALID_REGISTRATION error.
(page 12 continued on part 2)
