summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3082.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3082.txt')
-rw-r--r--doc/rfc/rfc3082.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc3082.txt b/doc/rfc/rfc3082.txt
new file mode 100644
index 0000000..cdc5eb6
--- /dev/null
+++ b/doc/rfc/rfc3082.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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.
+
+ As in small networks, notification is performed primarily by SAs. If
+ an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the
+ following conditions are met:
+
+ 1. The SA supports notification.
+
+ 2. The SA's service type matches the service type in the
+ NotifyAt extension.
+
+ 3. The SA's scopes match one of the scopes of the NotifyAt
+ extension.
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 5]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+ then the SA saves the multicast addresses that correspond to the
+ scopes and service types it supports. The SA MUST perform
+ notification immediately after the SA has performed the SrvReg or
+ SrvDereg with the DA. An SA that has detected a DA in its scopes
+ MUST NOT multicast any notifications unless it receives a NotifyAt
+ extension in a SrvAck with service type and scopes matching the SA's
+ service type and scopes.
+
+6. Subscribe Extension
+
+ The Subscribe extension has the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extension Type = 0x0004 | Extension Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ex. Len. (ct) | Abs. Type Fl. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The scope list and service type of the extension are taken from the
+ accompanying SrvRqst. The abstract type flag indicates whether the
+ UA is interested in hearing from all SAs advertising concrete
+ instances of an abstract type [3], and is only of interest if the
+ service type in the SrvRqst is a concrete type. If the flag is 1,
+ the UA is interested in hearing from all SAs advertising concrete
+ types having the same abstract type as the type of the SrvRqst. If
+ the flag is 0, the UA is only interested in hearing from SAs
+ supporting the particular concrete type in the SrvRqst. If the
+ service type in the accompanying SrvRqst is not a concrete type, the
+ flag is ignored.
+
+7. NotifyAt Extension
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Extension Type = 0x0005 | Extension Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ext. Len (ct) | Subscription Lifetime |SGL List Len. \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |SGL L. Len (ct)| Scope/Group List \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length of Service Type Name | Service Type Name \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 6]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+ The service type name is in the same format as in the SrvRqst. The
+ scope/group list is a list of scope names and multicast group
+ addresses. The following ABNF [5] syntax describes the list:
+
+ sglist = sgitem / sgitem "," sglist
+ sgitem = scope-name ":" ip-addr
+ ip-addr = ipv4-number | ipv6-number
+ scope-name = ; See RFC 2608 for the format of scope names.
+ ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
+ ipv6-number = ;See RFC 2373 [9] Section 2.2
+
+ An example of a scope/group list for IPv4 is:
+
+ eng:239.255.255.42,corp:239.255.255.43
+
+ An example of a scope/group listfor IPv6 is:
+
+ eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042
+
+ The scope/group list gives the multicast addresses to use for
+ notifications involving the service type for the given scopes.
+
+ The service type name can be a simple type name, an abstract type
+ name, or a concrete type name. If the name is an abstract type name,
+ all SAs advertising the abstract type MUST notify. If the name is a
+ concrete or simple type name, ONLY those SAs advertising the simple
+ or concrete type MUST notify, others MUST NOT notify. A DA that
+ receives a subscription for a concrete type with the abstract type
+ flag set, MUST include the abstract type name in all the NotifyAt
+ messages it sends. If the DA receives a subscription for a concrete
+ type with the abstract type flag not set, the DA MUST NOT include the
+ abstract type, but rather MUST include the concrete type name.
+
+ There are three cases in which an agent may receive a NotifyAt
+ extension: in a SrvRply returned to a UA, in a multicast DAAdvert,
+ and in a SrvAck returned to an SA. The three subsections below
+ describe the response in each of these cases.
+
+7.1 NotifyAt received with SrvRply
+
+ When a UA sends a SrvRqst with a Subscribe extension, the DA responds
+ with a SrvRply including a NotifyAt. The DA MUST NOT unicast a
+ NotifyAt to a UA with any other message and MUST NOT send a NotifyAt
+ unless a SrvRqst with a Subscribe extension was received.
+
+ The UA responds by setting up a multicast listener to the group
+ addresses included in the extension on the SLP notification port
+ 1847. The UA MAY also want to note the expiration lifetime of the
+
+
+
+Kempf & Goldschmidt Experimental [Page 7]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+ subscription assigned by the DA, and reissue a subscription before
+ the lifetime expires.
+
+7.2 NotifyAt received with Multicast DAAdvert
+
+ The DA multicasts a NotifyAt with a DAAdvert using the multicast
+ transmit algorithm when a UA has requested notification and the
+ scopes and service type in the subscription were not previously seen.
+ This message informs existing SAs having the service type and scopes
+ in the announcement that they should multicast notifications when
+ they shut down.
+
+ A receiving SA participating in notification responds by noting the
+ multicast address if the service type and scopes match. When the SA
+ is about to go down, the SA MUST first unicast a SrvDereg without
+ attribute tag list to its DAs (as per standard SLP), then it MUST
+ multicast the same SrvDereg message according to the multicast
+ transmit algorithm. The SA MUST cease performing notification when
+ the subscription lifetime expires, unless a subsequent NotifyAt is
+ received prolonging the subscription.
+
+ A UA that is performing passive DA detection will naturally also
+ receive the extension, but the UA SHOULD ignore the extension.
+
+7.3 NotifyAt received with SrvAck
+
+ An SA can receive a NotifyAt with a SrvAck when it first comes up and
+ registers itself with a DA. If the DA has any subscriptions from UAs
+ for the service type and scopes represented by the SA, it MUST return
+ a NotifyAt with the SrvAck.
+
+ The SA upon receiving the NotifyAt immediately multicasts the same
+ SrvReg it sent to the DA, according to the multicast transmit
+ algorithm. The SA MUST only perform the multicast algorithm once,
+ even if it registers with more than one DA and receives the NotifyAt
+ in reply from more than one. Prior to its demise and after
+ deregistering with a DA, the SA MUST notify with the same SrvDereg,
+ as described in Section 7.2.
+
+8. Multicast Address Allocation
+
+ Enterprise networks that allow SLP notification SHOULD deploy the
+ Multicast Address Allocation Architecture (MAAA) including
+ administratively scoped multicast and Multicast Address Dynamic
+ Client Allocation Protocol (MADCAP) [6].
+
+ If it is not possible to obtain a multicast address for use in SLP
+ notifications, the SLP multicast address is used.
+
+
+
+Kempf & Goldschmidt Experimental [Page 8]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+ If the MAAA infrastructure is deployed, DAs and SAs obtain their
+ scope configuration from MADCAP, because the SLP scopes are the same
+ as the MADCAP scopes. Each SLP scope MUST correspond to a multicast
+ scope name, in the sense of [6]. In such a case, a DA allocates,
+ using MADCAP, a new multicast group address for each new service
+ type/scope pair to which a UA subscribes. The allocation is made by
+ MADCAP from the multicast address range for the scope. In this way,
+ only those UAs interested in the service type and scopes in the
+ subscription receive the multicast notification. The DA sets up the
+ lease on the multicast address to correspond with the duration of the
+ subscription. If the MADCAP server runs out of addresses, the SLP
+ multicast group is used as a last resort.
+
+ For example, if the multicast scope has an address range of 239.1.0.0
+ through 239.1.255.255, the notification group address for service
+ type X in scope A could be 239.1.0.42 and for service type Y in scope
+ B could be 239.1.42.42.
+
+9. Multicast Transmit Algorithm
+
+ The DA and SAs use a multicast transmit algorithm similar to that
+ used for discovering services in SLP, described in RFC 2608 [1],
+ except the agent performing the notification doesn't wait for
+ replies. The agent performing the notification transmits a
+ notification message repeatedly over a period of 15 seconds, backing
+ off exponentially on the duration of the time interval between the
+ multicasts. The rationale for this algorithm is to limit the
+ duration and scope of the multicast announcement while still
+ repeating the announcement enough times to increase the probability
+ that one message gets through.
+
+ For an SA, a notification message is either a SrvReg or a SrvDereg
+ message, depending on whether the SA is registering a new service or
+ deregistering a service. When a new service is registered, the
+ SrvReg message MUST have the fresh bit set in the SLP header. The
+ entire list of attributes for the service SHOULD be included. The
+ SrvDereg message MUST NOT include an attribute tag list.
+ Notifications MUST NOT be transmitted at any other time, to minimize
+ multicast traffic.
+
+ Since a SrvReg could contain attribute lists of arbitrary length, the
+ message could potentially overflow the packet MTU for UDP. If an
+ attribute list causes a packet MTU overflow, the SA MUST set the
+ overflow bit in the SLP header. The attribute list in the
+ notification message MUST be formatted so that a UA can use the
+ attributes even if an overflow occurs. If a UA needs more attributes
+ than are transmitted in the notification message, it can contact the
+ SA (if no DA is present) or the DA for the attributes it needs.
+
+
+
+Kempf & Goldschmidt Experimental [Page 9]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+ A DA multicasts a DAAdvert when a subscription comes in containing a
+ service type and scopes that do not match any on the DA's list of
+ known subscriptions. The same algorithm MUST be used. If the
+ combination of the DA attributes and the NotifyAt message cause the
+ DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to
+ allow the NotifyAt to fit and the overflow bit MUST be set in the
+ header. An SA knows that the purpose of the message is to inform it
+ of a new subscription rather than for passive advertisement, because
+ of the extension, and it can therefore ignore the DA attribute list
+ field if the overflow bit is set in the header. A DA also transmits
+ a SrvDereg message when a service advertisement is deregistered due
+ to timeout, following the same rules as for an SA.
+
+10.0 DA Disappearance
+
+ Robustness to DA failure is an important goal of the design. When a
+ DA disappears due to unforeseen circumstances, subscription
+ information from UAs is lost. UAs continue to get notifications from
+ existing SAs. However, new SAs will not be informed of the
+ subscription unless other DAs also have the subscription information.
+ Because a UA may not discover a new DA until it tries to perform an
+ active request, the UA could potentially miss the appearance of new
+ services. For this reason, UAs that are concerned about receiving
+ notification of absolutely every service that appears SHOULD issue
+ subscriptions to every newly discovered DA that supports the scopes
+ it supports. Similarly, if a DA disappears through controlled
+ shutdown, a UA performing passive discovery can detect the shutdown
+ and reissue the subscription to an alternate DA.
+
+ On the SA side, when a DA goes down, existing SAs continue to notify
+ until the subscription expires. Before ceasing to notify, an SA MUST
+ determine whether the DA is still active and, if not, verify with
+ another DA whether the subscription has been extended. If no other
+ DA is available, the SA MUST ignore the subscription expiration time
+ and continue notifying until a new DA is discovered. When a new DA
+ is discovered the SA must send a new SrvReg to the DA, according to
+ RFC 2608 [1]. The replying SrvAck contains a NotifyAt extension if
+ the UA has renewed its subscription with the DA. If the SrvAck does
+ not contain a NotifyAt message the SA MUST continue to notify until
+ the subscription expires. If a UA is interested in continuing the
+ notification, it renews the subscription with the new DA prior to the
+ expiration of the old one, and so the SA is informed to continue
+ notifying.
+
+
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 10]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+ Note that this procedure still does not inform SAs that come up
+ between the time a newly booted DA comes up and the time the UA has
+ renewed its subscription with the newly booted DA. If this situation
+ is of concern, multiple DAs can be used to assure that all
+ subscriptions are covered when a DA goes down.
+
+11. Network Administration Considerations
+
+ In SLP networks with DAs as described in RFC 2608, the only multicast
+ is the SrvRqst for DAAdverts performed during active DA discovery,
+ and unsolicited DAAdverts sent periodically by the DA for passive
+ discovery. There is no multicast involved in UA queries or SA
+ registrations. This allows network administrators to set up DAs for
+ a particular collection of IP subnets and confine all service
+ discovery traffic to unicast between the SA and UA clients and the
+ DA. Administratively scoped multicast can additionally be used to
+ limit the extent of active DA discovery and passive DA advertising.
+ The amount of multicast involved is not high and DHCP DA and scope
+ configuration can be used to limit which DAs a particular UA or SA
+ client sees, or to inhibit multicast entirely so that UAs and SAs
+ only use configured DAs.
+
+ With notification, however, multicast traffic involving events in SAs
+ becomes available. Because DAs request multicast addresses based on
+ scope and service type, the multicast associated with particular
+ events should only propagate to those subnets in which UAs and SAs of
+ the same scope are interacting. Routers should be configured with
+ administrative multicast scoping to limit multicast. If DAs are not
+ deployed (or the MAAA is not deployed), however, the amount of
+ multicast on the SLP multicast address when notifications are being
+ used could quickly become very large. Therefore, it is crucial that
+ DAs supporting notification be deployed in large networks where UA
+ clients are interested in notification.
+
+12. Security Considerations
+
+ The SrvReg and SrvDereg messages contain authentication blocks for
+ all SLP SPIs supported by the DAs with which the SA registers. Since
+ these SPIs are necessarily the same as those that UAs can verify, a
+ UA receiving a multicast notification is in a position to verify the
+ notification. It does so by selecting the authentication block or
+ blocks that it can verify. If authentication fails, either due to
+ lack of an authentication block, or lack of the proper SPI, the UA
+ simply discards the notification. In a network without DAs, the SPIs
+ of the UA and SA must also match.
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 11]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+13. IANA Considerations
+
+ The SLP Notification services use the IANA-assigned port number of
+ 1847. The SLP extension identifiers assigned by IANA are 0x0004 for
+ Subscribe and 0x0005 for NotifyAt.
+
+14. Acknowledgements
+
+ The authors would like to thank Charles Perkins, of Nokia, and Erik
+ Guttman and Jonathan Wood, of Sun Microsystems, for their stimulating
+ discussion and suggestions during the initial phases of the
+ subscription/notification design. We would also like to thank Erik
+ for his intense scrutiny of the specification during the later
+ phases. His comments were instrumental in refining the design.
+ Shivaun Albright, of HP, motivated simplification of the protocol to
+ focus on initial registration and deregistration only. Vaishali
+ Mithbaokar implemented the simplified protocol.
+
+15. References
+
+ [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+ Location Protocol", RFC 2608, July 1999.
+
+ [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
+ service: Schemes", RFC 2609, July 1999.
+
+ [4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
+ 1998.
+
+ [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic
+ Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
+
+ [7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses
+
+ [8] Guttman, E., "Service Location Protocol Modifications for IPv6",
+ Work in Progress.
+
+ [9] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2375, July 1997.
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 12]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+16. Author's Addresses
+
+ James Kempf
+ Sun Microsystems
+ UMPK15-214
+ 901 San Antonio Rd.
+ Palo Alto, CA 94040
+ USA
+
+ Phone: +1 650 786 5890
+ EMail: james.kempf@sun.com
+
+
+ Jason Goldschmidt
+ Sun Microsystems
+ UMPK17-202
+ 901 San Antonio Rd.
+ Palo Alto, CA 94040
+ USA
+
+ Phone: +1 650 786 3502
+ EMail: jason.goldschmidt@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 13]
+
+RFC 3082 Notification and Subscription for SLP March 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Goldschmidt Experimental [Page 14]
+