----------------------------------------------------------------------------------------
3.5 Event Classes
Notifications can be classified into a number of event classes. Each
event class identifies a set of event notifications which
- share similar content
- are generated from similar events
- expect similar handling on the manager/agent side
- are used for similar purpose
The initial set of event classes are configuration, state, rpc-reply,
maintenance, heartbeat, fault. Netconf defines a set of standard
event classes but allows a netconf server to use other vendor specific
event classes if the proposed event or it's usage can not fit the
standard classes.
All events shall carry the following data: detailed event type,
event class timestamp, sequence number of the notification
and are free to carry additional data.
For each class the following is included:
- definition, including triggering events
- expected handling
- expected data, additional data is allowed
- examples
- why do we need the event class
A configuration event, alternatively known as an inventory
event, is used to indicate that hardware, software, or a
service has been added/changed/removed.
- As configuration notifications could potentially carry huge
amounts of data it is expected that netconf clients will use
filtering to reduce their number and possibly their data content.
- The notification might carry the changed data itself or rather
some kind of pointer to the changed part of the configuration.
It is discouraged to include big amounts of configuration data
in the notification or to simply repeat the content of the
netconf operation that triggered the notification
- Examples: HW board removed, SW module loaded, DNS server reconfigured.
- As multiple independent sources can configure a netconf server
node, netconf clients need to be aware of configuration operations
issued by other clients and events like physical HW removal.
A state event indicates a change from one state to another, where a
state is a condition or stage in the existence of a managed entity.
If the state can indicate some kind of fault e.g. link failed the
notification shall be sent as a fault notification. The state
event is not a direct result of a
configuration operation but rather a result of a network event a
node internal event or an indirect result of a configuration event
- No special handling.
- The notification shall identify the object who's state changed
and the new state.
- Examples: Operational state of an interface has changed to up.
- Internal states of a node are important for supervision purposes
and also effect how a node can be configured.
A maintenance event signals the beginning, process or end of an
action generated by a manual or automated maintenance action.
If the maintenance event is a direct result of a
configuration management operation on this Netconf session then
an rpc-reply notification should be used.
- no special handling
- Expected data: description of the maintenance process, the stage
the process
has reached, the manual action, automatic process that triggered
the notification
- Examples: automatic backup completed
- Network management needs to know about the success or failure
of certain maintenance operations that were not triggered by the
event receiving management entity.
An rpc-reply event is triggered by a specific Netconf operation
that sends back multiple response messages. The first message
indicates the unsuccessful/successful starting of an operation
that might take a longer time to complete. Succeeding messages
return further results.
- The netconf server and the management application should be
able to link the event with the triggering operation.
- Expected data: Reference to the triggering operation including
session-Id and message-id, sequence number
- Examples: end result of a long running operation, successive
results of a ping test
- Some operation can take a longer time to complete or produce
multiple results in which case both an initial and one or more
late result are needed
A heart beat event is sent periodically to enable testing that the
communications channel is still functional.
- On reception the liveliness of the channel is confirmed, after
this the notification is simply discarded not even logged.
- Expected data: sequence number
A fault notification is generated when a fault condition occurs.
Depending on the severity of the fault the notification might be
considered an alarm or a warning.
- This notification represent an undesirable situation. It is
expected that a manager will sooner or later take action to rectify
the fault. The agent shall try to send the fault notification without
any delay or buffering.
- The fault notification should carry the following data: severity,
event source, probable cause, specific problem, additional information
- Examples: communications alarm, environmental alarm,
equipment alarm, processing error alarm, quality of service alarm, or
a threshold crossing event. See RFC3877 and RFC2819 for more
information.
- fault notifications are not the main aim of this configuration
protocol,
however they are included as faults have a relevance for
configuration management.
----------------------------------------------------------------------------------------
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>