RFC 3082 (rfc3082) - Page 2 of 14

Notification and Subscription for SLP

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
   intervening DAs.  SLP is transparent with respect to DAs supporting a



Kempf & Goldschmidt           Experimental