SLP select and sort: Select and Sort Extensions for the Service Location Protocol (SLP)
Ask SLP servers to limit and sort the list of matching services, not just return everything.
Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Select and Sort Extensions for the Service Location Protocol (SLP)", RFC 3421, DOI 10.17487/RFC3421, November 2002, <https://www.rfc-editor.org/info/rfc3421>.
@misc{rfc3421,
series = {Request for Comments},
number = 3421,
howpublished = {RFC 3421},
publisher = {RFC Editor},
doi = {10.17487/RFC3421},
url = {https://www.rfc-editor.org/info/rfc3421},
author = {W. Zhao and H. Schulzrinne and E. Guttman and C. Bisdikian and W. Jerome},
title = {{Select and Sort Extensions for the Service Location Protocol (SLP)}},
pagetotal = 8,
year = 2002,
month = nov,
} RFC text
Contents
Network Working Group W. Zhao
Request for Comments: 3421 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
November 2002
Select and Sort Extensions for the Service Location Protocol (SLP)
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines two extensions (Select and Sort) for the
Service Location Protocol (SLP). These extensions allow a User Agent
(UA) to request that the Uniform Resource Locator (URL) entries in a
Service Reply (SrvRply) be limited to the specified number, or be
sorted according to the specified sort key list. Using these two
extensions together can facilitate discovering the best match, such
as finding a service that has the maximum speed or the minimum load.
1. Introduction
This document defines two extensions (Select and Sort) for SLP
[RFC2608]. These extensions allow a UA to request that the URL
entries in a SrvRply be limited to the specified number, or be sorted
according to the specified sort key list. A Directory Agent (DA) or
Service Agent (SA) that supports the Select and/or Sort extensions
MUST include the attribute keyword "select-enabled" and/or "sort-
enabled" in its advertisement (DAAdvert or SAAdvert). A UA SHOULD
check these attributes of the contacting DA/SA before it uses the
Select and/or Sort extensions to query the DA/SA.
Using the Select extension, a UA can opt for finding just a few (not
necessarily all) matching services, which is useful if the UA uses a
low-bandwidth channel. Using the Sort extension, a UA can ask the
DA/SA to sort matching URL entries, which helps the UA to choose a
service from multiple candidates. Sorting by the server is more
efficient than sorting by the client since for sorting purposes, the
former does not need to pass the attributes of matching URLs to the
client. Furthermore, using the Select and Sort extensions together
can facilitate discovering the best match, such as finding a service
that has the maximum speed or the minimum load, or has a speed
closest to a reference value.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted according to in BCP 14, RFC 2119
[RFC2119].
2. Select Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Select Extension ID = 0x4002 | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, cont'd | Number of URL Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Select Extension
The format of the Select extension is shown in Figure 1. A UA uses
this extension in a Service Request (SrvRqst) to limit the maximum
number (say, n) of URL entries to be returned. When a DA/SA receives
a SrvRqst with a Select extension, it MUST use a Select extension in
the corresponding SrvRply to indicate the total number (say, m) of
matching URL entries if the DA/SA supports this extension, otherwise
the DA/SA MUST set the error code in the corresponding SrvRply to
OPTION_NOT_UNDERSTOOD [RFC2608]. If n < m, then only the first n
matching URL entries are returned, else all m matching URL entries
are returned. As a special case, a UA may set n to zero to obtain
the number of matching URL entries without retrieving the entries
themselves.
We denote a Select extension as Select(number). Thus, Select(3)
means that the corresponding SrvRply can have at most three URL
entries.
3. Sort Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sort Extension ID = 0x4003 | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, cont'd | length of <sort-key-list> |<sort-key-list>\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Sort Extension
The format of the Sort extension is shown in Figure 2. A UA uses
this extension in a SrvRqst to request the URL entries in the
corresponding SrvRply be sorted according to the sort-key-list. The
sort-key-list is defined using Augmented Backus-Naur Form (ABNF)
[RFC2234] as follows:
sort-key-list = sort-key / sort-key "," sort-key-list
sort-key = key-name ":" type ":" ordering [":" ref-value]
key-name = attr-tag from Section 5 of RFC 2608
type = "s" / "i"
; "s" for string type
; "i" for integer type
ordering = "+" / "-"
; "+" for increasing order
; "-" for decreasing order
ref-value = intval from Section 5 of RFC 2608
Each sort-key in the sort-key-list has a key-name, a type specifier,
an ordering specifier, and an optional reference value. The key-name
MUST be a valid attribute name, and its type is explicitly specified.
Although SLP has five attribute types (integer, string, boolean,
opaque and keyword), we only consider integer sort and string sort
since keyword attributes (they have no values) never need to be
sorted, and boolean and opaque attributes can be sorted as strings if
needed. The integer sort uses the integerOrderingMatch rule defined
in X.520 [X520], whereas the string sort is performed based on
lexical ordering. Strings are compared using the rules defined in
Section 6.4 of RFC 2608.
Only integer keys may have a reference value, causing the sort to be
based on the distance to the reference value. A reference-based
sort, such as "X:i:+:12", requires the following two steps:
Step 1. For each matching service, if its attribute X has a value of
x, then use |x-12| as its metric.
Step 2. Use the metrics obtained in Step 1 to sort attribute X
for matching services.
The SLP sort rules are adapted from the Lightweight Directory Access
Protocol (LDAP) sort rules defined in RFC 2891 [RFC2891]. Note that
sort in SLP is a best effort, no sort error will be returned from a
DA/SA to a UA.
(1) The sort-key-list is in order of highest to lowest sort key
precedence (Section 1.1 of RFC 2891).
(2) Each attribute SHOULD only occur in the sort-key-list once
(Section 1.1 of RFC 2891). If an attribute is included in the
sort-key-list multiple times, only its first occurrence is
considered, all other occurrences are ignored.
(3) For a multi-valued attribute, the least value in each entry
SHOULD be used in sort (Section 2.2 of RFC 2891).
(4) An entry missing one or more of the sort keys is treated as
having NULLs for those missing keys (Section 2.2 of RFC 2891).
(5) NULL is considered as a larger value than all other valid
values (Section 2.2 of RFC 2891).
(6) As the attribute type in SLP is not enforced, an attribute may
have inconsistent values. For the purpose of sorting,
inconsistent values may exist only when an attribute is
sorted as integer. Inconsistent values SHOULD be treated as
NULLs.
When a DA/SA receives a SrvRqst with a Sort extension, it MUST set
the error code in the corresponding SrvRply to OPTION_NOT_UNDERSTOOD
[RFC2608] if the DA/SA does not support the Sort extension or cannot
perform the requested sort. The DA/SA sets the error code in the
corresponding SrvRply to zero if it has successfully processed the
SrvRqst and performed the requested sort.
We denote a Sort extension as Sort(sort-key-list). The following
examples illustrate how to use the Sort extension.
o Integer sort on speed (decreasing order).
Sort(speed:i:-)
[Note] "i" means integer sort, and "-" means decreasing order.
o Integer sort on load (increasing order) and speed (decreasing
order).
Sort(load:i:+,speed:i:-)
[Note] "+" means increasing order.
o String sort on model (increasing order).
Sort(model:s:+)
[Note] "s" means string sort.
o Integer sort on speed (increasing order), based on a reference
value 12.
Sort(speed:i:+:12)
[Note] For example, if we have four matching services, with the
"speed" attribute as 8 (URL1), 10 (URL2), 12 (URL3), and 15 (URL4),
then the sorted URL list will be "URL3,URL2,URL4,URL1" (based on
the metric ordering of |12-12| < |12-10| < |12-15| < |12-8|).
4. Using the Select and Sort Extensions Together
In addition to being used individually, the Select and Sort
extensions can be used together to facilitate discovering the best
match, such as finding a service with the maximum speed. When these
two extensions appear in the same SrvRqst message, they MUST be
processed in the order of their presence. We show some examples
next.
o Find the service with the minimum load
Sort(load:i:+)
Select(1)
o Find the three fastest services
Sort(speed:i:-)
Select(3)
o Find the service with the minimum load among the three fastest
Sort(speed:i:-)
Select(3)
Sort(load:i:+)
Select(1)
o Find the service that has a speed closest to 12
Sort(speed:i:+:12)
Select(1)
5. IANA Considerations
The Select and Sort extension IDs, 0x4002 and 0x4003, described in
Section 2 and Section 3, respectively, have been assigned by IANA out
of the SLP extension space (RFC 2608, Section 9.1) reserved for
"mandatory to implement" extensions (i.e., the 0x4000-0x7FFF range).
6. Security Considerations
There are no new security issues beyond those described in RFC 2608.
7. Acknowledgments
Ira McDonald provided good suggestions.
8. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC 2119, March 1997.
9. Non-normative References
[X520] International Telephone Union, "The Directory: Selected
Attribute Types", X.520, 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2891] Howes, T., Wahl, M. and A. Anantha, "LDAP Control Extension
for Server Side Sorting of Search Results", RFC 2891,
August 2000.
10. Authors' Addresses
Weibin Zhao
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
EMail: zwb@cs.columbia.edu
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
EMail: hgs@cs.columbia.edu
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
EMail: Erik.Guttman@sun.com
Chatschik Bisdikian
IBM Corp.
Thomas J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532, USA
EMail: bisdik@us.ibm.com
William F. Jerome
IBM Corp.
Thomas J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532, USA
EMail: wfj@us.ibm.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1The Problem and Solution
Service Location Protocol (SLP) (RFC 2608) allows clients to discover services (like printers, file servers, or VoIP endpoints) on a network. A client sends a service request to a Directory Agent (DA) or Service Agent (SA), which replies with a list of all matching service URLs. However, this approach has drawbacks: if hundreds of services match, the client downloads a large list, and if the client has a low-bandwidth connection, this is costly. Also, the client must sort the results itself using service attributes, requiring those attributes to be transferred.
RFC 3421 defines two new SLP extensions: Select and Sort. The Select extension lets a client request only the first n matching service URLs. The Sort extension lets a client request that matching URLs be sorted by one or more attributes (such as speed or load). Sorting on the server side is more efficient than sorting on the client because the server can discard non-matching attributes before sending results.
Instead of getting all 500 results and sorting them yourself, you tell the server "give me only 5, and sort by speed first." The server does the work.
§2Select and Sort Extensions
The Select extension has extension ID 0x4002. It contains a number field: the client sets it to n to request at most n service URLs. If there are m matching URLs total and m is less than n, all m are returned. If m is greater than n, only the first n are returned. The response includes both the number of results returned and the total number of matching services available (even if not all are returned), so the client knows how many services matched in total.
As a special case, setting n to zero returns only the count of matching services without returning any actual service URLs. This allows a client to discover the number of available services without downloading the full list.
The Sort extension has extension ID 0x4003. It specifies a sort-key-list: a comma-separated list of sort keys. Each sort key has a key name (an attribute from the service advertisement), a type (string "s" or integer "i"), an ordering ("+" for increasing or "-" for decreasing), and optionally a reference value (for integer keys). For example, "speed:i:-" sorts by speed in decreasing order (fastest first), and "load:i:+:50" sorts by distance from a reference value of 50.
Select says "give me only the first 5 matches." Sort says "sort them by speed with the fastest first," or "sort by how close they are to speed 12."
- 0x4002Select extension — Limits the number of service URLs returned.
- 0x4003Sort extension — Requests server-side sorting of service URLs by specified attributes.
§3Sorting Rules and Combinations
SLP sorting follows rules adapted from LDAP (RFC 2891). The sort-key-list is ordered from highest to lowest precedence: the first key is the primary sort, the second key breaks ties, and so on. For multi-valued attributes, the least value in each entry is used for comparison. Attributes missing from a service are treated as NULL values, which sort after all non-NULL values (so services lacking a sorted attribute appear at the end of results). For string sorting, lexical ordering is used based on the rules in RFC 2608.
For integer sorting with a reference value (such as "speed:i:+:12"), the server computes the distance |speed - 12| for each service and sorts by that metric. For example, services with speeds 10, 12, 15 become metrics 2, 0, 3 and are ordered as 12, 10, 15.
The Select and Sort extensions can be used together to find the best match: for example, "Sort by speed descending, Select 3" returns the three fastest services, or "Sort by speed, Select 3, then Sort by load, Select 1" returns the fastest service among the three with lowest load.
You can use Sort and Select together: "give me the top 3 fastest, and among those, give me the one with the lowest load."
§4Error Handling and Advertisement
If a DA or SA receives a service request with a Select or Sort extension but does not support that extension, it returns an error code of OPTION_NOT_UNDERSTOOD in the service reply. This allows clients to detect unsupported extensions and fall back to fetching all results.
To help clients know which extensions are supported, the RFC specifies that a Directory Agent or Service Agent supporting these extensions MUST include the attribute keywords "select-enabled" and/or "sort-enabled" in its advertisements (DAAdvert or SAAdvert messages). A client SHOULD check these attributes before using Select or Sort on a given DA/SA to avoid sending unsupported requests.
The RFC notes that sort in SLP is a best-effort service: no sort-related error codes are returned, so if a DA/SA cannot perform the requested sort (for example, if the attribute does not exist or has inconsistent types), it returns an error code indicating the problem, but the operation itself is simple and does not require negotiation.
If a directory doesn't support Sort, it says "I don't understand that." Directory agents advertise what they support, so clients know what to ask for.