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 blocks in unsolicited
DAAdverts.
9.2.1. SLP Message Authentication Rules
The sections below define how to calculate the value to apply to the
algorithm identified by the BSD value. The components listed are
used as if they were a contiguous single byte aligned buffer in the
order given.
URL
16-bit Length of SLP SPI String, SLP SPI String.
16-bit Length of URL, URL,
32-bit Timestamp.
Attribute List
16-bit Length of SLP SPI String, SLP SPI String,
16-bit length of <attr-list>, <attr-list>,
32-bit Timestamp.
DAAdvert
16-bit Length of SLP SPI String, SLP SPI String,
32-bit DA Stateless Boot Timestamp,
16-bit Length of URL, URL,
16-bit Length of <attr-list>, <attr-list>,
16-bit Length of DA's <scope-list>, DA's <scope-list>,
16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>,
32-bit Timestamp.
The first SLP SPI is the SLP SPI in the Authentication
Block. This SLP SPI indicates the keying material and other
parameters to use to verify the DAAdvert. The SLP SPI List is
the list of SLP SPIs the DA itself supports, and is able to
verify.
SAAdvert
16-bit Length of SLP SPI String, SLP SPI String,
16-bit Length of URL, URL,
16-bit Length of <attr-list>, <attr-list>,
16-bit Length of <scope-list>, <scope-list>,
32-bit Timestamp.
9.2.2 DSA with SHA-1 in Authentication Blocks
BSD=0x0002 is defined to be DSA with SHA-1. The signature
calculation is defined by [20]. The signature format conforms to
that in the X.509 v3 certificate:
1. The signature algorithm identifier (an OID)
2. The signature value (an octet string)
3. The certificate path.
All data is represented in ASN.1 encoding:
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately
by:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
i.e., the binary ASN.1 encoding of r and s computed using DSA and
SHA-1. This is followed by a certificate path, as defined by X.509
[10], [2], [3], [4], [5].
Authentication Blocks for BSD=0x0002 have the following format. In
the future, BSDs may be assigned which have different formats.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 encoded DSA signature \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.3. Incremental Service Registration
Incremental registrations update attribute values for a previously
registered service. Incremental service registrations are useful
when only a single attribute has changed, for instance. In an
incremental registration, the FRESH flag in the SrvReg header is NOT
set.
The new registration's attributes replace the previous
registration's, but do not affect attributes which were included
previously and are not present in the update.
For example, suppose service:x://a.org has been registered with
attributes A=1, B=2, C=3. If an incremental registration comes for
service:x://a.org with attributes C=30, D=40, then the attributes for
the service after the update are A=1, B=2, C=30, D=40.
Incremental registrations MUST NOT be performed for services
registered with Authentication Blocks. These must be registered with
ALL attributes, with the FRESH flag in the SrvReg header set. DAs
which receive such registration messages return an
AUTHENTICATION_FAILED error.
If the FRESH flag is not set and the DA does not have a prior
registration for the service, the incremental registration fails with
error code INVALID_UPDATE.
The SA MUST use the same <scope-list> in an update message as was
used in the prior registration. If this is not done, the DA returns
a SCOPE_NOT_SUPPORTED error. In order to change the scope of a
service advertisement it MUST be deregistered first and reregistered
with a new <scope-list>.
The SA MUST use the same <service-type> in an update message as was
used in a prior registration of the same URL. If this is not done,
the DA returns an INVALID_UPDATE error.
9.4. Tag Lists
Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a
<tag-list> item is:
tag-filter = simple-tag / substring
simple-tag = 1*filt-char
substring = [initial] any [final]
initial = 1*filt-char
any = `*' *(filt-char `*')
final = 1*filt-char
filt-char = Any character excluding <reserved> and <bad-tag> (see
grammar in Section 5).
Wild card characters in a <tag-list> item match arbitrary sequences
of characters. For instance "*bob*" matches "some bob I know",
"bigbob", "bobby" and "bob".
10. Optional SLP Messages
The additional requests provide features for user interaction and for
efficient updating of service advertisements with dynamic attributes.
10.1. Service Type Request
The Service Type Request (SrvTypeRqst) allows a UA to discover all
types of service on a network. This is useful for general purpose
service browsers.
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 = SrvTypeRqst = 9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of Naming Authority | <Naming Authority String> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <PRList> list and <scope-list> are interpreted as in Section 8.1.
The Naming Authority string, if present in the request, will limit
the reply to Service Type strings with the specified Naming
Authority. If the Naming Authority string is absent, the IANA
registered service types will be returned. If the length of the
Naming Authority is set to 0xFFFF, the Naming Authority string is
omitted and ALL Service Types are returned, regardless of Naming
Authority.
10.2. Service Type 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 = SrvTypeRply = 10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <srvType-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <srvtype--list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service-type Strings (as described in Section 4.1) are provided
in <srvtype-list>, which is a <string-list>.
If a service type has a Naming Authority other than IANA it MUST be
returned following the service type string and a `.' character.
Service types with the IANA Naming Authority do not include a Naming
Authority string.
10.3. Attribute Request
The Attribute Request (AttrRqst) allows a UA to discover attributes
of a given service (by supplying its URL) or for an entire service
type. The latter feature allows the UA to construct a query for an
available service by selecting desired features. The UA may request
that all attributes are returned, or only a subset of them.
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 = AttrRqst = 6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <tag-list> string | <tag-list> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in
Section 8.1.
The URL field can take two forms. It can simply be a Service Type
(see Section 4.1), such as "http" or "service:tftp". In this case,
all attributes and the full range of values for each attribute of all
services of the given Service Type is returned.
The URL field may alternatively be a full URL, such as
"service:printer:lpr://igore.wco.ftp.com:515/draft" or
"nfs://max.net/znoo". In this, only the registered attributes for
the specified URL are returned.
The <tag-list> field is a <string-list> of attribute tags, as defined
in Section 9.4 which indicates the attributes to return in the
AttrRply. If <tag-list> is omitted, all attributes are returned.
<tag-list> MUST be omitted and a full URL MUST be included when
attributes when a SLP SPI List string is included, otherwise the DA
will reply with an AUTHENTICATION_FAILED error.
10.4. Attribute 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 = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths | Attribute Authentication Block (if present) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the <attr-list> and the Authentication Block is as
specified for SrvReg (see Section 9.2.1).
Attribute replies SHOULD be returned with the original case of the
string registration intact, as they are likely to be human readable.
In the case where the AttrRqst was by service type, all attributes
defined for the service type, and all their values are returned.
Although white space is folded for string matching, attribute tags
and values MUST be returned with their original white space
preserved.
Only one copy of each attribute tag or String value should be
returned, arbitrarily choosing one version (with respect to upper and
lower case and white space internal to the strings): Duplicate
attributes and values SHOULD be removed. An arbitrary version of the
string value and tag name is chosen for the merge. For example:
"(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)".
10.5. Attribute Request/Reply Examples
Suppose that printer services have been registered as follows:
Registered Service:
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = en
Attributes = (Name=Igore),(Description=For developers only),
(Protocol=LPR),(location-description=12th floor),
(Operator=James Dornan \3cdornan@monster\3e),
(media-size=na-letter),(resolution=res-600),x-OK
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
(Protocol=LPR),(location-description=13te Etage),
(Operator=James Dornan \3cdornan@monster\3e),
(media-size=na-letter),(resolution=res-600),x-OK
URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn
scope-list = Development
Lang. Tag = en
Attributes = (Name=Not),(Description=Experimental IPP printer),
(Protocol=http),(location-description=QA bench),
(media-size=na-letter),(resolution=other),x-BUSY
Notice the first printer, "Igore" is registered in both English and
German. The `<' and `>' characters in the Operator attribute value
which are part of the Email address had to be escaped, as they are
reserved characters for values.
Attribute tags are not translated, though attribute values may be,
see [13].
The attribute Request:
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
tag-list = resolution,loc*
receives the Attribute Reply:
(location-description=13te Etage),(resolution=res-600)
The attribute Request:
URL = service:printer
scope-list = Development
Lang. Tag = en
tag-list = x-*,resolution,protocol
receives an Attribute Reply containing:
(protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY
The first request is by service instance and returns the requested
values, in German. The second request is by abstract service type
(see Section 4) and returns values from both "Igore" and "Not".
An attribute Authentication Block is returned if an authentication
block with the SLP SPI in the AttrRqst can be returned. Note that
the <attr-list> returned from a DA with an Authentication Block MUST
be identical to the <attr-list> registered by a SA, in order for the
authentication verification calculations to be possible.
A SA or DA only returns an Attribute Authentication Block if the
AttrRqst included a full URL in the request and no tag list.
If an SLP SPI is specified in a unicast request (the REQUEST MCAST
flag in the header is not set) and the SA or DA cannot return an
Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN
error is returned. The # of Attr Auths field is set to 0 if there no
Authentication Block is included, or 1 if an Authentication Block
follows.
10.6. Service Deregistration
A DA deletes a service registration when its Lifetime expires.
Services SHOULD be deregistered when they are no longer available,
rather than leaving the registrations to time out.
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 = SrvDeReg = 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL Entry \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <tag-list> | <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <scope-list> is a <string-list> (see section 2.1).
The SA MUST retry if there is no response from the DA, see Section
12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA
receives an acknowledgment indicating success, the service and/or
attributes are no longer advertised by the DA. The DA deregisters the
service or service attributes from every scope specified in the
SrvDeReg which it was previously registered in.
The SA MUST deregister all services with the same scope list used to
register the service with a DA. If this is not done in the SrvDeReg
message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime
field in the URL Entry is ignored for the purposes of the SrvDeReg.
The <tag-list> is a <string-list> of attribute tags to deregister as
defined in Section 9.4. If no <tag-list> is present, the SrvDeReg
deregisters the service in all languages it has been registered in.
If the <tag-list> is present, the SrvDeReg deregisters the attributes
whose tags are listed in the tag spec. Services registered with
Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg
message: A DA will respond with an AUTHENTICATION_FAILED error in
this case.
If the service to be deregistered was registered with an
authentication block or blocks, a URL authentication block for each
of the SLP SPIs registered must be included in the SrvDeReg.
Otherwise, the DA returns an AUTHENTICATION_ABSENT error. If the
message fails to be verified by the DA, an AUTHENTICATION_FAILED
error is returned by the DA.
11. Scopes
Scopes are sets of services. The primary use of Scopes is to provide
the ability to create administrative groupings of services. A set of
services may be assigned a scope by network administrators. A client
seeking services is configured to use one or more scopes. The user
will only discover those services which have been configured for him
or her to use. By configuring UAs and SAs with scopes,
administrators may provision services. Scopes strings are case
insensitive. The default SCOPE string is "DEFAULT".
Scopes are the primary means an administrator has to scale SLP
deployments to larger networks. When DAs with NON-DEFAULT scopes are
present on the network, further gains can be had by configuring UAs
and SAs to have a predefined non-default scope. These agents can
then perform DA discovery and make requests using their scope. This
will limit the number of replies.
11.1. Scope Rules
SLP messages which fail to contain a scope that the receiving Agent
is configured to use are dropped (if the request was multicast) or a
SCOPE_NOT_SUPPORTED error is returned (if the request was unicast).
Every SrvRqst (except for DA and SA discovery requests), SrvReg,
AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a
<scope-list>.
A UA MUST unicast its SLP messages to a DA which supports the desired
scope, in preference to multicasting a request to SAs. A UA MAY
multicast the request if no DA is available in the scope it is
configured to use.
11.2. Administrative and User Selectable Scopes
All requests and services are scoped. The two exceptions are
SrvRqsts for "service:directory-agent" and "service:service-agent".
These MAY have a zero-length <scope-list> when used to enable the
user to make scope selections. In this case UAs obtain their scope
list from DAAdverts (or if DAs are not available, from SAAdverts.)
Otherwise, if SAs and UAs are to use any scope other than the default
(i.e., "DEFAULT"), the UAs and SAs are configured with lists of
scopes to use by system administrators, perhaps automatically by way
of DHCP option 78 or 79 [21]. Such administrative scoping allows
services to be provisioned, so that users will only see services they
are intended to see.
User configurable scopes allow a user to discover any service, but
require them to do their own selection of scope. This is similar to
the way AppleTalk [12] and SMB [19] networking allow user selection
of AppleTalk Zone or workgroups.
Note that the two configuration choices are not compatible. One
model allows administrators control over service provision. The
other delegates this to users (who may not be prepared to do any
configuration of their system).
12. Directory Agents
DAs cache service location and attribute information. They exist to
enhance the performance and scalability of SLP. Multiple DAs provide
further scalability and robustness of operation, since they can each
store service information for the same SAs, in case one of the DAs
fails.
A DA provides a centralized store for service information. This is
useful in a network with several subnets or with many SLP Agents.
The DA address can be dynamically configured with UAs and SAs using
DHCP, or by using static configuration.
SAs configured to use DAs with DHCP or static configuration MUST
unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst
omits the scope list and sets the service type of the request to
"service:directory-agent". The DA will return a DAAdvert with its
attributes, SLP SPI list, and other parameters which are essential
for proper SA to DA communication.
Passive detection of DAs by SAs enables services to be advertised
consistently among DAs of the same scope. Advertisements expire if
not renewed, leaving only transient stale registrations in DAs, even
in the case of a failure of a SA.
A single DA can support many UAs. UAs send the same requests to DAs
that they would send to SAs and expect the same results. DAs reduce
the load on SAs, making simpler implementations of SAs possible.
UAs MUST be prepared for the possibility that the service information
they obtain from DAs is stale.
12.1. Directory Agent Rules
When DAs are present, each SA MUST register its services with DAs
that support one or more of its scope(s).
UAs MUST unicast requests directly to a DA (when scoping rules
allow), hence avoiding using the multicast convergence algorithm, to
obtain service information. This decreases network utilization and
increases the speed at which UAs can obtain service information.
DAs MUST flush service advertisements once their lifetime expires or
their URL Authentication Block "Timestamp" of expiration is past.
DAAdverts MUST include DA Stateless Boot Timestamp, in the same
format as the Authentication Block (see Section 9.2). The Timestamp
in the Authentication Block indicates the time at which all previous
registrations were lost (i.e., the last stateless reboot). The
Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA
is going down. DAs MUST NOT use equal or lesser Boot Timestamps to
previous ones, if they go down and restart without service
registration state. This would mislead SAs to not reregister with
the DA.
DAs which receive a multicast SrvRqst for the service type
"service:directory-agent" MUST silently discard it if the <scope-
list> is (a) not omitted and (b) does not include a scope they are
configured to use. Otherwise the DA MUST respond with a DAAdvert.
DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are
OPTIONAL only for SAs, not DAs.)
12.2. Directory Agent Discovery
UAs can discover DAs using static configuration, DHCP options 78 and
79, or by multicasting (or broadcasting) Service Requests using the
convergence algorithm in Section 6.3.
See Section 6 regarding unsolicited DAAdverts. Section 12.2.2
describes how SAs may reduce the number of times they must reregister
with DAs in response to unsolicited DAAdverts.
DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An
unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts,
passively, as described in Section 8.5. UAs MAY do this. If they do
not listen for unsolicited DAAdverts, however, they will not discover
DAs as they become available. UAs SHOULD, in this case, do periodic
active DA discovery, see Section 6.
A URL with the scheme "service:directory-agent" indicates the DA's
location as defined in Section 8.5. For example:
"service:directory-agent://foobawooba.org".
The following sections suggest timing algorithms which enhance the
scalability of SLP.
12.2.1. Active DA Discovery
After a UA or SA restarts, its initial DA discovery request SHOULD be
delayed for some random time uniformly distributed from 0 to
CONFIG_START_WAIT seconds.
The UA or SA sends the DA Discovery request using a SrvRqst, as
described in Section 8.1. DA Discovery requests MUST include a
Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT
be sent more than once per CONFIG_DA_FIND seconds.
After discovering a new DA, a SA MUST wait a random time between 0
and CONFIG_REG_ACTIVE seconds before registering their services.
12.2.2. Passive DA Advertising
A DA MUST multicast (or broadcast) an unsolicited DAAdvert every
CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to
prevent DAAdverts from using more than 1% of the available bandwidth.
All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine
its DA stateless Boot Timestamp. If it is set to 0, the DA is going
down and no further messages should be sent to it.
If a SA detects a DA it has never encountered (with a nonzero
timestamp,) the SA must register with it. SAs MUST examine the
DAAdvert's timestamp to determine if the DA has had a stateless
reboot since the SA last registered with it. If so it registers with
the DA. SAs MUST wait a random interval between 0 and
CONFIG_REG_PASSIVE before beginning DA registration.
12.3. Reliable Unicast to DAs and SAs
If a DA or SA fails to respond to a unicast UDP message in
CONFIG_RETRY seconds, the message should be retried. The wait
interval for each subsequent retransmission MUST exponentially
increase, doubling each time. If a DA or SA fails to respond after
CONFIG_RETRY_MAX seconds, the sender should consider the receiver to
have gone down. The UA should use a different DA. If no such DA
responds, DA discovery should be used to find a new DA. If no DA is
available, multicast requests to SAs are used.
12.4. DA Scope Configuration
By default, DAs are configured with the "DEFAULT" scope.
Administrators may add other configured scopes, in order to support
UAs and SAs in non default scopes. The default configuration MUST
NOT be removed from the DA unless:
- There are other DAs which support the "DEFAULT" scope, or
- All UAs and SAs have been configured with non-default scopes.
Non-default scopes can be phased-in as the SLP deployment grows.
Default scopes should be phased out only when the non-default scopes
are universally configured.
If a DA and SA are coresident on a host (quite possibly implemented
by the same process), configuration of the host is considerably
simplified if the SA supports only scopes also supported by the DA.
That is, the SA SHOULD NOT advertise services in any scopes which are
not supported by the coresident DA. This means that incoming requests
can be answered by a single data store; the SA and DA registrations
do not need to be kept separately.
12.5. DAs and Authentication Blocks
DAs are not configured to sign service registrations or attribute
lists. They simply cache services registered by Service Agents. DAs
MUST NOT accept registrations including authentication blocks for SLP
SPIs which it is not configured with, see Section 8.5.
A DA protects registrations which are made with authentication blocks
using SLP SPIs it is configured to use. If a service S is
registered, a subsequent registration (which will replace the
adertisement) or a deregistration (which will remove it) MUST include
an Authentication Block with the corresponding SLP SPI, see Section
8.3 and Section 10.6.
Example:
A DA is configured to be able to verify Authentication Blocks with
SLP SPIs "X,Y", that is X and Y.
An SA registers a service with an Authentication Block with SPI "Z".
The DA stores the registration, but discards the Authentication
Block. If a UA requests a service with an SLP SPI string "Z", the DA
will respond with an AUTHENTICATION_UNKNOWN error.
An SA registers a service S with Authentication Blocks including SLP
SPIs "X" and "Y". If a UA requests a service with an SLP SPI string
"X" the DA will be able to return S (if the service type, language,
scope and predicate of the SrvRqst match S) The DA will also return
the Authentication Block with SLP SPI set to "X". If the DA receives
a subsequent SrvDeReg for S (which will remove the advertisement) or
a subsequent SrvReg for S (which will replace it), the message must
include two URL Authentication Blocks, one each for SPIs "X" and "Y".
If either of these were absent, the DA would return an
AUTHENTICATION_ABSENT error.
13. Protocol Timing Defaults
Interval name Section Default Value Meaning
------------------- ------- ------------- ------------------------
CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a
complete multicast query
response (all values.)
CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA
discovery on reboot.
CONFIG_RETRY 12.3 2 seconds Wait interval before
initial retransmission
of multicast or unicast
requests.
CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast
request retransmission.
CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs
passively detect new DAs.
CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait
before repeating Active
DA discovery.
CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle
connections.
14. Optional Configuration
Broadcast Only
Any SLP agent SHOULD be configurable to use broadcast
only. See Sections 6.1 and 12.2.
Predefined DA
A UA or SA SHOULD be configurable to use a predefined DA.
No DA Discovery
The UA or SA SHOULD be configurable to ONLY use
predefined and DHCP-configured DAs and perform no active
or passive DA discovery.
Multicast TTL
The default multicast TTL is 255. Agents SHOULD be
configurable to use other values. A lower value will
focus the multicast convergence algorithm on smaller
subnetworks, decreasing the number of responses and
increases the performance of service location. This
may result in UAs obtaining different results for the
identical requests depending on where they are connected
to the network.
Timing Values
Time values other than the default MAY be configurable.
See Section 13.
Scopes
A UA MAY be configurable to support User Selectable
scopes by omitting all predefined scopes. See
Section 11.2. A UA or SA MUST be configurable to use
specific scopes by default. Additionally, a UA or SA
MUST be configurable to use specific scopes for requests
for and registrations of specific service types. The
scope or scopes of a DA MUST be configurable. The
default value for a DA is to have the scope "DEFAULT" if
not otherwise configured.
DHCP Configuration
DHCP options 78 and 79 may be used to configure SLP. If
DA locations are configured using DHCP, these SHOULD
be used in preference to DAs discovered actively or
passively. One or more of the scopes configured using
DHCP MUST be used in requests. The entire configured
<scope-list> MUST be used in registration and DA
configuration messages.
Service Template
UAs and SAs MAY be configured by using Service Templates.
Besides simplifying the specification of attribute
values, this also allows them to enforce the inclusion
of 'required' attributes in SrvRqst, SrvReg and SrvDeReg
messages. DAs MAY be configured with templates to
allow them to WARN UAs and SAs in these cases. See
Section 10.4.
SLP SPI for service discovery
Agents SHOULD be configurable to support SLP SPIs using
the following parameters: BSD=2 (DSA with SHA-1) and
a public key identified by the SLP SPI String. In
the future, when a Public Key Infrastructure exists,
SLP Agents may be able to obtain public keys and
cryptographic parameters corresponding to the names used
in SLP SPI Strings.
Note that if the SLP SPI string chosen is identical
to a scope string, it is effectively the same as a
Protected Scope in SLPv1. Namely, every SA advertising
in that scope would be configured with the same Private
Key. Every DA and UA of that scope would be configured
with the appropriate Public Key to verify signatures
produced by those SAs. This is a convenient way to
configure SLP deployments in the absence of a Public Key
Infrastructure. Currently, it would be too difficult to
manage the keying of UAs and DAs if each SA had its own
key.
SLP SPI for Directory Agent discovery
Agents SHOULD be configurable to support SLP SPIs as
above, to be used when discovering DAs. This SPI SHOULD
be sent in SrvRqsts to discover DAs and be used to verify
multicast DAAdvert messages.
SA and DA Private Key
SAs and DAs which can generate digital signatures require
a Private Key and a corresponding SLP SPI indentifier
to include in the Authentication Block. The SLP SPI
identifies the Public Key to use to verify the digital
signature in the Authentication Block.
15. IANA Considerations
SLP includes four sets of identifiers which may be registered with
IANA. The policies for these registrations (See [18]) are noted in
each case.
The Block Structure Descriptor (BSD) identifies the format of the
Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use.
Further Block Structured Descriptor (BSD) values, from the range
0x0003-0x7FFF may be standardized in the future by submitting a
document which describes:
- The data format of the Structured Authenticator block.
- Which cryptographic algorithm to use (including a reference
to a technical specification of the algorithm.)
- The format of any keying material required for
preconfiguring UAs, DAs and SAs. Also include any
considerations regarding key distribution.
- Security considerations to alert others to the strengths and
weaknesses of the approach.
The IANA will assign Cryptographic BSD numbers on the basis of IETF
Consenus.
New function-IDs, in the range 12-255, may be standardized by the
method of IETF Consensus.
New SLP Extensions with types in the range 2-65535 may be registered
following review by a Designated Expert.
New error numbers in the range 15-65535 are assigned on the basis of
a Standards Action.
Protocol elements used with Service Location Protocol may also
require IANA registration actions. SLP is used in conjunction with
"service:" URLs and Service Templates [13]. These are standardized
by review of a Designated Expert and a mailing list (See [13].)
16. Internationalization Considerations
SLP messages support the use of multiple languages by providing a
Language Tag field in the common message header (see Section 8).
Services MAY be registered in multiple languages. This provides
attributes so that users with different language skills may select
services interactively.
Attribute tags are not translated. Attribute values may be
translated unless the Service Template [13] defines the attribute
values to be 'literal'.
A service which is registered in multiple languages may be queried in
multiple languages. The language of the SrvRqst or AttrRqst is used
to satisfy the request. If the requested language is not supported,
a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply
messages are always in the same language of the request.
A DA or SA MAY be configured with translations of Service Templates
[13] for the same service type. This will allow the DA or SA to
translate a request (say in Italian) to the language of the service
advertisement (say in English) and then translate the reply back to
Italian. Similarly, a UA MAY use templates to translate outgoing
requests and incoming replies.
The dialect field in the Language Tag MAY be used: Requests which
can be fulfilled by matching a language and dialect will be preferred
to those which match only the language portion. Otherwise, dialects
have no effect on matching requests.
17. Security Considerations
SLP provides for authentication of service URLs and service
attributes. This provides UAs and DAs with knowledge of the