RFC2608 - 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 [RFC2165], 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 RFC2119 [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 RFC2396 [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 "FF0".
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,ff00 is
disallowed. A DA or SA receiving such an <attr-list> MUST return an
INVALID_REGISTRATION error.
6. Required Features
This section defines the minimal implementation requirements for SAs
and UAs as well as their interaction with DAs. A DA is not required
for SLP to function, but if it is present, the UA and SA MUST
interact with it as defined below.
A minimal implementation may consist of either a UA or SA or both.
The only required features of a UA are that it can issue SrvRqsts
according to the rules below and interpret DAAdverts, SAAdverts and
SrvRply messages. The UA MUST issue requests to DAs as they are
discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or
SAAdvert messages. The SA MUST also register with DAs as they are
discovered.
UAs perform discovery by issuing Service Request messages. SrvRqst
messages are issued, using UDP, following these prioritized rules:
1. A UA issues a request to a DA which it has been configured with
by DHCP.
2. A UA issues requests to DAs which it has been statically
configured with.
3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses
that set of DAs. A UA that does not know of any DAs SHOULD retry
DA discovery, increasing the waiting interval between subsequent
attempts exponentially (doubling the wait interval each time.)
The recommended minimum waiting interval is CONFIG_DA_FIND
seconds.
4. A UA with no knowledge of DAs sends requests using multicast
convergence to SAs. SAs unicast replies to UAs according to the
multicast convergence algorithm.
UAs and SAs are configured with a list of scopes to use according to
these prioritized rules:
1. With DHCP.
2. With static configuration. The static configuration may be
explicitly set to NO SCOPE for UAs, if the User Selectable Scope
model is used. See section 11.2.
3. In the absence of configuration, the agent"s scope is "DEFAULT".
A UA MUST issue requests with one or more of the scopes it has been
configured to use.
A UA which has been statically configured with NO SCOPE LIST will use
DA or SA discovery to determine its scope list dynamically. In this
case it uses an empty scope list to discover DAs and possibly SAs.
Then it uses the scope list it oBTains from DAAdverts and possibly
SAAdverts in subsequent requests.
The SA MUST register all its services with any DA it discovers, if
the DA advertises any of the scopes it has been configured with. A
SA obtains information about DAs as a UA does. In addition, the SA
MUST listen for multicast unsolicited DAAdverts. The SA registers by
sending SrvReg messages to DAs, which reply with SrvReg messages to
indicate success. SAs register in ALL the scopes they were
configured to use.
6.1. Use of Ports, UDP, and Multicast
DAs MUST accept unicast requests and multicast directory agent
discovery service requests (for the service type "service:directory-
agent").
SAs MUST accept multicast requests and unicast requests both. The SA
can distinguish between them by whether the REQUEST MCAST flag is set
in the SLP Message header.
The Service Location Protocol uses multicast for discovering DAs and
for issuing requests to SAs by default.
The reserved listening port for SLP is 427. This is the destination
port for all SLP messages. SLP messages MAY be transmitted on an
ephemeral port. Replies and acknowledgements are sent to the port
from which the request was issued. The default maximum transmission
unit for UDP messages is 1400 bytes excluding UDP and other headers.
If a SLP message does not fit into a UDP datagram it MUST be
truncated to fit, and the OVERFLOW flag is set in the reply message.
A UA which receives a truncated message MAY open a TCP connection
(see section 6.2) with the DA or SA and retransmit the request, using
the same XID. It MAY also attempt to make use of the truncated reply
or reformulate a more restrictive request which will result in a
smaller reply.
SLP Requests messages are multicast to The Administratively Scoped
SLP Multicast [17] address, which is 239.255.255.253. The default
TTL to use for multicast is 255.
In isolated networks, broadcasts will work in place of multicast. To
that end, SAs SHOULD and DAs MUST listen for broadcast Service
Location messages at port 427. This allows UAs which do not support
multicast the use of Service Location on isolated networks.
Setting multicast TTL to less than 255 (the default) limits the range
of SLP discovery in a network, and localizes service information in
the network.
6.2. Use of TCP
A SrvReg or SrvDeReg may be too large to fit into a datagram. To
send such large SLP messages, a TCP (unicast) connection MUST be
established.
To avoid the need to implement TCP, one MUST insure that:
- UAs never issue requests larger than the Path MTU. SAs can omit
TCP support only if they never have to receive unicast requests
longer than the path MTU.
- UAs can accept replies with the "OVERFLOW" flag set, and make use
of the first result included, or reformulate the request.
- Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in
a single datagram. This means limiting the size of URLs,
the number of attributes and the number of authenticators
transmitted.
DAs MUST be able to respond to UDP and TCP requests, as well as
multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP
unless the SA will NEVER receive a request or send a reply which will
exceed a datagram in size (e.g., some embedded systems).
A TCP connection MAY be used for a single SLP transaction, or for
multiple transactions. Since there are length fields in the message
headers, SLP Agents can send multiple requests along a connection and
read the return stream for acknowledgments and replies.
The initiating agent SHOULD close the TCP connection. The DA SHOULD
wait at least CONFIG_CLOSE_CONN seconds before closing an idle
connection. DAs and SAs SHOULD close an idle TCP connection after
CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
initiating agent neglects to close it. See Section 13 for timing
rules.
6.3. Retransmission of SLP messages
Requests which fail to elicit a response are retransmitted. The
initial retransmission occurs after a CONFIG_RETRY wait period.
Retransmissions MUST be made with exponentially increasing wait
intervals (doubling the wait each time). This applies to unicast as
well as multicast SLP requests.
Unicast requests to a DA or SA should be retransmitted until either a
response (which might be an error) has been obtained, or for
CONFIG_RETRY_MAX seconds.
Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds
until a result has been obtained. UAs need only wait till they
obtain the first reply which matches their request. That is,
retransmission is not required if the requesting agent is prepared to
use the "first reply" instead of "as many replies as possible within
a bounded time interval."
When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
they contain a <PRList> of previous responders. Initially the
<PRList> is empty. When these requests are unicast, the <PRList> is
always empty.
Any DA or SA which sees its address in the <PRList> MUST NOT respond
to the request.
The message SHOULD be retransmitted until the <PRList> causes no
further responses to be elicited or the previous responder list and
the request will not fit into a single datagram or until
CONFIG_MC_MAX seconds elapse.
UAs which retransmit a request use the same XID. This allows a DA or
SA to cache its reply to the original request and then send it again,
should a duplicate request arrive. This cached information should
only be held very briefly. XIDs SHOULD be randomly chosen to avoid
duplicate XIDs in requests if UAs restart frequently.
6.4. Strings in SLP messages
The escape character is a backslash (UTF-8 0x5c) followed by the two
hexadecimal digits of the escaped character. Only reserved
characters are escaped. For example, a comma (UTF-8 0x29) is escaped
as `29", and a backslash `" is escaped as `5c". String lists used
in SLP define the comma to be the delimiter between list elements, so
commas in data strings must be escaped in this manner. Backslashes
are the escape character so they also must always be escaped when
included in a string literally.
String comparison for order and equality in SLP MUST be case
insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds
to ASCII character encoding). Case insensitivity SHOULD be supported
throughout the entire UTF-8 encoded Unicode [6] character set.
The case insensitivity rule applies to all string matching in SLPv2,
including Scope strings, SLP SPI strings, service types, attribute
tags and values in query handling, language tags, previous responder
lists. Comparisons of URL strings, however, is case sensitive.
White space (SPACE, CR, LF, TAB) internal to a string value is folded
to a single SPACE character for the sake of string comparisons.
White space preceding or following a string value is ignored for the
purposes of string comparison. For example, " Some String "
matches "SOME STRING".
String comparisons (using comparison operators such as `<=" or `>=")
are done using lexical ordering in UTF-8 encoded characters, not
using any language specific rules.
The reserved character `*" may precede, follow or be internal to a
string value in order to indicate substring matching. The query
including this character matches any character sequence which
conforms to the letters which are not wildcarded.
6.4.1. Scope Lists in SLP
Scope Lists in SLPv2 have the following grammar:
scope-list = scope-val / scope-val `," scope-list
scope-val = 1*safe
safe = ; Any character except reserved.
reserved = `(" / `)" / `," / `" / `!" / `<" / `=" / `>" / `~" / CTL
/ `;" / `*" / `+"
escape-val = `" HEXDIG HEXDIG
Scopes which include any reserved characters must replace the escaped
character with the escaped-val format.
7. Errors
If the Error Code in a SLP reply message is nonzero, the rest of the
message MAY be truncated. No data is necessarily transmitted or
should be expected after the header and the error code, except
possibly for some optional extensions to clarify the error, for
example as in section D.1.
Errors are only returned for unicast requests. Multicast requests
are silently discarded if they result in an error.
LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in
the scope in the AttrRqst or SrvRqst, but not in the requested
language.
PARSE_ERROR = 2: The message fails to obey SLP syntax.
INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero
lifetime or an omitted Language Tag.
SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
its <scope-list> supported by the SA or DA.
AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an
unsupported SLP SPI.
AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR
authentication in the SrvReg and did not receive it.
AUTHENTICATION_FAILED = 7: The DA detected an authentication error in
an Authentication block.
VER_NOT_SUPPORTED = 9: Unsupported version number in message header.
INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond.
DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off.
OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option
from the mandatory range (see section 9.1).
INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
an unregistered service or with inconsistent Service Types.
MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
and does not support it.
REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a
DA more frequently than the DA"s min-refresh-interval.
8. Required SLP Messages
All length fields in SLP messages are in network byte order. Where "
tuples" are defined, these are sequences of bytes, in the precise
order listed, in network byte order.
SLP messages all begin with the following header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Function-ID Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length, contd.OFR reserved Next Ext Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Extension Offset, contd. XID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Language Tag Length Language Tag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type Abbreviation Function-ID
Service Request SrvRqst 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Deregister SrvDeReg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
DA Advertisement DAAdvert 8
Service Type Request SrvTypeRqst 9
Service Type Reply SrvTypeRply 10
SA Advertisement SAAdvert 11
SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST
also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support
for other messages are OPTIONAL.
- Length is the length of the entire SLP message, header included.
- The flags are: OVERFLOW (0x80) is set when a message"s length
exceeds what can fit into a datagram. FRESH (0x40) is set on
every new SrvReg. REQUEST MCAST (0x20) is set when multicasting
or broadcasting requests. Reserved bits MUST be 0.
- Next Extension Offset is set to 0 unless extensions are used.
The first extension begins at "offset" bytes, from the message"s
beginning. It is placed after the SLP message data. See
Section 9.1 for how to interpret unrecognized SLP Extensions.
- XID is set to a unique value for each unique request. If the
request is retransmitted, the same XID is used. Replies set
the XID to the same value as the xid in the request. Only
unsolicited DAAdverts are sent with an XID of 0.
- Lang Tag Length is the length in bytes of the Language Tag field.
- Language Tag conforms to [7]. The Language Tag in a reply MUST
be the same as the Language Tag in the request. This field must
be encoded 1*8ALPHA *("-" 1*8ALPHA).
If an option is specified, and not included in the message, the
receiver MUST respond with a PARSE_ERROR.
8.1. Service Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Location header (function = SrvRqst = 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of <PRList> <PRList> String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of <service-type> <service-type> String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of <scope-list> <scope-list> String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of predicate string Service Request <predicate>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of <SLP SPI> string <SLP SPI> String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order for a Service to match a SrvRqst, it must belong to at least
one requested scope, support the requested service type, and match
the predicate. If the predicate is present, the language of the
request (ignoring the dialect part of the Language Tag) must match
the advertised service.
<PRList> is the Previous Responder List. This <string-list> contains
dotted decimal notation IP (v4) addresses, and is iteratively
multicast to obtain all possible results (see Section 6.3). UAs
SHOULD implement this discovery algorithm. SAs MUST use this to
discover all available DAs in their scope, if they are not already
configured with DA addresses by some other means.
A SA silently drops all requests which include the SA"s address in
the <PRList>. An SA which has multiple network interfaces MUST check
if any of the entries in the <PRList> equal any of its interfaces.
An entry in the PRList which does not conform to an IPv4 dotted
decimal address is ignored: The rest of the <PRList> is processed
normally and an error is not returned.
Once a <PRList> plus the request exceeds the path MTU, multicast
convergence stops. This algorithm is not intended to find all
instances; it finds "enough" to provide useful results.
The <scope-list> is a <string-list> of configured scope names. SAs
and DAs which have been configured with any of the scopes in this
list will respond. DAs and SAs MUST reply to unicast requests with a
SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to
include a scope they support (see Section 11). The only exceptions
to this are described in Section 11.2.
The <service-type> string is discussed in Section 4. Normally, a
SrvRqst elicits a SrvRply. There are two exceptions: If the
<service-type> is set to "service:directory-agent", DAs respond to
the SrvRqst with a DAAdvert (see Section 8.5.) If set to
"service:service-agent", SAs respond with a SAAdvert (see Section
8.6.) If this field is omitted, a PARSE_ERROR is returned - as this
field is REQUIRED.
The <predicate> is a LDAPv3 search filter [14]. This field is
OPTIONAL. Services may be discovered simply by type and scope.
Otherwise, services are discovered which satisfy the <predicate>. If
present, it is compared to each registered service. If the attribute
in the filter has been registered with multiple values, the filter is
compared to each value and the results are ORed together, i.e.,
"(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches
(y=0,1) since Y can be nonzero. Note the matching is case
insensitive. Keywords (i.e., attributes without values) are matched
with a "presence" filter, as in "(keyword=*)".
An incoming request term MUST have the same type as the attribute in
a registration in order to match. Thus, "(x=33)" will not match "
x=true", etc. while "(y=foo)" will match "y=FOO".
"((x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be
satisfied, because of the `" (boolean disjunction).
Wildcard matching MUST be done with the "=" filter. In any other
case, a PARSE_ERROR is returned. Request terms which include
wildcards are interpreted to be Strings. That is, (x=34*) would
match "x=34foo", but not "x=3432" since the first value is a String
while the second value is an Integer; Strings don"t match Integers.
Examples of Predicates follow. <t> indicates the service type of the
SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.
<t>=service:http <s>=DEFAULT <p>= (empty string)
This is a minimal request string. It matches all http
services advertised with the default scope.
<t>=service:pop3 <s>=SALES,DEFAULT <p>=(user=wump)
This is a request for all pop3 services available in
the SALES or DEFAULT scope which serve mail to the user
`wump".
<t>=service:backup <s>=BLDG 32 <p>=(&(q<=3)(speed>=1000))
This returns the backup service which has a queue length
less than 3 and a speed greater than 1000. It will
return this only for services registered with the BLDG 32
scope.
<t>=service:directory-agent <s>=DEFAULT <p>=
This returns DAAdverts for all DAs in the DEFAULT scope.
DAs are discovered by sending a SrvRqst with the service type set to
"service:directory-agent". If a predicate is included in the
SrvRqst, the DA SHOULD respond only if the predicate can be satisfied
with the DA"s attributes. The <scope-list> MUST contain all scopes
configured for the UA or SA which is discovering DAs.
The <SLP SPI> string indicates a SLP SPI that the requester has been
configured with. If this string is omitted, the responder does not
include any Authentication Blocks in its reply. If it is included,
the responder MUST return a reply which has an associated
authentication block with the SLP SPI in the SrvRqst. If no replies
may be returned because the SLP SPI is not supported, the responder
returns an AUTHENTICATION_UNKNOWN error.
8.2. Service Reply
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Location header (function = SrvRply = 2)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code URL Entry count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<URL Entry 1> ... <URL Entry N>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service reply contains zero or more URL entries (see Section
4.3). A service reply with zero URL entries MUST be returned in
response to a unicast Service Request, if no matching URLs are
present. A service reply with zero URL entries MUST NOT be sent in
response to a multicast or broadcast service request (instead, if
there was no match found or an error processing the request, the
service reply should not be generated at all).
If the reply overflows, the UA MAY simply use the first URL Entry in
the list. A URL obtained by SLP may not be cached longer than
Lifetime seconds, unless there is a URL Authenticator block present.
In that case, the cache lifetime is indicated by the Timestamp in the
URL Authenticator (see Section 9.2).
An authentication block is returned in the URL Entries, including the
SLP SPI in the SrvRqst. If no SLP SPI was included in the request,
no Authentication Blocks are returned in the reply. URL
Authentication Blocks are defined in Section 9.2.1.
If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless
it fits entirely without truncation.
8.3. Service Registration
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Location header (function = SrvReg = 3)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<URL-Entry>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of service type string <service-type>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of <scope-list> <scope-list>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length of attr-list string <attr-list>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# of AttrAuths (if present) Attribute Authentication Blocks...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <entry> is a URL Entry (see section 4.3). The Lifetime defines
how long a DA can cache the registration. SAs SHOULD reregister
before this lifetime expires (but SHOULD NOT more often than once per
second). The Lifetime MAY be set to any value between 0 and 0xffff
(maximum, around 18 hours). Long-lived registrations remain stale
longer if the service fails and the SA does not deregister the
service.
The <service-type> defines the service type of the URL to be
registered, regardless of the scheme of the URL. The <scope-list>
MUST contain the names of all scopes configured for the SA, which the
DA it is registering with supports. The default value for the
<scope-list> is "DEFAULT" (see Section 11).
The SA MUST register consistently with all DAs. If a SA is
configured with scopes X and Y and there are three DAs, whose scopes
are "X", "Y" and "X,Y" respectively, the SA will register the with
all three DAs in their respective scopes. All future updates and
deregistrations of the service must be sent to the same set of DAs in
the same scopes the service was initially registered in.
The <attr-list>, if present, specifies the attributes and values to
be associated with the URL by the DA (see Section 5).
A SA configured with the ability to sign service registrations MUST
sign each of the URLs and Attribute Lists using each of the keys it
is configured to use, and the DA it is registering with accepts.
(The SA MUST acquire DAAdverts for all DAs it will register with to
obtain the DA"s SLP SPI list and attributes, as described in Section
8.5). The SA supplies a SLP SPI in each authentication block
indicating the SLP SPI configuration required to verify the digital
signature. The format of the digital signatures used is defined in
section 9.2.1.
Subsequent registrations of previously registered services MUST
contain the same list of SLP SPIs as previous ones or else DAs will
reject them, replying with an AUTHENTICATION_ABSENT error.
A registration with the FRESH flag set will replace *entirely* any
previous registration for the same URL in the same language. If the
FRESH flag is not set, the registration is an "incremental"
registration (see Section 9.3).
8.4. Service Acknowledgment
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Location header (function = SrvAck = 5)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DA returns a SrvAck to an SA after a SrvReg. It carries only a two
byte Error Code (see Section 7).
8.5. Directory Agent Advertisement
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Location header (function = DAAdvert = 8)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code DA Stateless Boot Timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DA Stateless Boot Time,, contd. Length of URL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
URL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of <scope-list> <scope-list>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of <attr-list> <attr-list>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of <SLP SPI List> <SLP SPI List> String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# Auth Blocks Authentication block (if any)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code is set to 0 when the DAAdvert is multicast. If the
DAAdvert is being returned due to a unicast SrvRqst (ie. a request
without the REQUEST MCAST flag set) the DA returns the same errors a
SrvRply would.
The <scope-list> of the SrvRqst must either be omitted or include a
scope which the DA supports. The DA Stateless Boot Timestamp
indicates the state of the DA (see section 12.1).
The DA MAY include a list of its attributes in the DAAdvert. This
list SHOULD be kept short, as the DAAdvert must fit into a datagram
in order to be multicast.
A potential scaling problem occurs in SLPv2 if SAs choose too low a
Lifetime. In this case, an oNerous amount of reregistration occurs
as more services are deployed. SLPv2 allows DAs to control SAs
frequency of registration. A DA MAY reissue a DAAdvert with a new
set of attributes at any time, to change the reregistration behavior
of SAs. These apply only to subsequent registrations; existing
service registrations with the DA retain their registered lifetimes.
If the DAAdvert includes the attribute "min-refresh-interval" it MUST
be set to a single Integer value indicating a number of seconds. If
this attribute is present SAs MUST NOT refresh any particular service
advertisement more frequently than this value. If SrvReg with the
FRESH FLAG not set or SrvDereg with a non-empty tag list updating a
particular service are received more often than the value for the
DA"s advertised "min-refresh-interval" attribute the DA SHOULD reject
the message and return a REFRESH_REJECTED error in the SrvAck.
The URL is "service:directory-agent://"<addr> of the DA, where <addr>
is the dotted decimal numeric address of the DA. The <scope-list> of
the DA MUST NOT be NULL.
The SLP SPI List is the list of SPIs that the DA is capable of
verifying. SAs MUST NOT register services with authentication blocks
for those SLP SPIs which are not on the list. DAs will reject
service registrations which they cannot verify, returning an
AUTHENTICATION_UNKNOWN error.
The format of DAAdvert signatures is defined in Section 9.2.1.
The SLP SPI which is used to verify the DAAdvert is included in the
Authentication Block. When DAAdverts are multicast, they may have to
transmit multiple DAAdvert Authentication Blocks. If the DA is
configured to be able to generate signatures for more than one SPI,
the DA MUST include one Authentication Block for each SPI. If all
these Authentication Blocks do not fit in a single datagram (to
multicast or broadcast) the DA MUST send separate DAAdverts so that
Authentication Blocks for all the SPIs the DA is capable of
generating are sent.
If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert
contains only the authentication block with the SLP SPI in the
SrvRqst, if the DA is configured to be able to produce digital
signatures using that SLP SPI. If the SrvRqst is unicast to the DA
(the REQUEST MCAST flag in the header is not set) and an unsupported
SLP SPI is included, the DA replies with a DAAdvert with the Error
Code set to an AUTHENTICATION_UNKNOWN error.
UAs SHOULD be configured with SLP SPIs that will allow them to verify
DA Advertisements. If the UA is configured with SLP SPIs and
receives a DAAdvert which fails to be verified using one of them, the
UA MUST discard it.
8.6. Service Agent Advertisement
User Agents MUST NOT solicit SA Advertisements if they have been
configured to use a particular DA, if they have been configured with
a <scope-list> or if DAs have been discovered. UAs solicit SA
Advertisements only when they are explicitly configured to use User
Selectable scopes (see Section 11.2) in order to discover the scopes
that SAs support. This allows UAs without scope configuration to
make use of either DAs or SAs without any functional difference
except performance.
A SA MAY be configured with attributes, and SHOULD support the
attribute "service-type" whose value is all the service types of
services represented by the SA. SAs MUST NOT respond if the SrvRqst
predicate is not satisfied. For example, only SAs offering "nfs"
services SHOULD respond with a SAAdvert to a SrvRqst for service type
"service:service-agent" which includes a predicate "(service-
type=nfs)".
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Location header (function = SAAdvert = 11)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of URL URL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of <scope-list> <scope-list>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of <attr-list> <attr-list>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# auth blocks authentication block (if any)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SA responds only to multicast SA discovery requests which either
include no <scope-list> or a scope which they are configured to use.
The SAAdvert MAY include a list of attributes the SA supports. This
attribute list SHOULD be kept short so that the SAAdvert will not
exceed the path MTU in size.
The URL is "service:service-agent://"<addr> of the SA, where <addr>
is the dotted decimal numeric address of the SA. The <scope-list> of
the SA MUST NOT be null.
The SAAdvert contains one SAAdvert Authentication block for each SLP
SPI the SA can produce Authentication Blocks for. If the UA can
verify the Authentication Block of the SAAdvert, and the SAAdvert
fails to be verified, the UA MUST discard it.
9. Optional Features
The features described in this section are not mandatory. Some are
useful for interactive use of SLP (where a user rather than a program
will select services, using a browsing interface for example) and for
scalability of SLP to larger networks.
9.1. Service Location Protocol Extensions
The format of a Service Location Extension is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extension ID Next Extension Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offset, contd. Extension Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extension IDs are assigned in the following way:
0x0000-0x3FFF Standardized. Optional to implement. Ignore if
unrecognized.
0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA
which receives this option in a reply and does not understand
it MUST silently discard the reply. A DA or SA which receives
this option in a request and does not understand it MUST return
an OPTION_NOT_UNDERSTOOD error.
0x8000-0x8FFF For private use (not standardized). Optional to
implement. Ignore if unrecognized.
0x9000-0xFFFF Reserved.
The three byte offset to next extension indicates the position of the
next extension as offset from the beginning of the SLP message.
The offset value is 0 if there are no extensions following the
current extension.
If the offset is 0, the length of the current Extension Data is
determined by subtracting total length of the SLP message as given in
the SLP message header minus the offset of the current extension.
Extensions defined in this document are in Section D. See section 15
for procedures that are required when specifying new SLP extensions.
9.2. Authentication Blocks
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Block Structure Descriptor Authentication Block Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SLP SPI String Length SLP SPI String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Structured Authentication Block ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication blocks are returned with certain SLP messages to
verify that the contents have not been modified, and have been
transmitted by an authorized agent. The authentication data
(contained in the Structured Authentication Block) is typically case
sensitive. Even though SLP registration data (e.g., attribute
values) are typically are not case sensitive, the case of the
registration data has to be preserved by the registering DA so that
UAs will be able to verify the data used for calculating digital
signature data.
The Block Structure Descriptor (BSD) identifies the format of the
Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained
by IANA. BSDs 0x8000-0x8FFF are for private use.
The Authentication Block Length is the length of the entire block,
starting with the BSD.
The Timestamp is the time that the authenticator expires (to prevent
replay attacks.) The Timestamp is a 32-bit unsigned fixed-point
number of seconds relative to 0h on 1 January 1970. SAs use this
value to indicate when the validity of the digital signature expires.
This Timestamp will wrap back to 0 in the year 2106. Once the value
of the Timestamp wraps, the time at which the Timestamp is relative
to resets. For example, after 06h28 and 16 seconds 5 February 2106,
all Timestamp values will be relative to that epoch date.
The SLP Security Parameters Index (SPI) string identifies the key
length, algorithm parameters and keying material to be used by agents
to verify the signature data in the Structured Authentication Block.
The SLP SPI string has the same grammar as the <scope-val> defined in
Section 6.4.1.
Reserved characters in SLP SPI strings must be escaped using the same
convention as used throughout SLPv2.
SLP SPIs deployed in a site MUST be unique. An SLP SPI used for
BSD=0x0002 must not be the same as used for some other BSD.
All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST
register services with DSA authentication blocks, and they MAY
register them with other authentication blocks using other
algorithms. SAs MUST use DSA authentication blocks in SrvDeReg
messages and DAs MUST use DSA authentication