2.3.16 Service Location Protocol (svrloc)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97


John Veizades <veizades@home.net>
Erik Guttman <erik.guttman@eng.sun.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:srvloc@corp.home.net
To Subscribe: srvloc-request@corp.home.net
Archive: http://www.srvloc.org/mail_archive

Description of Working Group:

The Service Location Protocol is a decentralized, lightweight, scalable and extensible protocol for service discovery within a site. It allows but does not require centralized administration. Even when security, administrative policies or convenience require centralization (say in large enterprise deployments) the protocol requires very little administration. The protocol limits its use of multicast and broadcast as much as possible to conserve network bandwidth. Moreover, the protocol is extensible to arbitrary service advertisement and discovery and supports multiple languages and character set encodings.

The working group will document procedures for discovering services, and standardize "service:" schemes, which are definitions for resource and service URLs.

The focus of the working group will be on completing various documents which describe how to do service discovery and how to standardize service definitions which will be advertised and discovered.

- Interactions between Service Location Protocol and other enterprise naming and directory service protocols will be explored, defined, and standardized.

- Schemes for popular services will be discussed, and standardization efforts with other working groups explored as needed.

- Operational experiences and security procedures will be discussed and documented as best current practice.

- Service Type attribute definitions will be standardized by registering a 'Service Template' with IANA. This document will also describe how Service Types and Directory Schemas can be made interoperable. The Service Location Protocol can then be used to populate a directory service dynamically.

- An Application Programmers Interface has been developed to allow a uniform mechanism for applications to make use of Service Location Protocol functions, which will be supplied as an informational document.

- The Service Location Protocol itself will be revised and improved on, continuing it along the standards track.

Goals and Milestones:



Open discussion and determine if a working group should be formed.



Continue discussion trying to refine the problem statement and possible resolutions.



Issue a standards track protocol specification for the Service Location Protocol



Define an authentication mechanism for Service Location.

Nov 97


Submit an API for the Service Location Protocol to IESG for consideration as an Informational RFC.

Nov 97


Define a Service Discovery procedure for use in site as well as internet applications. Also define a mechanism for advertising services using DNS TXT records.

Nov 97


Submit the modifications to SLP for implementing it on IPv6 to IESG for consideration as a Proposed Standard.

Nov 97


Submit a service: URL and service template definition as an Internet-Draft.

Dec 97


Submit a revised I-D of the Service Location Protocol reflecting implementation experience and working group consensus on open issues.

Jan 98


Review the status of the SVRLOC WG. Revise the charter or shut down.


Request For Comments:







Service Location Protocol

Current Meeting Report

Minutes: Service Location Protocol (svrloc) Working Group

Reported by "Tom Taylor" <Tom.Taylor.taylor@nt.com>

Edited by "Erik Guttman" <eguttman@eng.sun.com>

The Service Location Protocol Working Group met for one session of two hours' duration. Erik Guttman chaired the meeting.

I. Agenda

The declared goal of the meeting was to wrap up current work, by achieving closure on the remaining issues. Please see the following website for all slides presented at the meeting:

Slides presented:

Basic presentation: http://www.srvloc.org/ietf40/SVRLOC-WG-IETF-40-index.html

New scope discussion: http://www.svrloc.org/~charliep/ietf40.html

Progress on Wide Area Service Location (WASRV) information:


II. Document Status

At last call:

draft-ietf-svrloc-discovery-05.txt (experimental track)

Agreed to last call at the meeting:

draft-ietf-svrloc-service-scheme-05.txt (standards track)
draft-ietf-svrloc-advertising-03.txt (standards track)
draft-ietf-svrloc-wpyp-02.txt (to IANA)
draft-ietf-svrloc-lpr-scheme-00 (to IANA)

Action: chair to forward notice.

Further work required:

draft-ietf-svrloc-protocol-v2-01.txt (standards track)
Aiming to move to last call in January. Target of most of the meeting effort.

draft-ietf-svrloc-api-02.txt (information)
Also aiming for January last call.

No current push to do this work.

Work of other groups:

Wide-area service location. To be considered by a BOF at the next meeting.

Erik raised the question of what to do with draft-ietf-svrloc-ipv6-02.txt. Charles Perkins observed that the IPv6 group is counting on service location. The meeting agreed that this document should move to a last call, directed to the IPv6 group. The document should be classed as standards track. Action: chair to forward notice.

III. Changes To Be Implemented In SLPv2

Erik identified a lengthy list of action items, classed by degree of necessity. None of these were questioned as to whether they were a good idea, although some elicited some discussion.


Highly advisable:

Further ideas:

IV. SLP Authentication Issues

Erik identified a number of issues, looking for some sense of direction from the meeting.

1. Should SLP certificates be dropped from the specification? Alternatives might be to accept any certificate, or to encourage X.509.
2. Directory Agent handling of signatures is brittle. The Directory Agent must store them, then forward them on demand without any changes such as reordering, case transformation, etc.
3. Private keys must be installed in multiple places, resulting in a dispersion and dilution of trust. To solve the malicious Directory Agent problem, it is necessary for Service Agents to pass private keys to the Directory Agent, but then the latter can say anything it wants about the Service Agents it is representing.

At this point, Erik proposed a detailed process based on the premise that public keys now represent certificate authorities. In the new process, the User and Directory Agents obtain the public key by asking for it. It was pointed out that this process had no means of preventing revocation.

