CISCO-FLOW-MONITOR-MIB
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.