| This MIB module defines objects that describe flow monitoring.
A typical application of this MIB module will facilitate
monitoring media flows, especially flows carrying video streams.
However, by no means does the definition of this MIB module
prevents other applications from using it.
FLOW MONITORS
=================
At the top level, this MIB module describes the notion of a flow
monitor. A flow monitor is a hardware or software entity that
classifies traffic flows, collects data on conforming traffic
flows, and periodically computes metrics that reflect the
quality of the traffic flows. Because a device can support more
than one flow monitor, the MIB module defines the
cfmFlowMonitorTable. Consider an edge router that supports a
certain line card that has an integrated capability to monitor
video flows. In this example, the cfmFlowMonitorTable would
contain a row describing each line card installed in the device.
TRAFFIC FLOWS
=================
At the next level, this MIB module describes the notion of a
traffic flow. This MIB module uniquely identifies a traffic
flow using an auxiliary variable called cfmFlowId; however, an
implementation only has guarantee its uniqueness within the
scope of the flow monitor that has the responsibility for
monitoring the traffic flow. Thus, we can think of the flow
monitor as a container for the traffic flows for which it
collects data and periodically computes metrics, as the figure
below illustrates.
+----------------------------+
| cfmFlowTable |
| |
+----------------------+ +--------------------------------+
| cfmFlowMonitorId = 3 ----->| +------------------------+ |
+----------------------+ | | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| +------------------------+ |
| +------------------------+ |
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 102 | |
| +------------------------+ |
| : |
| : |
| +------------------------+ |
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 150 | |
| +------------------------+ |
+--------------------------------+
| |
+----------------------+ +--------------------------------+
| cfmFlowMonitorId = 4 ----->| +------------------------+ |
+----------------------+ | | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 1 | |
| +------------------------+ |
| +------------------------+ |
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 2 | |
| +------------------------+ |
| : |
| : |
| +------------------------+ |
| | cfmFlowMonitorId = 4 | |
| | cfmFlowId = 150 | |
| +------------------------+ |
+--------------------------------+
| |
+----------------------------+
While the identifying of a traffic flow using this auxiliary
variable is convenient for the MIB module, it is does suffice
for an EMS/NMS trying to isolate faults in a network delivering
these traffic flows. To aid an EMS/NMS in this task, this MIB
module defines a number of tables that provide layers of data
relating to a traffic flow, including:
o cfmFlowL2VlanTable - describes L2 VLAN data relating to
traffic flows.
o cfmFlowIpTable - describes IP data relating to traffic
flows.
o cfmFlowUdpTable - describes UDP data relating to traffic
flows.
o cfmFlowTcpTable - describes TCP data relating to traffic
flows.
o cfmFlowRtpTable - describes RTP data relating to traffic
flows.
Each of these tables have a sparse dependent relationship on the
cfmFlowTable, as there exist situations when the data may not be
available for a traffic flow, including:
1) The flow monitor simply may not collect the particular
data for the traffic flows that it has the
responsibility of monitoring. For example, a flow
monitor may not have any concern for L2 VLAN data.
2) The data may not apply to a traffic flow. For example,
a TCP and RTP data do not apply for a UDP traffic flow.
To help an EMS/NMS navigate the data collected for a traffic
flow, the corresponding rows are daisy-chained using 'next
objects'. An EMS/NMS starts with cfmFlowNext, which indicates a
reference to the row in the next table containing data related
to the traffic flow. The first object contained by each of
these tables is a 'next object'. Consider a RTP traffic flow
for which the flow monitor has collected IP, UDP, and RTP data.
The figure below illustrates how this MIB module daisy chains
this data through the relevant tables.
+-------------------------------------------+
| cfmFlowTable |
| +---------------------------------------+ |
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 42 | |
| | cfmFlowNext = cfmFlowIpNext.3.42 ----------+
| +---------------------------------------+ | |
+-------------------------------------------+ |
|
+-------------------------------------------+ |
| cfmFlowIpTable | |
| +---------------------------------------+ | |
| | cfmFlowMonitorId = 3 |<---+
| | cfmFlowId = 42 | |
| | cfmFlowIpNext = cfmFlowUdpNext.3.42 -------+
| +---------------------------------------+ | |
+-------------------------------------------+ |
|
+-------------------------------------------+ |
| cfmFlowUdpTable | |
| +---------------------------------------+ | |
| | cfmFlowMonitorId = 3 |<---+
| | cfmFlowId = 42 | |
| | cfmFlowUdpNext = cfmFlowRtpNext.3.42 ------+
| +---------------------------------------+ | |
+-------------------------------------------+ |
|
+-------------------------------------------+ |
| cfmFlowRtpTable | |
| +---------------------------------------+ | |
| | cfmFlowMonitorId = 3 |<---+
| | cfmFlowId = 42 | |
| | cfmFlowRtpNext = zeroDotZero | |
| +---------------------------------------+ |
+-------------------------------------------+
Observe that this structure simplifies the task of extending the
MIB module to support additional layers of data. For example,
if there is a need for a device to collect data relating to the
MPEG-TS layer of a flow carrying a video stream, then it is as
simple as defining a table containing this data. However, the
definition of such a table must comply with the following
requirements:
1) The table must have a sparse dependent relationship on
the cfmFlowTable.
2) The first object contained by the table must be a 'next
object' to support daisy chaining.
REPORTING FLOW METRICS
==========================
At the next level, the MIB defines two tables that together form
the foundation for reporting metrics. The cfmFlowMetricsTable
has a one-to-one dependent relationship on the cfmFlowTable, and
it contains data aggregate metrics and data relating to the
collection of metrics for the corresponding traffic flow. A row
in this table also serves as a container for the historic
metrics computed by the corresponding flow monitor, as the
figure below illustrates.
+----------------------------+
| cfmFlowMetricsIntTable |
| |
+----------------------+ +----------------------------------+
| cfmFlowMetricsEntry |-->| +------------------------------+ |
| | | | cfmFlowMonitorId = 3 | |
| cfmFlowMonitorId = 3 | | | cfmFlowId = 101 | |
| cfmFlowid = 101 | | | cfmFlowMetricsIntNumber = 1 | |
+----------------------+ | +------------------------------+ |
| +------------------------------+ |
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = 2 | |
| +------------------------------+ |
| : |
| : |
| +------------------------------+ |
| | cfmFlowMonitorId = 3 | |
| | cfmFlowId = 101 | |
| | cfmFlowMetricsIntNumber = N | |
| +------------------------------+ |
+----------------------------------+
| |
+----------------------------+
The device collects data for a traffic flow over a configured
measurement interval, indicated by cfmFlowMetricsIntervalTime.
At the end of a measurement interval, the device computes
metrics from this data, generating a report. An EMS/NMS can
access this report using the cfmFlowMetricsIntTable.
cfmFlowMetricsMaxInterval indicates the maximum number of
reports a device will save for the corresponding traffic flow,
while cfmFlowMetricsIntervals indicates the number of reports
currently saved by the device.
The cfmFlowMetricsTable and cfmFlowMetricsIntTable have the
intent of providing a foundation for reporting metrics for a
traffic flow. Furthermore, it is the intent that additional MIB
modules define extensions to these tables describing specific
sets of metrics. The following list provides some examples:
o CISCO-FLOW-MON-MDI-MIB - this MIB module defines
extensions that describe MDI metrics defined by
RFC-4445.
o CISCO-FLOW-MON-RTP-MIB - this MIB module defines
extensions that describe RTP metrics defined by
RFC-3550.
o CISCO-FLOW-MON-IP-CBR-MIB - this MIB module defines
extension that describe IP CBR metrics.
The tables defined by these MIB modules have a sparse dependent
relationhip on the cfmFlowMetricsTable and
cfmFlowMetricsIntTable. An EMS/NMS can determine the metrics
collected for a traffic flow from the corresponding instance of
cfmFlowMetricsCollected, which is nothing more than a bit
string-value for which each bit corresponds to a different set
of metrics.
FAULT MANAGEMENT
====================
At the next level, this MIB module defines tables that describe
standing conditions. A standing condition is a lasting error,
fault, or warning resulting from the application of a set of
criteria to the state of an entity.
For example, a flow monitor ceases monitoring a traffic flow
when it has not received any packets for that traffic flow in a
configured interval of time. If flow monitor expires a
significantly large number of traffic flows during a measurement
interval, then this might signal a fault.
In this example, the 'set of criteria' is a rising threshold and
the 'state of an entity' is the number of traffic flows
expired by a flow monitor.
The cfmConditionTable describes the criteria applied to entities
managed by the device, specifically flow monitors and traffic
flows. The table groups these criteria into 'conditions
profiles'. The device periodically applies these criteria
to an entity and saves the results in a bit string-value
associated with the entity.
An EMS/NMS can monitor the most recent standing conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorConditions. Likewise, an EMS/NMS can monitor the
most recent standing conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsConditions.
It goes without saying that monitoring the standing conditions
for significantly large numbers of traffic flows becomes
problematic. To aid an EMS/NMS in this task, this MIB module
defines many mechanisms. The most basic of these mechanisms is
the notion of an alarm, which is simply a standing condition for
which the device signals changes in state. This MIB module
provides for three means of signaling when the device raises or
clears an alarm condition:
1) Logging - the device creates a record of the event and
saves it in a historical account.
2) syslog - the device generates a syslog message
containing details of the event and sends it to one
or more configured syslog server.
3) SNMP - the device generates a SNMP notification
containing details of the event and sends it to one
or more configured targets.
An EMS/NMS can monitor the most recent alarm conditions for a
flow monitor by retrieving the corresponding instance of
cfmFlowMonitorAlarms. Likewise, the EMS/NMS can monitor the
most recent alarm conditions for a traffic flow by retrieving
the corresponding instance of cfmFlowMetricsAlarms.
Additionally, the EMS/NMS can poll a summary of alarm conditions
maintained for each flow monitor and the traffic flows that it
monitors. The following list summarizes the data contained by
this summary:
o cfmFlowMonitorAlarmSeverity
o cfmFlowMonitorAlarmCriticalCount
o cfmFlowMonitorAlarmMajorCount
o cfmFlowMonitorAlarmMinorCount
o cfmFlowMonitorAlarmWarningCount
o cfmFlowMonitorAlarmInfoCount
An EMS/NMS can also poll cfmAlarmHistoryLastId, which indicates
the value of the identifier assigned to the last record saved to
the historical account. When it observes a change in the value
of this object, then it can retrieve the new records from the
cfmAlarmHistoryTable.
The burden of monitoring alarm conditions for sufficiently large
numbers of traffic flows can itself become a daunting task.
Thus, this MIB module defines the notion of an alarm group,
which represents a single alarm condition that aggregates a
standing condition for a set of traffic flows. The
cfmAlarmGroupTable describes the alarm groups configured for a
device, and the cfmAlarmGroupFlowTable describes the sets of
flows aggregated by these alarm groups.
GLOSSARY
============
Alarm Action - a method used by the device to signal changes in
an alarm condition.
Alarm Aggregation - a technique used to efficiently monitor the
same standing condition for a flow set.
Alarm Condition - a standing condition for which the device
signals changes in state.
Alarm Group - a flow set for which the device monitors a
configured standing condition, raising an alarm when a
configured number of flows in the flow set assert the
standing standing.
Alarm Severity - the relative disposition of an alarm condition
when raised by the device. For example, a provider may
regard a flow stop alarm as having a higher severity than a
flow's loss fraction exceeding a configured threshold.
Flow Monitor - a hardware or software entity that classifies
traffic flows, collects flow data, and periodically
computes flow metrics.
Flow Metric - a measurement that reflects the quality of a
traffic flow.
Flow Point - represents the ingress or egress of a traffic flow.
Flow Set - a group of traffic flows.
Measurement Interval - the length of time over which a flow
monitor collects data related to a traffic flow, after which
the flow monitor computes flow metrics using the collected
data.
Standing Condition - represents a lasting error, fault, or
warning resulting from the application of a set of criteria
to the state of an entity, such as a flow monitor or traffic
flow. For example, a flow monitor may assert a standing
condition if the number of traffic flows that expire in a
measurement interval exceeds a configured threshold.
Traffic Flow - a unidirectional stream of packets conforming to
a classifier. For example, packets having a particular
source IP address, destination IP address, protocol type,
source port number, and destination port number. |
