RFC 3082 (rfc3082) - Page 2 of 14
Notification and Subscription for SLP
Alternative Format: Original Text Document
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