Simple Event Notification Service Environment (SENSE) Proposed Initial Requirements Version 1.0 28 November 1995 This document describes the requirements for a Simple Event Notification Service Environment (SENSE) and related protocol(s). This document is intended to serve as a basis for ongoing research and discussion by interested parties in developing more formal specifications and implementations. Overview -------- The need for SENSE stems from the widespread need for simple notification of events from various kinds of network entities to network clients. Work in this area was originated by JK Martin (Underscore), Rick Landau (Digital) and Mike Timperman (Lexmark) in response to an identified need for transmission of events from network printer devices to network management applications designed to monitor such devices. As work progressed it became readily apparent that the need for such notification services are pervasive in today's widespread client/server environments. The operative word in this initiative is "simple"; the intent is to derive a very simple facility that serves as a "wrapper protocol" that can support the delivery of event messages from a wide variety of sources. It is all too easy to go "hog wild" and specify intricate mechanisms for such a facility. It is the intent of the original development group to keep the SENSE facility very, very simple so as to support both simple client implementations and simple server implementations. It is a specific goal to make the SENSE facility easily implementable in small embedded systems, such as low-cost network printers and printer server devices. While it is not the intent to support only network printer devices, the final results of this initiative should support network printer devices to the maximum extent possible. Glossary -------- Following is a brief set of terms used elsewhere in this document: Event Any single instance of time-oriented information that may arise during the operation of an entity. There are no semantics associated with an Event; an Event can be anything from a "warning" to an "alert" to a simple informational statement. Event Source An entity that emits Events during its operation. Event Message A message containing an Event. The contents and format of the message are not defined by the SENSE facility; that is, the message content is opaque with respect to the protocol used by the SENSE facility. Event Server A network entity that provides event notification services. Event Client A network entity that consumes event notification services. Registration The transaction initiated by an Event Client to an Event Server in which the Client requests services from the Server. A Server expects Registration requests at any time during its operation. Subscription The relationship between an Event Client and an Event Server. A Client registers a Subscription with the Server for an agreed upon period of time, afterwhich the Subscription is automatically terminated by the Server. A "Subscription" can be viewed as a time-limited session between a Client and a Server. SENSE Requirements ------------------ A primary motivation for developing the SENSE specification is to improve the delivery of critical messages as compared to the SNMP TRAP model. In particular, the SENSE specification should improve on these difficiencies in the SNMP TRAP mechanism: - No standard method for adding/removing TRAP destination addresses, either statically or dynamically - All TRAP messages are directed to a fixed UDP port number, thereby forcing the implementation of a demultiplexing mechanism on hosts where multiple recipients operate - Only a single copy of the TRAP message is delivered to any given destination address; if the message gets lost, then no recipient is able to determine that a TRAP message was sent SENSE must satisfy the following functional and operational requirements (not listed in any particular order): 1. Relatively reliable receipt of Event Messages A key requirement is for a Client to expect reasonably reliable receipt of Event Messages. The term "reasonably reliable" is used to denote the fact that a Server should make multiple attempts to deliver the message to the Client. It should be noted that absolute reliability is not considered practical, and thus, not considered as a requirement. 2. Datagrams are used at the transport layer Since stream-oriented protocols are typically considered too "heavy" for lightweight services, datagrams should be used for all SENSE protocol implementations. 3. A well-known transport address is defined for common use To facilitate interoperability, the Server should operate using a standard, "well known" transport address. 4. A Server can operate using any transport address The Server should be able to operate with any defined address within the target transport environment. This will, of course, require that Clients know of and use the non-standard transport address. This requirement is called out so as to allow a Server to operate in an environment in which the standard transport address is already in use. This requirement should be considered optional for an implementation. 5. Minimal protocol data formatting requirements To maintain simplicity, the protocol data units (PDUs) should use displayable text strings for all data components rather than the equivalent binary forms. Using displayable text circumvents the incompatibilities between various network platforms and allows for simple implementation of Client applications. Since the number of PDUs exchanged between a Client and a Server is expected to be rather small, the resulting parsing of the data components by the Client and Server should not be considered a performance problem. 6. Multiple sources of events can be managed by a single Server A Server should be able to "front-end" any number of Event Sources. No minimum or maximum number of supported Event Sources should be required. 7. A Server can be queried to determine the set of event sources managed by the Server A Client should be able to request the list of Event Sources supported by the Server. The list should be formatted in displayable text. 8. A Server can be queried to determine its operational parameters A Client should be able to request a list of operational parameters and their values from the Server. The list should be formatted in displayable text. 9. A simple loopback capability to determine Server existence A Client should be able to "ping" the Server to determine whether the Server is operating at the target transport address. This requirement could be reasonably satisfied through the implementation of Requirement #8 above 10. A client dynamically registers for receipt of events from multiple event sources A Client should be able to dynamically request the creation of a Subscription from a Server, in which any number of Event Sources may be specified as being part of the Subscription. The Subscription request also includes a requested period of time for which the Subscription remains active; once this time period is exceeded, the Server automatically terminates the Subscription without further action by the Client. 11. A client specifies the network endpoint to which all Event Messages are directed When the Client requests the creation of a Subscription, part of the request includes the destination transport address (network address and transport port number) to which all Event Messages are delivered. 12. A client can cancel a subscription at any time A Client is free to prematurely cancel a Subscription (before the Subscription period runs out). 13. Event Messages are asynchronously transmitted by the Server to all registered clients when an event occurs The Server should send Event Messages to the network/transport address specified by the Client at Subscription request time as events occur. The Server will continue to periodically retransmit an Event Message until either the Server-defined retransmit time/count runs out, or until the Client acknowledges receipt of the event. 14. Clients acknowledge receipt of events A Client must acknowledge receipt of an Event Message from a Server. 15. The precise content and format of an Event Message is opaque relative to the underlying SENSE protocol The format and contents of an Event Message are (by definition) not defined within the SENSE specification; instead, the Client is expected to be intimately familiar with the format of such messages based on the associated Event Source. 16. A Server must be able to control resource consumption A key aspect of the SENSE facility is to be highly "Server-oriented" with respect to implementation and performance. In particular, the Server should be allowed to arbitrarily implement the values for such parameters as: Maximum number of Subscriptions Maximum Subscription period Maximum number of retries for delivery of event messages It is expected that the values of these parameters (and probably many others) will be part of the response to a request for a Server's operational parameters as described in Requirement #8 above. While not called out as a requirement in the above list, it is expected that the SENSE facility should be implemented for use with at least the following transports: - UDP/IP - IPX - AppleTalk DDP Other datagram-oriented transports are not necessarily precluded from implementation. Functional Model ---------------- A crude structural diagram that can be used to describe the desired functional model is shown below: Client -----| . | |--- Event Source . | | . . | | . Client -----+----- Server ---+--- Event Source . | | . . | | . . | |--- Event Source . | Client -----| This diagram describes the three primary interworking entities: Client Server Event Source The protocol used between the Client and the Server is expected to be defined for the SENSE facility. On the other hand, the protocol(s) between the Server and the Event Sources are not expected to be defined in the SENSE specification. Protocol Exchange Example ------------------------- Following is a rough protocol diagram describing the basic, error-free exchange between a Client and a Server whereby: o The Client registers a Subscription with the Server o The Server later sends Event Messages to the Client o The Client cancels the Subscription Client Server ------ ------ >---------- registration request ----------> <---------- registration reply ----------< . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . <---------- event message ----------< >---------- event acknowledgement ---------> . . . >---------- termination request ----------> <---------- termination reply ----------< # # # # #