rfc3082.txt

RFC 的详细文档！

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



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


   particular scope; that is, a UA can use any DA with a particular
   scope and expect to get the same service advertisements.
   Notifications should exhibit the same property.  Whether or not a UA
   receives a notification should not depend on the DA to which they
   happen to connect. This preserves the DAs' identity as a pure cache.

   Another goal is that the notification messages contain enough
   information about the triggering event that the UA can determine
   whether or not it is of interest in the large majority of cases
   without having to issue another SLP request a priori.  The UA may, of
   course, issue an SLP request for related reasons, but it should not
   have to issue a request to obtain more information on the event that
   triggered the notification in most cases.  This reduces the amount of
   network traffic related to the event.

   In order to simplify implementation, we would like to use similar
   mechanisms for notification in large and small networks.  The
   mechanisms are not identical, obviously, but we want to avoid having
   radically different mechanisms that require completely separate
   implementations.  Having similar mechanisms reduces the amount of
   code in UA and SA clients.

   A minor goal is to make use of existing SLP message types and
   mechanisms wherever possible.  This reduces the amount of code
   necessary to implement the notification mechanism, because much code
   can be reused between the base SLP and the notification mechanism.
   In particular, we expect to make use of the SLP extension mechanism
   in certain cases to support subscription.

5. Notification Design Description

   In order to support scalability, we split the design into two parts.
   A small network design is used when no DAs are present in the
   network.  A large network design is used in networks with DAs.  The
   following subsections describe the two designs.

5.1 Small Network Design

   In networks without DAs, UAs are notified by an SA when the SA
   initially appears, and when the SA disappears.  This allows UAs to
   know about the list of service types the SA supports.  In small
   networks, there is no centralized agent available to administer
   subscriptions for newly appearing SAs.  This rules out any kind of
   subscription design in which a UA subscribes to notifications for a
   particular service type in particular scopes of interest, because a
   newly appearing SA can't tell whether or not there are any
   subscriptions without a centralizing agent to tell it.




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


   As a result, SAs perform notification when they come on line and
   prior to shutting down regardless of their scope or service type, if
   they are capable of performing notification.  This means that a UA
   receives notification of all types of changes for all scopes and
   service types, and consequently must be prepared to filter out those
   changes in which it is not interested (other scopes, other service
   types).

   The design requires SAs to perform notification by IP multicasting
   (or broadcasting in IPv4 if multicast is not available) SLP SrvReg or
   SrvDereg messages using the multicast transmit algorithm described in
   Section 9.0.  The port number for notifications is not the default
   SLP port, because that port is only accessible to privileged users on
   some operating systems, but rather the port 1847, as assigned by
   IANA.

   In IPv4, the SA performs multicast on the SLP multicast address
   (239.255.255.253, default TTL 255) and is administratively scoped in
   the same manner as SLP [4].  IPv4 UAs interested in notification join
   the multicast group 239.255.255.253 and listen on port 1847.  In
   IPv6, the multicast is performed to the scoped IPv6 addresses for the
   service type advertised, as described in [8].  The SA advertises on
   all addresses up to and including the largest multicast scope that it
   supports.  IPv6 UAs interested in notification join the multicast
   groups corresponding to the multicast scopes and service type in
   which they are interested and listen on port 1847.  For example, an
   IPv6 UA that has access to site local scope and is interested in a
   service type whose hash is 42, calculated according to the algorithm
   in [8], joins the groups FF01:0:0:0:0:0:10042 through
   FF05:0:0:0:0:0:10042.

5.2 Large Network Design

   In networks with DAs, a DA supporting a particular scope can act as
   an intermediary for administering UA subscriptions.  A subscription
   consists of a service type and a collection of scopes.  A UA
   interested in being notified about changes in a particular service
   type attaches the Subscribe extension to a SrvRqst message sent to
   the DA.  The DA obtains multicast group addresses for notification
   based on the algorithm described in Section 8.0 and puts them into a
   NotifyAt extension which it attaches to the SrvRply.  The UA listens
   on the group addresses in the reply for notifications.

   When a new subscription comes in, existing SAs are informed about the
   subscription using the following procedure.  The DA compares the
   service type and scopes in the new subscription against a list of
   existing subscriptions.  If no previous subscription has the same
   service type and scopes, the DA MUST multicast a DAAdvert, using the



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


   multicast transmit algorithm described in Section 9.0, and MUST
   include the NotifyAt extension with the multicast group addresses for
   notification.  If an existing subscription covers the same service
   type and scopes as the new subscription, the DA MUST NOT multicast a
   DAAdvert.

   A DA MUST keep track of subscriptions it has arranged as well as
   subscriptions arranged by other DAs in any scopes with which the DA
   is configured.  To avoid multiple multicast NotifyAt messages, a DA
   MUST wait a random amount of time, uniformly distributed between 0
   and 3 seconds before sending the multicast DAAdvert with NotifyAt.
   During this period, the DA MUST listen for NotifyAt messages that
   match the one from the new subscription.  If a matching NotifyAt is
   detected, the DA MUST not multicast.

   When a new SA registers with a DA that has existing subscriptions,
   the new SA is informed of notifications it should perform using the
   following procedure.  If the service type and scopes in the new SA's
   SrvReg messages match an existing subscription, a NotifyAt containing
   the multicast addresses for notification MUST be included in the
   SrvAck.  If the SA doesn't support notification, it simply ignores
   the extension.  If the service type and scopes in the new SA's SrvReg
   do not match any existing subscriptions, the DA MUST NOT include a
   NotifyAt.

   The DA itself MUST also perform notification, according to the
   multicast transmit algorithm, when a service advertisement times out.
   Time-out of a service advertisement results in the DA multicasting a
   SrvDereg for the deregistered URL.  This allows interested UAs to be
   informed of the service advertisement's demise even if the SA has
   disappeared without deregistering.  A DA MUST NOT perform
   notification when it receives a SrvReg from an SA, however, that is
   the job of the SA.