Charlie Perkins suggested that extra security be designed in only where needed. In this case, the group should retain the old model.

The sense of the meeting was that it is acceptable to pass private keys to the Directory Agent.

MD5/RSA is currently mandatory for signatures. However, if the User or Directory Agent does not understand the selected algorithm, it cannot process the signature in order to return a NACK to say so. Some fixes were suggested to allow algorithm negotiation, but were vulnerable to man-in-the-middle attacks or unworkable due to key unavailability. The real issue is which algorithm to make mandatory to guarantee interoperability. The discussion of this issue will be taken to the list, bearing in mind the IETF guideline that encumbered technology should be avoided.

One suggestion was made which seems promising: The UA can request algorithms be including an extension option listing algorithms by preference. The DA or SA will respond with a reply, including an extension indicating which algorithm was used *and* echoing the list's order. This entire reply option will be signed so the UA can verify that the list was not reordered by a man in the middle to put a weaker algorithm first in the list, or eliminate harder algorithms from the negotiation.

V. LDAP Filters

Erik presented the proposal to make SLP interoperate with LDAP filters.


Implied work items:

Would be nice items:

A discussion ensued on whether compatibility would be with LDAPv2 or LDAPv3. LDAPv3 specifies the use of UTF-8, but is much more complicated than LDAPv2. Erik called for a volunteer to determine the scope of effort involved in using LDAPv3. Ryan Moels of AT&T volunteered. Action: Ryan Moels to report to list.

Jim Kempf pointed out that the SLPv1 filter is inconsistent with LDAP. The SLPv1 filter has the form:


However, in LDAP, scope is not an attribute: (&(service type = st)(predicate)), where & is the scope. But the LDAP expression poses a problem for SLPv1, because service type appears syntactically to be part of the predicate. The suggestion was made to move the service-type item out of the predicate. No one dissented, so this will be done for the next version of the protocol.

VI. Service Specific Multicast Addresses

SLP was not granted the requested ranged of 1024 addresses:

The suggestion was that SLP drop the multicast feature. The original purpose of multicast was to divert unusable traffic from nodes and links. Jonathan Rosenberg, who had indicated that a multicast mechanism similar in some respects to the one in SLPv1 was essential for scalability at the Munich meeting, agreed that it could be omitted in single-domain operation. The rest of the working group agreed to its elimination.

VII. Requested New Directory Agent Capabilities

For increased robustness, two new Directory Agent capabilities were proposed:

A question was raised, whether the first capability implied that User and Service Agents must now track the list of active Directory Agents. In Erik's view, this would be optional.

Clearly, Service Agents would have to keep track of those Directory Agents reporting congestion. This implies the need for a back-off algorithm in the specification. Microsoft may post one to the list. It was noted that back-off requests must be signed.

VIII. Scopes

Charles Perkins gave a presentation on normalized scopes for SLP.

Design premises:

Comment from the audience: Appletalk supplies a precedent. Users supply scopes interactively. John Veizades noted that as a matter of history, SLP was originally conceived of to replace NBP on Appletalk. A further comment was made that users don't necessarily like Appletalk zones.

Charlie's specific proposal was that scopes be used as an administrative tool.

Erik emphasized that this would represent a major change in point of view from SLPv1. Scope would not be an attribute, and would not be visible to the user.

Charles presented a picture:

UA ---------> SA

Unscoped Scoped

The User Agent cannot currently make a scoped request to the Service Agent because it doesn't know which scopes the Service Agent recognizes. With the proposed changes, the User Agent can make scoped, unscoped, or ignore-scope requests to the Service agent. Similarly, the User Agent can make unscoped, scope 'X' plus unscoped, or scope 'X' only requests to the Directory Agent. The middle category (scope 'X' plus unscoped) is for transition.

In the proposed scheme, the Directory Agent advertises its ability to handle scoped queries. DHCP has to be fixed to carry the same information.

There are some potential problems with scope name collision when organizations merge.

John ---- asked whether the user would be able to see Service Agents in other scopes. The answer is Yes. It can either ignore scopes (thus including all SAs in the potential list of responders) or know the scope to use a priori - such as via DHCP.

IX. Wide Area Service Location (WASRV)

Wide Area Service Location: BOF scheduled for March. 01 draft released. An architecture is proposed in this draft.

The mailing list is available for discussion:

To post: wasrv@lists.research.bell-labs.com
To join: un/subscribe on wasrv-request@lists.research.bell-labs.com.

The architecture has come a long way since the discussion in Munich. Those who follow SVRLOC are encouraged to follow this work as it builds upon the mechanisms of SLP, taking advantage of scalable wide area multicast protocol techniques.

X. Summary and Wrapup

The meeting agreed to work toward LDAP interoperability.

Regarding a MIB: could be used to find the locations of the manageable entities. The group should consider the possibilities.

A draft is out on expanding-ring search. Is there interest in adding this as a possible SLP search mode? A comment here was that expanding-ring searches don't always give you what you want (for example, pipe speed). The question will go to the list.

SVRLOC may not have to meet next time. In fact, it may be time to go dormant. The template draft provides the process needed for IANA registration.


Wide Area Service Location

Attendees List

go to list

Previous PageNext Page