V0.10 RBLandau 19960517
Abstract: The Simple Event Notification Service Environment (SENSE) is a client-server communciation service technology for computer networks that enhances the organization and delivery of asynchronous status information. In its simplest form, SENSE is a reliable clearinghouse and delivery service for event notices.
This document describes the "Simple Event Notification Service Environment," abbreviated as "SENSE" throughout this and other related documents and correspondence.
SENSE is a component architecture designed to facilitate the collection and distribution of events within a heterogeneous network environment.
SENSE may be described as being:
The concept of SENSE was originated by JK Martin (Underscore), Rick Landau (Digital) and Mike Timperman (Lexmark) in October, 1995, in response to an identified need for the transmission of events from network printer devices to network management applications specifically 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 distributed network environments.
The original motivation for developing SENSE came from the lack, in most networks, of standard facilities that would be suitable for management of the status information for large groups of network printers and similar network devices. In particular, we felt the need for a service that met the following goals.
The model we have developed for SENSE meets these goals. In particular,
Formal requirements for the SENSE facility are listed below.
A primary motivation for developing SENSE is to improve on the delivery of critical event messages as compared to the SNMP TRAP model. In particular, SENSE should improve on these deficiencies in the SNMP TRAP mechanism:
SENSE must satisfy the following functional and operational requirements (not listed in any particular order).
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.
Since stream-oriented protocols are typically considered too "heavy" for lightweight services, datagrams should be used for all SENSE protocol implementations. 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 datagram-oriented transports:
Other datagram-oriented transports are not necessarily precluded from implementation.
To facilitate interoperability, the Server should be able to operate using a standard, "well known" 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 specified so as to allow a Server to operate in an environment in which the standard transport address is already in use, or when an unprivileged user wishes to operate a Server when the standard transport address requires privileges. This requirement should be considered optional for an implementation.
The overall capabilities described by SENSE do not require complex nor significant resources. Hence, the SENSE specification should not require the use of facilities that are not readily and/or inexpensively available within the many desktop and server operating systems. Examples of facilities that would be considered not readily available are: DCE, ToolTalk, CORBA, Kerberos, and other such facilities that are either prohibitively expensive or unavailable on many platforms. Use of such facilities is considered optional.
A Server should be able to represent any number of Event Sources. No minimum or maximum number of supported Event Sources should be formally specified.
A Client should be able to request the list of event sources supported by the Server.
A Client should be able to request a list of operational parameters and their values from the Server.
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 R.8 above.
A Client should be able dynamically to request delivery or non-delivery of events from any source represented on a Server. A Client should be able to register for multiple event sources simultaneously.
When the Client requests the receipt of events from a source, part of the request includes the destination transport address (network address and transport port number) to which all Event Messages are delivered.
A Client is free to cancel receipt of events before the assigned time period expires.
The Server should send Event Messages to the network/transport address specified by the Client as such events occur.
The Server will periodically retransmit an Event Message until either the Client acknowledges receipt of the Event Message or a Server-defined retransmit count expires. A Client must acknowledge receipt of an Event Message so that the Server will cease retransmission of the Event Message.
An Event Message can optionally contain a data component that is not related to nor relevant to the SENSE system; instead, the receiving Client is expected to be familiar with the format of such messages based on the associated event source.
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:
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 R.8 above.
The basic ideas behind SENSE are modeled on a concept that should be familiar and meaningful to a wide audience, publishing a magazine. The mapping between the concepts of magazine publishing and the abstractions of SENSE is not precise, but it is instructive.
The key components of this model are
| Publication | A collection of information of interest to one or more persons. The contents of Publications typically have very specific focus. For example, Time = general news, Business Week = business news, People = gossip news. |
| Publisher | The person responsible for the content of a Publication. The Publisher ensures the Publication is published as specified. A single Publisher may be responsible for multiple Publications. |
| Edition | A version of a Publication with some special characteristics. For example, an Edition may be specific to a language (English, Spanish, etc.), to a region (Northeast, Mid-Atlantic, etc.), to a timeframe (daily, weekly, etc.), and so forth. |
| Subscriber | A person interested in receiving issues of Editions of Publications. The subscriber's interest in Publications is primarily based on content, but interest in Editions is generally based on other factors such as geographic focus, language, etc. |
| Subscription | A time-limited association between an Edition and a Subscriber. When an issue of an Edition is published, a copy of that issue is delivered to all (active) Subscribers. |
| Fulfillment House | A clearinghouse to which Publishers submit (issues of Editions of) Publications that are subsequently delivered to Subscribers. |
| Management | Coordinates the operations of the Fulfillment House to ensure that all activities are performed in an efficient manner consistent with established policy. Management typically reserves the right to accept or cancel Subscriptions or Publications at will based on policy. |
SENSE uses much terminology derived largely from this Magazine Publishing Model: Publisher, Publication, Edition, Subscriber, Subscription, etc.
The simplest sensible SENSE system includes a Server and two Clients: a Publisher, and a Subscriber.
The Publisher first registers with the Server to identify itself. Then the Publisher registers a Publication that represents a physical or logical object in the network. Once the Publication is established, the Publisher registers one or more Editions of the Publication. Once an Edition is established, the Publisher can issue events to the Server, and the Server will forward those events to interested Subscribers, if any.
The Subscriber first registers with the Server to identify itself. The Subscriber can request from the Server a list of Publications and Editions. The Subscriber registers for a period of time with the Server, and then can subscribe to any available Editions. If any events are published during the period of the subscription, the Server will reliably forward them to the Subscriber.
Subscriptions last either until the Client unsubscribes from the Edition, or until the Client's session terminates. The session may be terminated explicitly by the Client (using "Unregister") or implicitly when the registration period expires.
The flexibility of the SENSE system comes primarily from the generality of relationships in the system design.
A Client communicates with a SENSE Server through the Client interface. To perform most functions, Clients must register with the SENSE Server. If a Client has not registered with the Server, then it is a Transient Client, and it can perform only a few, exploratory operations.
A Client registers with the Server for some period of time. The Client requests a registration period, and the Server grants the registration for some period (less than or equal to the requested period). The Client may terminate the registration prematurely, or the Server will terminate the registration when the period expires.
Registered Clients generally fall into three different categories: Publishers, Subscribers, and Managers. There is no enforced distinction between these categories; the differences are largely in the types of operations that a Client happens to perform after registering. A registered Client may perform operations appropriate to more than one type of Client. In particular, Translator and Replicator applications always function simultaneously as Subscribers and Publishers. (See Appendix C for descriptions of these applications.)
A Publisher is a Client that registers with a Server and then registers Publications and/or Editions. The Publisher that first registers a Publication is called the Primary Publisher. Any other Publishers that register Editions of that Publication are Secondary Publishers. A single Publisher application may be both a Primary and a Secondary Publisher; in fact, this may be the most common case.
A Publisher may register one or more Publications, one or more Editions of any Publications, and may issue Events for any Editions it has registered.
A Publisher represents the state and activity of a managed entity to the SENSE network. A Publisher's main activity is to issue Event Messages for Edition(s) that it has registered. The SENSE Server's responsibility is to forward those Events to Subscribers of that Edition.
A Subscriber is a Client that has subscribed to one or more Editions in a Server.
A registered Client may subscribe to receive Events from the Server associated with one or more Editions. The Client subscribes to an Edition within the server. If any events are published for that Edition during the subscription period, the Server will forward the Events to the Subscriber.
A Subscriber is generally an application that is monitoring the status and activity of some managed entities in the network. A Subscriber registers with one or more SENSE Servers and subscribes to one or more Editions relating to some entities. A Subscriber chooses Publications (entities) depending on the user's interests, and Editions depending on the its capabilities to understand particular event notices and event notification syntax.
A registered Client may perform management operations on the Server. At the moment, the security requirements and procedures for a Client to use this interface have not been clearly stated. Manager clients will be required to authenticate with the Server using at least password-level security.
SENSE applications can be both Subscribers and Publishers at the same time. This enables some unusual applications, called Replicators and Translators, that subscribe to some Publications in some Servers and republish them, possibly in altered form, in other Servers. See Appendix C for details of these applications.
A Publication is a top-level representation of an object in the network. Publications should be one-to-one with managed objects in the network. Each device, program, or other object in the network that generates Events and wants to use SENSE services should have exactly one Publication.
Publications, once created, persist at least for the life of the SENSE Server (unless they are explicitly destroyed by the Primary Publisher). In some Server implementations, at the option of the Publisher, Publications may be persistent across power cycles of the Server.
Rationale: This is done to provide consistent human interface. For instance, even though installed devices may be powered off, down for maintenance, etc., they should still appear in lists and menus visible to users. They should not disappear and reappear suddenly in user applications due to transient conditions. An object represented by a Publication should appear continuously, even though the (Primary) Publisher responsible for the Publication may not be registered with the Server for a time.
A persistent Publication is "owned" by its Primary Publisher, that is, by the Publisher that originally registered it. In some Server implementations, there may be some security associated with a persistent Publication. For instance, only the Primary Publisher might be permitted to modify some properties of a Publication; or Secondary Publishers may not be permitted to issue Events in their Editions unless the Primary Publisher is registered.
Additionally, there may be some boundary conditions that require both Publisher and Subscriber applications to be written tolerantly. For instance, when a Server is started with a persistent Publication available, which Publishers can publish event messages, depending on the order of re-registration of the Primary and Secondary Publishers? Different Servers and different Publications may have different rules regarding these boundary cases.
[[more tbs]]
There is always at least one Publication and one Edition on any given Server. A SENSE Server publishes a Publication about the Server itself and several Editions of Server-related events. Server-related events include, for example, registering and unregistering Publications and Editions. That is, every time a new Publication or Edition is registered, the Server publishes an Event message recording that event. Similarly registration or deregistration of any of the fundamental objects in the Server generate events in the Server's Publication.
Some simple Subscriber applications will statically subscribe to certain Editions, and will not change those subscriptions during their lifetimes. Some more complex applications may subscribe to Server events to watch for new (or obsolete) Publications and Editions, and may change subscriptions accordingly.
See Appendix D for details of the Server Publication and required Editions.
A Publication may have one or more associated Editions. An Edition is a source of events for its Publication. Typically, Editions are distinguished either by content or by syntax. Following the magazine publishing model analogy, there might be regional Editions that contain different articles or advertising; or national Editions written in different languages. SENSE Editions might describe different subsets of the Events of the Publication or different data syntaxes in which those events are described.
Example of content-oriented Editions: Publish different Editions for different types of alarms, such as "all alarms," "intervention required alarms only," "accounting records only," etc.
Example of syntax-oriented Editions: Publish one Edition that describes events in SNMP Trap syntax, another in NPAP alarm syntax.
An object instance can have any number of properties. A property has a name and a value, both strings. There is a small number of reserved properties that are special to the SENSE Servers or Clients; otherwise, the Server and Clients do not place any interpretation on the name or value of properties.
In V1 of the SENSE protocol, the names and values of all properties must be printable strings in the ISO Latin-1 character set. (In future versions of the protocol, the names and values of other properties may be extended to be expressed in any character set, in particular Unicode.)
Property names follow a hierarchical, segmented structure similar to those of X Window System resource names. The name consists of a list of segment names separated by dots, with the more general segment on the left and the more specific on the right of the dot. Example: cars.honda.windows.windshield.
Publications and Editions are required to have certain properties. See Appendix B for the list of reserved property names and the list of properties that must be defined for any Publication or Edition.
A property sheet is a list of properties and values.
A set of properties whose names share a prefix are sometimes referred to as a Property Group. For instance, the set of properties {AAA.x,AAA.y,AAA.z} can be referred to as "the AAA property group" or "the AAA.* property group."
A special property group with the reserved name "Condition" will always be available for a Publication.
A registration is the binding of a Client to a Server. A Client must register with a Server before it can perform any but the most basic inspection operations.
Registration of a Client with a SENSE Server lasts for a limited time period. Near the end of the registration period, the Server may optionally notify the Subscriber that the registration is about to lapse.
A subscription is the binding of a Subscriber Client to an Edition for a period of time. During the subscription period, the Server will forward to the Subscriber any Events published for that Edition.
An Event is a message published for an Edition of a Publication. A Publisher sends the Event to the Server, and the Server forwards the Event to Subscribers (if any).
An Event message from the Publisher contains a block of opaque data, in the data syntax appropriate to the Edition, and a property sheet containing property names and values. The Server labels each message with a unique, Server-assigned id number, and also adds a property containing the Server time stamp.
All Event messages shall contain a set of standard properties supplied by the SENSE Server: Id and Timestamp, as mentioned above. Event messages of any Edition also carry a standard set of properties that depend on the Edition. Consult the specification for the particular Edition to determine the properties delivered with each event message.
When a Server sends an Event message to a Subscriber, the Subscriber must acknowledge receipt of the event. If the Server does not receive an acknowledgment from the Subscriber, it will resend the Event message.
The timeout period for retransmitting Events and the stopping conditions on retransmissions, whether number of retries or time period, are configurable within the Server.
[[We may one-plus this to permit the retransmission parameters to be negotiated at the time of Client registration. In that case, the ranges of acceptable parameter values will be configurable within the Server. Is this overkill?]]
In general, when an object is created in the Server, it is assigned a numeric ID by the Server. This ID persists as long as the object exists within the Server, and as long as the instance of the Server exists.
Ids are recycled very slowly within the Server. After an object instance is destroyed, its id is not reused (within this instantiation of the Server) until the integer value used internally in the Server wraps around zero.
Associated with every object class in the Server is a Server property with a reserved name that enumerates the ids (handles) instances of that object. For an object class named Foo, the property is named FooIdList. The value of the property is a comma-separated list of the numeric ids of the instances of the object within that Server. For example, the Server property PublicationIdList enumerates the ids of the Publications within the Server; similarly for EditionIdList, ClientIdList, SubscriberIdList, etc.
The way this scenario is handled in SENSE is that all Clients (except "Transient" Clients) must register with the Server as either a Subscriber, Publisher or Manager. Every Session registration involves a registration period that is "negotiated" between the Client and Server.
The negotiation of a registration period is quite simple and is designed to be "Server-centric" in that the Client "requests" a particular registration period in the registration request message, and the Server "declares" the actual registration period in the corresponding response message. This approach gives a Server a great deal of flexibility in managing its resources by being able to enforce short registration periods, if necessary, when it appears that too many Clients fail to properly deregister when they no longer have need for SENSE services.
When the registration period for a Client is about to expire, the Client must continue the Session by sending the Server a renewal request. Similar to the registration request described above, the Client again proposes a registration period, and the Server responds with the value that is actually used.
When a Client Session is about to expire, the Server may optionally assist the Client in managing this situation by sending the Client an expiration notice to "nudge" the Client in sending a renewal request. This optional Server capability alleviates Client application developers from having to deal with potentially difficult timer facilities on the local platform.
A SENSE Server provides a modest level of Directory Services to its Clients to minimize the dependency on external facilities that may not be available in all platform or network environments.
The services needed by most Clients fall into two general categories of requests:
| ObjectGetFirst/Next | Enumerate objects of certain types. |
| ObjectGetProperties | Get the values of one or more properties for the specified Object. |
Each of these requests can be made of one of the following Object types:
Classes of objects may be enumerated with the ObjectGetFirst and ObjectGetNext functions. A response to a ObjectGetFirst or ObjectGetNext request is the handle of, and optionally other properties of, an object of a given class.
A response to a ObjectGetProperties request is a PropertyList containing the names and values of a set of Properties specified in the request. Wildcards may be used to retrieve all currently defined Properties or specific Property Groups.
A Server may elect to not support these services for particular Object classes due to security concerns. For example, it may not be desirable within a given environment to allow arbitrary Clients to have access to identification information for other Clients or Subscribers currently registered on the Server.
Events form the backbone of existence for SENSE. The simple goal for SENSE in this respect is to allow the passage of opaque event data from a Publisher (on behalf of a registered Publication), through the Server, and on to all registered Subscribers. The protocol and services provided by a SENSE Server provide a wrapper protocol that allows an arbitrary Publisher to propagate any kind of data—even binary data—through a Server and on to any number of Subscribers (only limited by the resources of the Server).
Perhaps more importantly are the facilities provided by SENSE to maximize the likelihood of successful receipt of events by Subscribers. The delivery mechanism used by a Server includes multiple retries in sending any given Event Message to a target Subscriber; the Server will repeatedly send the Event Message until either the Client acknowledges receipt of the message, or the retry count is exceeded. (The maximum retry count is one of the properties negotiated between the Client and the Server when the Client registers or renews a Session with the Server.)
One of the defining characteristics of a Publication is which Event Protocols are supported by the Publication. The term Event Protocol is used here to denote the set of Properties contained within an Event Message, as well as the content and format of an optional opaque data component attached to the message.
Note that using the term "Event Protocol" is really a misnomer here, since there is no real protocol exchange between the Publisher and its (anonymous) Subscribers. The term is used, however, as it is expected that most Publishers will use SENSE to encapsulate the contents of certain PDUs for distribution to interested Subscribers, since SENSE offers significantly improved event distribution services when compared with the native services associated with such PDUs.
SNMP is a prime example of this scenario, whereby TRAP messages are sent in such a manner that interested Client applications may dynamically commence receiving TRAPs from a number of SNMP agents, then disassociate themselves from reception, all without the SNMP agents being involved in the process, particularly in the process of defining and redefining destination TRAP addresses.
All that must be done to provide this kind of capability is to write a SENSE Publisher that communicates with a SNMP agent (as a type of "proxy" agent) and publishes a corresponding Publication on a SENSE Server. Alternatively, SENSE Publisher capabilities could be directly integrated within the SNMP agent.
One of the challenges of SENSE is to enumerate or otherwise register the set of names and/or identifiers that specify particular Event Protocols, such as SNMP.
As of this writing, the topic of SENSE Management Services has not yet received much attention due to other, more pressing requirements to establish the basic foundation and infrastructure. However, it is expected that a modest level of services in this area will be developed to provide for these types of management activities:
| Set Server Properties | Set one or more operational controls or identifying properties of a Server. |
| Terminate Client | Terminate a Client for any number of reasons, ranging from security to resource recapture (due to an errant Client application) to version updating activities. |
| Terminate Publication | Similar to Client Termination, but targeted at Publications. |
| Shutdown/Restart Server | Control the orderly, graceful shutdown of a Server so that all currently registered Clients may properly handle the interruption of services. |
[[outline only]]
idlist, id, class,