4. Workflow Explanations
Cette section conserve le texte RFC de la network fault and problem management terminology, y compris Event, State, Fault, Problem, Symptom, Cause, Alert, Alarm, workflow figures, security, privacy et IANA considerations.
4. Workflow Explanations
This section aims to add information about the relationship between
the terms defined in Section 3.2 in the context of network fault and
problem management. The text and figures here are for explanation
and are not normative for the definition of terms.
The relationship between Resources and Characteristics is shown in
Figure 1. Note that there is a 1:n relationship between a Network
system and Resources and between Resources and Characteristics: For
clarity, this is not shown in the figure.
Characteristics
^
|
Resources
^
|
Network system
Figure 1: Resources and Characteristics
The Value of a Characteristic of a Resource may change over time.
Specific Changes in Value may be noticed at a specific time (as
digital Changes), Detected, and treated as Events. This is shown on
the left-hand side of Figure 2.
The center of Figure 2 shows how the Value of a Characteristic may
change over time. The Value may be Detected at specific times or
periodically and give rise to Conditions that are States (and
consequently State Changes).
In practice, the Characteristic may vary in an analog manner over
time as shown on the right-hand side of Figure 2. The Value can be
read or reported (i.e., Detected) periodically leading to analog
Values that may be deemed Relevant Values, or it may be evaluated
over time as shown in Figure 6.
Event State Value
Condition
^ ^ ^
Detect : Detect : Detect :
: : :
^ ^ ^ ^ ^ /\
: : : : : / \
: : : : : /\ / \
__ __ _____ / \/
| | | | /\/
__| |__ ____| |____ /
Change at a time Change over time Change over time
Figure 2: Characteristics and Changes
Figure 3 shows the workflow progress for Events. As noted above, an
Event is a Change in the Value of a Characteristic at a time. The
Event may be evaluated (considering policy, relative to a specific
perspective, with a view to intent, and in relation to other Events,
States, and Values) to determine if it is an Occurrence and possibly
to indicate a Change of State. An Occurrence may be undesirable (a
Fault), which might cause an Alert to be generated. Or, an
Occurrence may be evidence of a Problem and could directly indicate a
Cause. In some cases, an Alert may give rise to an Alarm
highlighting the potential or actual presence of a Problem.
Alert - - - > Alarm
^
|
| -----> Cause
| |
|----------> Problem
|
|
Fault
^
|
|
|
Occurrence
^
|
|----------> State
|
|
Event
Figure 3: Event and Dependent Terms
Parallel to the workflow for Events, Figure 4 shows the workflow
progress for States. As shown in Figure 2, Change noted at a
particular time gives rise to State. The State may be deemed to have
Relevance considering policy, relative to a specific perspective,
with a view to intent, and in relation to other Events, States, and
Values. A Relevant State may be deemed a Problem, or it may indicate
a Problem or potential Problem.
Problems may be considered based on Symptoms and may map directly or
indirectly to Causes. An Incident results from one or more Problems.
An Alarm may be raised as the result of a Problem, and the transition
to an alarmed State may give rise to an Alert.
Alarm - - -> Alert
^
| ------> Incident
| |
| | ---> Cause
| | |
Problem---------> Symptom
^
|
| Relevance
|
|
State
Figure 4: State and Dependent Terms
Figure 5 shows how Faults and Problems may be consolidated to
determine the Causes. The arrows show how one item may give rise to
another.
A Cause can be indicated by or determined from Faults, Problems, and
Symptoms. It may be that one Cause points to another, and it can
also be considered as a Symptom. The determination of Causes can
consider multiple inputs. An Incident results from one or more
Problems.
---------
------------- | |
| ----------> | Symptom |
| | | |
| | ---------
v | ^
--------- |
------->| Cause |<--------- |
| --------- | |
| ^ | | |
| | | | |
| --- | |
| | |
--------- --------- ----------
| Fault |------------------->| Problem |------->| Incident |
--------- --------- ----------
Figure 5: Consolidation of Symptoms and Causes
Figure 6 shows how thresholds are important in the consideration of
analog Values and Events. The arrows in the figure show how one item
may give rise to or utilize another. The use of threshold-driven
Events and States (and the Alerts that they might give rise to) must
be treated with caution to dampen any "flapping" (so that consistent
States may be observed) and to avoid overwhelming management
processes or systems. Analog Values may be read or notified from the
Resource and could transition a threshold, be deemed Relevant Values,
or be evaluated over time. Events may be counted, and the Count may
cross a threshold or reach a Relevant Value.
The Threshold Process may be implementation specific and subject to
policies. When a threshold is crossed and any other conditions are
matched, an Event may be determined and treated like any other Event.
Occurrence
^
|
|---------------------> State
|
| ------- Relevance
|------>| Count |-----------------------------> Value
| ------- | ^
| | | |
| | | | Relevance
| | v |
| | ----------- ----------------
Event | | Evaluated | | |
^ | | over time |<--------| Analog Value |
| v ----------- | |
| ----------- | | |
| | Threshold | | | |
|<----| Process |<------ | |
| | |<----------------------| |
| ----------- ----------------
| ^
| |
| Detect Detect |
| |
Change at a Time Change over Time
Figure 6: Counts, Thresholds, and Values