> I think SENSE has been more of a topic of discussion at printer MIB meetings.
> I don't recall ot getting much attention at IPP meetings. Of course, I have not
> been able to attend all of the meetings, but I have not personally seen a
> pointer to the documentation nor seen a formal presentation on SENSE.
> Would it be worthwhile at an IPP meeting to do this?
For starters, check out the PWG website (http://www.pwg.org) where
you will find the SENSE project listed along with all the other PWG
projects. Follow the link to the SENSE home page, where all the
current documents are listed with easy single-click access to
each and every document.
In particular, I would request that everyone take about 5 minutes
to review the very first document published for SENSE, namely the
"SENSE Proposed Initial Requirements" document located at:
ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt
Since the document is pretty small I have taken the liberty of
attaching it below so folks can start looking at the fundamentals.
If nothing else, some of the functional requirements and constraints
listed in that document could be used to jump-start the IPP async
notification function requirements.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
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 ----------<
# # # # #