Internet Engineering Task Force James Kempf INTERNET DRAFT Sun Microsystems 22 October 1999 Jason Goldschmidt Bucknell University Notification and Subscription for SLP draft-kempf-srvloc-notify-00.txt Status of This Memo This document is a submission by the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@srvloc.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The Service Location Protocol 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 and update when the attributes of the service change. 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 Kempf and Goldschmidt Expires 22 March 2000 [Page i] Internet Draft Notification and Subscription for SLP 22 October 1999 clients to be notified when a change occurs, removing the need for polling. Kempf and Goldschmidt Expires 22 March 2000 [Page ii] Internet Draft Notification and Subscription for SLP 22 October 1999 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Notation Conventions 2 3. Terminology 2 4. Design Considerations 2 5. Notification Design Overview 3 5.1. Small Network Design . . . . . . . . . . . . . . . . . . 4 5.2. Large Network Design . . . . . . . . . . . . . . . . . . 4 6. Subscribe Extension 5 7. NotifyAtExt Extension 6 7.1. NotifyAtExt received with SrvRply . . . . . . . . . . . . 7 7.2. NotifyAtExt received with multicast DAAdvert . . . . . . 7 7.3. NotifyAtExt received with SrvAck . . . . . . . . . . . . 7 8. Multicast Address Allocation 8 9. Multicast Transmit Algorithm 8 10. DA Disappearance 9 11. Network Administration Considerations 9 12. Security Considerations 10 13. Acknowledgements 10 14. Full Copyright Statement 11 Kempf and Goldschmidt Expires 22 March 2000 [Page iii] Internet Draft Notification and Subscription for SLP 22 October 1999 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 changes in the services of interest. In particular, these applications require notification of the following events: 1 Appearance of a new advertisement for a particular kind of service. 2 Disappearance of an advertisement for a particular kind of service. 3 Change in attributes in the advertisement for a particular kind of service. Ideally, these applications would like to be notified when a new SA comes up, when an SA disappears or when a service advertisement times out in a DA, and when an SA adds, deletes, or changes the value of its attributes. 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. An example of such a client is a printer that wants to dynamically advertise a state change in order that administrative applications can receive up-to-the-minute information about the state of devices they are administering. Another example 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 types of interest. Kempf and Goldschmidt Expires 22 March 2000 [Page 1] Internet Draft Notification and Subscription for SLP 22 October 1999 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 [3]. 3. Terminology In this section, we present some additional terminology beyond that in [1] and [2]. Notification A message sent to an interested agent informing that agent of a change in state involving another agent. Subscription A request to be informed about changes in state 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 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. 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 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. Kempf and Goldschmidt Expires 22 March 2000 [Page 2] Internet Draft Notification and Subscription for SLP 22 October 1999 Another consideration, related to the scalability goal, is to keep the granularity of subscription high enough that notification messages don't become a burden on the network or the individual agents. For example, we could design the notification mechanism such that a notification message is sent for a change on a single attribute. However, this would cause a flood of notification messages when an SA changed a few attributes. A related 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 may not be 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. An explicit nongoal of the design is to support notification frequencies on on the order of seconds or even a few minutes. We would like notification to be dynamic but we expect the frequency of update to be on the order of five minutes or more. Applications that require notification at higher frequencies should use an application specific protocol designed for higher frequency notification. 5. Notification Design Overview 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. Kempf and Goldschmidt Expires 22 March 2000 [Page 3] Internet Draft Notification and Subscription for SLP 22 October 1999 5.1. Small Network Design In networks without DAs, UAs are notified by an SA when the SA initially appears, if any change occurs in attributes, and when the SA disappears. 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. As a result, SAs perform notification on every state change 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, or advertisements that are not of interest because the attributes don't match attributes in which the UA is interested). The design requires SAs to perform notification by IP multicasting (or broadcasting if multicast is not available) one or several SLP SrvReg or SrvDereg messages describing their state change using the multicast transmit algorithm described in Section 9. The multicast is performed on the SLP multicast address (239.255.255.253, default TTL 255) and is administratively scoped in the same manner as SLP [4]. The port number for notifications is not the default SLP port, because that port is only accessible to privileged users, but rather the port <*to be assigned by IANA*>. UAs interested in notification join the multicast group 239.255.255.253 and listen on port <*to be assigned by IANA*>. 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 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 based on the algorithm described in Section 8 and puts them into a NotifyAtExt extension which it attaches to the SrvRply. The UA listens on the group addresses in the reply for notifications. If no previous subscription was seen having the same scope or scopes, the DA multicasts DAAdverts using the multicast transmit algorithm described in Section 9 including the NotifyAtExt extension. This informs existing SAs that a UA has requested a subscription to events involving their service type. When new SAs register with the DA, the NotifyAtExt is included in the SrvAck. If the SAs don't support Kempf and Goldschmidt Expires 22 March 2000 [Page 4] Internet Draft Notification and Subscription for SLP 22 October 1999 notification, they simply ignore the extension. 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. As in small networks, notification is performed primarily by SAs. If an SA receives a DAAdvert or SrvAck with a NotifyAtExt extension and the following conditions are met: 1. The SA supports notification. 2. The SA's service type matches the service type in the NotifyAtExt. 3. The SA's scopes match one of the scopes of the NotifyAtExt extension. 4. The NotifyAtExt query query matches one or more of the SA's advertisements. then the SA saves the multicast addresses that correspond to the scopes it supports. The SA MUST perform notification immediately after the SA has performed the SrvReg or SrvDereg with the DA. An SA that has not received a NotifyAtExt extension in a message from a DA or that has received a NotifyAtExt that doesn't match any of its services MUST NOT perform multicast notification. 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 = | Extension Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Scope List | Scope List \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Service Type Name | Service Type Name \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The scope list has the same format as in the SLP UA requests [1]. The service type name has the same format as in the SLP SrvRqst. When a DA receives the Subscribe extension, it determines the multicast addresses to use based on the algorithm described Kempf and Goldschmidt Expires 22 March 2000 [Page 5] Internet Draft Notification and Subscription for SLP 22 October 1999 in Section 8. The multicast addresses are then bundled into a NotifyAtExt along with the scopes and service type. The query included in the NotifyAtExt is the logical conjunction of all queries received from all UAs for the subscribed service type in the accompanying SrvRqsts. The DA also includes a lifetime in the NotifyAtExt, informing subscribing UAs and notifying SAs how long the subscription is active. The lifetime is included to prevent old subscriptions from hanging around after the UA making the subscription has exited. The NotifyAtExt is then multicast as part of a DAAdvert according to the multicast transmission algorithm, and is included in the SrvRply to the requesting UA. The DA itself is required to perform notification if a service advertisement times out. This informs the UA that the service advertisement is no longer valid. 7. NotifyAtExt 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 = | Extension Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subscription Lifetime | Length of Scope/Group List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope/Group List \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Service Type Name | Service Type Name \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Query | Query \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The service type name is in the same format as in the Subscribe extension. The scope/group list is a list of scope names and multicast group addresses, in IPv4 dotted decimal notation. The following ABNF [5] syntax describes the list: sglist = sgitem / sgitem "," sglist sgitem = scope-name ":" ipv4-number scope-name = ; See RFC 2608 for the format of scope names. ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) An example of a scope/group list is: Kempf and Goldschmidt Expires 22 March 2000 [Page 6] Internet Draft Notification and Subscription for SLP 22 October 1999 eng:239.255.255.42,corp:239.255.255.43 There are three cases in which an agent may receive a NotifyAtExt 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. NotifyAtExt received with SrvRply When a UA sends a SrvRqst with a Subscribe extension, the DA responds with a SrvRply including a NotifyAtExt. The DA MUST NOT unicast a NotifyAtExt to a UA with any other message and MUST NOT send a NotifyAtExt unless a SrvRqst with a Subscribe extension was received. The UA responds by setting up a multicast listener to the group address included in the extension on the SLP notification port <*to be assigned by IANA*>. The UA MAY also want to note the expiration lifetime of the subscription assigned by the DA, and reissue a subscription before the lifetime expires. 7.2. NotifyAtExt received with multicast DAAdvert The DA multicasts a NotifyAtExt with a DAAdvert using the multicast transmit algorithm when a UA has requested notification. This message informs existing SAs having the service type and scopes in the announcement that they should multicast notifications upon state changes if the query matches their attributes. A receiving SA participating in notification responds by noting the multicast address if the service type, scopes, and query match. When a state change (change in attributes, deregistration) occurs, the SA MUST first inform all its DAs of the change, then it MUST multicast the same message sent to the DAs according to the multicast transmit algorithm. The SA MUST cease performing notification when the lifetime expires, unless a subsequent NotifyAtExt 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. NotifyAtExt received with SrvAck An SA can receive a NotifyAtExt with a SrvAck when if first comes up and registers itself with a DA. If the DA has any subscriptions from Kempf and Goldschmidt Expires 22 March 2000 [Page 7] Internet Draft Notification and Subscription for SLP 22 October 1999 UAs for the service type and scopes represented by the SA, it returns a NotifyAtExt with the SrvAck. The SA upon receiving the NotifyAtExt takes exactly the same actions as when it receives a NotifyAtExt along with a multicast DAAdvert. Additionally, it MUST immediately perform a multicast notification of its SrvReg if the scopes, service type, and query of the NotifyAtExt apply. 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) [7]. If the MAAA infrastructure is not deployed, the SLP multicast address is used for notifications. If the MAAA infrastructure is deployed, the MADCAP servers MUST be configured with multicast scopes to support SLP scopes. Each SLP scope MUST correspond to a multicast scope name, in the sense of [7]. In such a case, a DA obtains the base multicast addresses and ranges for the SLP scopes it supports using MADCAP. The multicast group address used for SLP notifications is at the IANA-assigned fixed offset of 2 below the last multicast address in the scope, as described for SLP in [6]. This is the same address used for other SLP multicasting in administratively scoped networks. 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 periodically over an interval of 15 seconds. The number of retransmits should vary according to network congestion, but a minimum of 6 and a maximum of one per second is recommended. A notification message is either a SrvReg or a SrvDereg message, depending on whether the SA is registering a new service or adding attributes to an existing service, or deregistering a service or deleting attributes from an existing service. If a new service is registered, the notification message MUST have the fresh bit set in the SLP header of the multicast SrvReg message. Since SrvReg and SrvDereg contain attribute lists of arbitrary length, the message Kempf and Goldschmidt Expires 22 March 2000 [Page 8] Internet Draft Notification and Subscription for SLP 22 October 1999 could potentially overflow the packet MTU for UDP. If an attribute list causes a packet MTU overflow, the transmitting agent 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. A DA also multicasts a DAAdvert when a subscription comes in for a never-before-seen scope or scopes. The same algorithm should be used. If the combination of the DA attributes and the NotifyAtExt message cause the DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to allow the NotifyAtExt to fit and the overflow bit must be set in the header. Multiple DAAdvert messages MUST NOT be multicast. 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. 10. DA Disappearance When a DA disappears due to unforeseen circumstances, subscription information from UAs is lost. If a new DA is discovered, existing SAs continue notifying UAs of their state changes until the subscriptions expire. If no new DA is discovered, existing SAs ignore the subscription expiration time and continue notifying SAs until a new DA is discovered. UAs SHOULD reissue their subscriptions to a newly discovered DA the next time they perform an SLP query or when they renew their subscription. However, there is a window between when the old DA disappears and when the UAs reissue their subscriptions in which any newly starting SAs are not informed of the outstanding subscriptions. 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 a controlled shutdown, a UA performing passive discovery can detect the shutdown and reissue the subscriptions to an alternate DA. 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 Kempf and Goldschmidt Expires 22 March 2000 [Page 9] Internet Draft Notification and Subscription for SLP 22 October 1999 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 the DAs that 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, 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. 13. 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. References [1] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol. RFC 2608, July 1999. Kempf and Goldschmidt Expires 22 March 2000 [Page 10] Internet Draft Notification and Subscription for SLP 22 October 1999 [2] E. Guttman, C. Perkins, J. Kempf Service Templates and service: Schemes RFC 2609, July 1999. [3] S. Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [4] D. Meyer. Administratively Scoped IP Multicast. RFC 2365, July 1998. [5] D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. RFC 2234, November 1997. [6] http://www.iana.org/in-notes/iana/assignments/multicast-addresses [7] Hanna, S., B. Patel, M. Shah Multicast Address Dynamic Client Allocatin Protocol (MADCAP) draft-ietf-malloc-madcap-XX.txt A work in progress 14. Full Copyright Statement Copyright (C) The Internet Society (1997). 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." Kempf and Goldschmidt Expires 22 March 2000 [Page 11] Internet Draft Notification and Subscription for SLP 22 October 1999 Authors' Addresses James Kempf Jason Goldschmidt Sun Microsystems C0318 Bucknell University UMPK15-214 Lewisburg, PA, 17837 901 San Antonio Rd. USA Palo Alto, CA 94040 USA Phone: +1 650 786 5890 +1 570 577 5624 Email: james.kempf@sun.com jgoldsch@acm.org Kempf and Goldschmidt Expires 22 March 2000 [Page 12]