Notification and Subscription for SLP
RFC 3082

Document Type RFC - Experimental (March 2001; No errata)
Was draft-kempf-srvloc-notify (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3082 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           J. Kempf
Request for Comments: 3082                                J. Goldschmidt
Category: Experimental                                  Sun Microsystems
                                                              March 2001

                 Notification and Subscription for 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 (2001).  All Rights Reserved.

Abstract

   The Service Location Protocol (SLP) provides mechanisms whereby
   service agent clients can advertise and user agent clients can query
   for services.  The design is very much demand-driven, so that user
   agents only obtain service information when they specifically ask for
   it.  There exists another class of user agent applications, however,
   that requires notification when a new service appears or disappears.
   In the RFC 2608 design, these applications are forced to poll the
   network to catch changes.  In this document, we describe a protocol
   for allowing such clients to be notified when a change occurs,
   removing the need for polling.

1. Introduction

   The Service Location Protocol (SLP) [1] provides a mechanism for
   service agent (SA) clients to advertise network services and for user
   agent (UA) clients to find them.  The mechanism is demand-driven.
   UAs obtain service information by actively querying for it, and do
   not obtain any information unless they do so.  While this design
   satisfies the requirements for most applications, there are some
   applications that require more timely information about the
   appearance or disappearance in the services of interest.

   Ideally, these applications would like to be notified when a new
   service comes up or when a service disappears.  In order to obtain
   this information with SLP as described in RFC 2608, such applications
   must poll the network to periodically refresh their local cache of
   available service advertisements.

Kempf & Goldschmidt           Experimental                      [Page 1]
RFC 3082         Notification and Subscription for SLP        March 2001

   An example of such a client is a desktop GUI that wants to display
   network service icons as soon as they appear to provide users with an
   accurate picture of all services available to them.

   Because polling is inefficient and wasteful of network and processor
   resources, we would like to provide these applications a mechanism
   whereby they can be explicitly notified of changes.  In this
   document, we describe a scalable mechanism allowing UAs to be
   notified of changes in service availability.

2. Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

3. Terminology

   In this section, we present some additional terminology beyond that
   in [1] and [3].

   Notification - A message sent to an interested agent informing that
                  agent that a service has appeared or disappeared.

   Subscription - A request to be informed about changes in service
                  availability for a particular service type and scopes.

4. Design Considerations

   The primary design consideration in a notification protocol for SLP
   is that we would like it to exhibit the same high degree of
   scalability and robustness that the base SLP protocol exhibits.
   Notification should work in small networks with only a few SAs, as
   well as large enterprise networks with thousands of SAs and hundreds
   of DAs.  Small networks should not be required to deploy DAs in order
   to receive the benefits of notification.  We also want to assure that
   notification in large networks does not cause heavy processing loads
   to fall on any one particular SLP agent.  This requires that the task
   of notification be distributed rather than centralized, to avoid
   loading down one agent with doing all the notification work.
   Finally, we would like the notification scheme to be robust in the
   face of DA failures, just as the base SLP design is.

   An important consideration is that the UA clients obtain
   notifications of SA events in a timely fashion.  If a UA has
   subscribed to notification for a particular service type, the UA
   should receive such notification regardless of the state of
Show full document text