RFC 3577
Introduction to the Remote Monitoring (RMON) Family of MIB Modules
RFC 3577: Introduction to the Remote Monitoring (RMON) Family of MIB Modules 🎀
okay bestie, this is the RFC that gives you the map of the whole RMON family 🗺️✨ It's an Informational doc from the Network Working Group, dated August 2003.
- RFC number: 3577
- Title: Introduction to the Remote Monitoring (RMON) Family of MIB Modules
- Authors: S. Waldbusser (AT&T), R. Cole (AT&T), C. Kalbfleisch (Verio, Inc.), D. Romascanu (Avaya)
- Category: Informational
- Date: August 2003
- Obsoletes / Updates: nothing is listed in the title block, so this one doesn't obsolete or update any other RFC 💅
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract
The Remote Monitoring (RMON) Framework is a bunch of documents that are all interrelated 🧶 This memo explains what those documents are and how they connect to each other.
Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 2
2. Definition of RMON . . . . . . . . . . . . . . . . . . . . . . 2
3. Goals of RMON. . . . . . . . . . . . . . . . . . . . . . . . . 3
4. RMON Documents . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RMON-1 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Token Ring Extensions to RMON MIB. . . . . . . . . . . . 7
4.3. The RMON-2 MIB . . . . . . . . . . . . . . . . . . . . . 9
4.4. RMON MIB Protocol Identifiers. . . . . . . . . . . . . . 10
4.5. Remote Network Monitoring MIB Extensions for Switched
Networks (SMON MIB). . . . . . . . . . . . . . . . . . . 10
4.6. RMON MIB Extensions for Interface Parameters Monitoring
(IFTOPN) . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. RMON Extensions for Differentiated Services (DSMON MIB). 12
4.8. RMON for High Capacity Networks (HCRMON MIB) . . . . . . 13
4.9. Application Performance Measurement MIB (APM MIB). . . . 14
4.10. RMON MIB Protocol Identifier Reference Extensions. . . . 15
4.11. Transport Performance Metrics MIB (TPM MIB). . . . . . . 16
4.12. Synthetic Sources for Performance Monitoring MIB
(SSPM MIB) . . . . . . . . . . . . . . . . . . . . . . . 17
4.13. RMON MIB Extensions for High Capacity Alarms . . . . . . 17
4.14. Real-Time Application Quality of Service Monitoring
(RAQMON) MIB . . . . . . . . . . . . . . . . . . . . . . 17
5. RMON Framework Components. . . . . . . . . . . . . . . . . . . 18
5.1. MediaIndependent Table . . . . . . . . . . . . . . . . . 18
5.2. Protocol Directory . . . . . . . . . . . . . . . . . . . 19
5.3. Application Directory and appLocalIndex. . . . . . . . . 21
5.4. Data Source. . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Capabilities . . . . . . . . . . . . . . . . . . . . . . 22
5.6. Control Tables . . . . . . . . . . . . . . . . . . . . . 23
6. Relationship of the SSPM MIB with the APM and TPM MIBs . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 311. The Internet-Standard Management Framework ✨
If you want the detailed tour of the docs that describe the current Internet-Standard Management Framework, go check section 7 of RFC 3410 [RFC3410] 📚
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🗄️ MIB objects are usually reached through the Simple Network Management Protocol (SNMP). The objects inside the MIB are defined using the rules in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🎀
2. Definition of RMON 🛰️
Remote network monitoring devices, which people often call monitors or probes, are instruments that exist to manage and/or monitor a network 👀 These probes are usually stand-alone boxes that put a lot of their own internal resources toward one job: managing a network. An organization might use a bunch of them, up to one per network segment, to manage its internet 🌐 They can also manage a remote network, like when a service provider's network management support center watches a client's network, or when an enterprise's central support team keeps an eye on a remote site 🏢
When work on the RMON documents first started, this device-oriented definition of RMON was taken super literally. RMON devices were purpose-built probes dedicated to running the RMON MIB modules. Then cards showed up that added RMON capability into a network hub, switch or router 🔌 RMON also started showing up as a software feature added to certain network equipment, and as software applications that could run on servers or clients 💻 Even with all these different approaches, the RMON capability in each one acts as a dedicated network management resource. It can be used for everything from long-term data collection and analysis to ad-hoc firefighting 🔥
At the beginning, most (but not all) of RMON's capabilities were based on promiscuous packet capture on a network segment or segments. Over time, the mix grew to include more and more capabilities that didn't depend on promiscuous packet capture. Today, some of the newest documents in the RMON framework allow several ways of gathering data, and promiscuous packet capture is just one of those options 🦋
3. Goals of RMON 🎯
- Offline Operation
Sometimes a management station isn't in constant contact with its remote monitoring devices. This can happen by design, to keep communication costs down (especially over a WAN or dialup link), or by accident, when network failures get in the way of communication between the management station and the probe 📴
So RMON lets a probe be configured to run diagnostics and collect statistics continuously, even when talking to the management station isn't possible or efficient 💪 The probe can then try to notify the management station when something exceptional happens. That means that even when the connection between the management station and the probe isn't continuous, fault, performance, and configuration information can keep piling up and get passed to the management station conveniently and efficiently 🧚
- Proactive Monitoring
Since the monitor has resources to spare, it's really helpful for it to keep running diagnostics and logging network performance all the time 🕵️♀️ The monitor is always there when a failure starts. It can tell the management station about the failure and store historical statistical information about it 📜 The management station can play that history back to dig further into the cause of the problem 🔍
- Problem Detection and Reporting
The monitor can be set up to recognize conditions (especially error conditions) and keep checking for them. When one of those conditions shows up, the event may be logged, and management stations may be notified in a number of ways 🚨
- Value Added Data
A remote monitoring device is a network resource that's dedicated exclusively to network management functions, and it sits right on the part of the network being monitored. So it has a real chance to add a lot of value to the data it collects 💎 For example, by highlighting the hosts on the network that generate the most traffic or errors, the probe can hand the management station exactly the information it needs to solve a class of problems 🎀
- Multiple Managers
An organization may have several management stations, for different units of the organization, for different functions (like engineering and operations), and to provide disaster recovery 🛟 Since environments with multiple management stations are common, the remote network monitoring device has to deal with more than one management station, possibly using its resources at the same time 👑
⭐ the RMON tea keeps coming, so stay tuned for part 2 💖
4. RMON Documents ✨
okay so the RMON Framework is a whole family of documents, bestie 🧚 each one defines some new useful behavior (an application) and also the managed objects that configure, control, and monitor that behavior. this section walks through all of them and tells you what each one does 💅
one of the best ways to tell the RMON MIB modules apart is by checking which layer they work at 🦋 since they take measurements and then present rolled-up aggregates of those measurements, there are 2 criteria to check for every MIB:
- 1. At which layers does the MIB take measurements? For example, the RMON MIB measures data-link layer stuff (packets, bytes, errors), while the APM MIB measures application layer stuff (response time). measuring higher up means digging deeper into the packet, and lots of application layer measurements need stateful flow analysis 👀
- 2. At which layers does the MIB aggregate measurements? this one is about how granular the rollups are. the RMON MIB aggregates to the link, hardware address, or hardware address pair, which are all data-link concepts 🍓 meanwhile the RMON-2 MIB takes those same data-link metrics (packets, bytes, errors) and aggregates them by network address, transport protocol, or application protocol ✨
a MIB can take measurements at one level and aggregate at a different level, and it can also work at multiple levels at once 🌈 Figure 1 and Figure 2 show the measurement layers and aggregation layers for each MIB, so you can see it at a glance:
Measurement Layers
Data Link Network Transport Application
Layer Layer Layer Layer
RMON-1 X
TR-RMON X
RMON-2 X
SMON X
IFTopN X
HCRMON X
APM X
TPM XFigure 1
Aggregation Layers
Data Link Network Transport Application
Layer Layer Layer Layer
RMON-1 X
TR-RMON X
RMON-2 X X X
SMON X
IFTopN X
HCRMON X
APM X X X
TPM X X XFigure 2
4.1. RMON-1
okay the RMON-1 standard [RFC2819] is all about layer 2 🔥 it gives you link-layer statistics aggregated in a bunch of different ways, plus it can fire off alarms when thresholds get crossed, and it can filter and capture packet contents too. the components of RMON-1 are:
- The Ethernet Statistics Group: the statistics the probe measures for each monitored Ethernet interface on the device 📊
- The History Control Group: controls the periodic statistical sampling of data from different kinds of network media ⏱️
- The Ethernet History Group: records periodic statistical samples from an Ethernet network and stores them so you can grab them later 🗂️
- The Alarm Group: periodically samples variables in the probe and compares them against previously configured thresholds. when a monitored variable crosses a threshold, an event gets generated. there's a hysteresis mechanism too, which limits how many alarms get generated 🚨
- The Host Group: holds statistics for each host discovered on the network. hosts get discovered by keeping a list of source and destination MAC Addresses seen in good packets promiscuously received from the network 🕵️♀️
- The HostTopN Group: used to prepare reports describing the hosts that top a list ordered by one of their statistics. the available statistics are samples of one of their base statistics over an interval the management station picks, so they're rate based. the management station also chooses how many hosts get reported 🏆
- The Matrix Group: stores statistics for conversations between pairs of MAC addresses. when the device spots a new conversation, it makes a new entry in its tables 💌
- The Filter Group: lets packets get matched by a filter equation. the matched packets form a data stream that can be captured or can trigger events 🎯
- The Packet Capture Group: lets packets get captured after they flow through a channel 📦
- The Event Group: controls the generation and notification of events from this device 🔔
4.2. Token Ring Extensions to RMON MIB
some of the RMON-1 MIB functions were defined specifically for Ethernet media 🙈 so to make them work on Token Ring, new objects had to be defined in the Token Ring Extensions to RMON MIB [RFC1513]. this MIB also adds objects for monitoring functions that are unique to Token Ring 💜
the components of the Token Ring Extensions to RMON MIB are:
- The Token Ring Statistics Groups: contain current utilization and error statistics, split into two groups: the Token Ring Mac-Layer Statistics Group and the Token Ring Promiscuous Statistics Group. the Mac-Layer one collects info from the Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. the Promiscuous one collects utilization statistics from data packets collected promiscuously 🔁
- The Token Ring History Groups: contain historical utilization and error statistics, also split into the Token Ring Mac-Layer History Group and the Token Ring Promiscuous History Group. they work the same way as the statistics groups, but the data is historical 🕰️
- The Token Ring Ring Station Group: contains statistics and status info for each Token Ring station on the local ring. this group also gives status info for each ring being monitored 💍
- The Token Ring Ring Station Order Group: provides the order of the stations on monitored rings 🔢
- The Token Ring Ring Station Config Group: manages Token Ring stations through active means. any station on a monitored ring can be removed or have configuration info downloaded to it 🛠️
- The Token Ring Source Routing Group: contains utilization statistics derived from source routing information that's optionally present in Token Ring packets 🗺️
4.3. The RMON-2 MIB
the RMON-2 MIB [RFC2021] builds on the RMON-1 architecture, mainly by pushing RMON analysis all the way up to the application layer 🚀 it's giving full-stack visibility, periodt 💅
the components of the RMON-2 MIB are:
- The Protocol Directory Group: every RMON-2 implementation has to be able to parse certain types of packets and identify their protocol type at multiple levels. the protocol directory is an inventory of the protocol types the probe can monitor, and it lets you add, delete, and configure protocol types on that list 📒
- Protocol Distribution Group: controls the collection of packet and octet counts for any or all protocols detected on a given interface. an NMS can use this table to quickly see how bandwidth is being allocated across different protocols 🥧
- Address Mapping Group: lists the MAC address to network address bindings the probe has discovered, plus the interface where each one was last seen 🧭
- Network Layer Host Group: counts the traffic sent from and to each network address the probe has discovered 📬
- Network Layer Matrix Group: counts the traffic sent between each pair of network addresses the probe has discovered 💞
- Application Layer Host Group: counts the traffic, broken down by protocol, sent from and to each network address the probe has discovered 🎀
- Application Layer Matrix: counts the traffic, broken down by protocol, sent between each pair of network addresses the probe has discovered 🧶
- User History: lets an NMS ask for certain variables on the probe to be polled periodically, and stores a time-series of the polled values. this builds a user-configurable set of variables to monitor. (not to be confused with data about users, lol 🙃)
- Probe Configuration: contains configuration objects that set up lots of aspects of the probe, including the software downloaded to the probe, the out-of-band serial connection, and the network connection 🔧
4.4. RMON MIB Protocol Identifiers
so the RMON-2 MIB identifies protocols at any layer of the 7 layer hierarchy using an identifier called a Protocol Identifier, or ProtocolID for short 🦄 ProtocolIDs also identify the specific layering configuration in use, including any arbitrary encapsulations. the RMON MIB Protocol Identifiers document [RFC2896] is a companion to the RMON-2 MIB and defines a bunch of well-known protocols 📚 then there's the RMON MIB Protocol Identifiers Macros [RFC2895], which defines a macro format for describing those well-known protocols and others that might get described in the future ✨
as the RMON Framework has grown, other documents have been added that use ProtocolIDs too 🌸
4.5. Remote Network Monitoring MIB Extensions for Switched Networks (SMON MIB) 🔀✨
4.5. SMON MIB, the switch-monitoring glow-up 💅
Okay so switches are literally everywhere in today's networks, and they act like a broadcast medium 🌐. SMON [RFC2613] brings RMON-like functions to switched networks, which is so needed 🙌.
Switches are different from standard shared media protocols, and it's giving complicated 😩. Here's why:
- Data is not, in general, broadcast. This MAY be caused by the switch architecture or by the connection-oriented nature of the data. So, bestie, monitoring non-broadcast traffic needs to be considered 👀.
- Watching the multiple entry and exit points of a switching device takes a vast amount of resources: memory and CPU, plus aggregating the data into logical packets of information, based on what the application needs 🧠.
- Switching includes logical segmentation, like Virtual LANs (VLANs) 🎀.
- Switching includes packet prioritization 🏃♀️.
- Data moving across the switch fabric can be in the form of cells 🧱. Like RMON, SMON is only concerned with monitoring packets 📦.
All of these differences make monitoring hard 😭. The SMON MIB has these functions to help manage switched networks, and they are iconic 👑:
smonVlanStats
This function provides traffic statistics per Virtual LAN for 802.1q VLANs. 🎀
smonPrioStats
This function provides traffic statistics per priority level for 802.1q VLANS. 🏆
dataSourceCaps
This function identifies all supported data sources on a SMON device 🔎. An NMS MAY use this table to discover the RMON and Copy Port attributes of each data source 🕵️♀️.
portCopyConfig
Lots of network switches can make a copy of traffic seen on one port and send it out to another port for management purposes 🪞. This happens in addition to any copying done during the switch's normal forwarding behavior 💁♀️. The portCopyConfig function provides control of the port copy functionality in a device 🎛️.
4.6. RMON MIB Extensions for Interface Parameters Monitoring (IFTOPN) 📊
Many network switches have hundreds of ports, and lots of them have only one device attached 🔌. A super common thing when managing a switch is sorting the interfaces by some parameter, like finding the most highly utilized interface 🔥. If the switch has many interfaces, downloading the info for all of them to sort on the NMS is expensive and time-consuming 😩. So instead, the ifTopN MIB [RFC3144] lets the sorting happen on the switch, and only the top interfaces get downloaded 🧚✨. Efficient and lowkey genius 💖.
4.7. RMON Extensions for Differentiated Services (DSMON MIB) 🎯
This MIB [RFC3287] extends RMON so you can monitor traffic usage of Differentiated Services [RFC2474] codepoint values 🌈. The 6-bit DiffServ codepoint portion (DSCP) of the Type of Service (TOS) octet in the IP header gives 64 different packet treatments for differentiated network devices to use 🍓. DSMON-capable RMON probes collect and aggregate statistics by inspecting the DSCP value in monitored packets 🔍.
The DSMON MIB defines a DSCP counter aggregation mechanism that cuts down the total number of counters. The agent is configured to internally aggregate counters based on the DSCP value 🧮. This is designed to get around the agent's data collection limitation, do data reduction at both the agent and application levels, and optimize the app for cases where some codepoint values aren't used or lead to similar packet treatment in the monitored network domain 💜.
The components of the DSMON MIB are:
- The Aggregate Control Group 🎛️: This enables configuration of the counter aggregation groups.
- The DSMON Statistics Group 📈: This contains per counter aggregation group distribution statistics for a particular RMON data source.
- The DSMON Protocol Distribution Group 🗂️: This reports per counter aggregation distribution statistics for each application protocol detected on a particular RMON data source.
- The DSMON Host Group 🏠: This contains host address distribution statistics for each counter aggregation group, detected on a particular RMON data source.
- The DSMON Capabilities Group 🧰: This reports the DSMON MIB functional capabilities of the agent implementation.
- The DSMON Matrix Group 🧩: This contains host address pair distribution statistics for each counter aggregation group, detected on a particular RMON data source.
4.8. RMON for High Capacity Networks (HCRMON MIB) 🚀
This MIB [RFC3272] extends RMON for use on high capacity networks 💨. Except for the mediaIndependentTable, each table in this MIB adds high capacity capability to an associated table in the RMON-1 MIB or RMON-2 MIB 🫶.
The mediaIndependentTable gives media independent utilization and error statistics for full-duplex and half-duplex media 🌗. Before the HCRMON MIB existed, a new table had to be made for RMON monitoring of each data-link layer media 😤. Those tables had lots of statistical attributes of the media, including packet and octet counters that don't depend on media type. This wasn't optimal, because there was no way to monitor media types that didn't have a media-specific table defined 🙃. Plus, there were no common objects for monitoring media-independent attributes across media types 💀.
For media other than ethernet and token ring, the mediaIndependentTable is going to be the source for media-independent statistics 🔮. Additional media-specific tables may be created to provide attributes unique to particular media, like error counters 🧁.
4.9. Application Performance Measurement MIB (APM MIB) 🎀📱
The APM MIB [APM] analyzes application performance as experienced by end-users 👀.
Application performance measurement is all about the quality of service that applications deliver to end-users 💅. With this lens, you get a true end-to-end view of the IT infrastructure, combining the performance of the application, desktop, network, and server, plus any positive or negative interactions between those components 🧩.
Honestly, despite all the technically sophisticated ways networking and system resources can be measured, human end-users only notice two things about an application 🫠:
- Availability ✅: The percentage of time the application is ready to give a user service.
- Responsiveness ⚡: The speed at which the application delivers the requested service.
The APM MIB includes these functions:
- The APM Application Directory Group 📚: This contains configuration objects for every application or application verb monitored on this system.
- The APM User Defined Applications Group ✍️: This has objects that let you track applications or application verbs that aren't registered in the protocolDirectoryTable.
- The APM Report Group 📝: This prepares regular reports that aggregate application performance by flow, by client, by server, or by application.
- The APM Transaction Group 🔄: This shows transactions that are currently in progress and ones that ended recently, along with their responsiveness metric.
One important benefit of this table is that it lets a management station check on the status of long-lived transactions 🕰️. The apmReport and apmException mechanisms only act on transactions that have finished, so a network manager may not have visibility for a while into the performance of long-lived transactions, like streaming applications, large data transfers, or (very) poorly performing transactions 😬. Honestly, by definition, the apmReport and apmException mechanisms only show you a problem after nothing can be done about it 💔.
- The APM Exception Group 🚨: This generates immediate notifications for transactions that cross certain thresholds. The apmExceptionTable configures which thresholds get checked for which types of transactions. The apmTransactionResponsivenessAlarm notification is sent when a transaction occurs with a responsiveness that crosses a threshold ⏰.
The apmTransactionUnsuccessfulAlarm notification is sent when a transaction, for which exception checking was configured, fails 🙅♀️.
- The APM Notification Group 🔔: This contains 2 notifications that are sent when thresholds in the APM Exception Table are exceeded.
4.10. RMON MIB Protocol Identifier Reference Extensions 🪪
The protocol identifier defined in RMON-2 [RFC2021] can identify any protocol at any layer and its encapsulation 🌍. The protocol identifier macro document [RFC2896] defines a convenient, human-readable and machine-parseable format for documenting well-known protocols 📖.
Mostly, the protocol identifiers RMON-2 implementations use have described protocols at any layer, including the application layer, but they haven't gone any deeper into the application 🏊♀️. To tell apart an application's behavior while it's doing different tasks (like logging in vs. downloading), it's important to have a separate protocol identifier for each application "verb" 🗝️. The macro defined in [RFC2896] is inconvenient for defining application verbs, because it assumes most protocols are identified by an integer type field, and lots of applications use other means for identifying verbs, including character strings 🙄.
These extensions define another macro for defining application verbs that are children of an application 👶✨. The parent application can be defined with the original protocol identifier macro, and the application verbs are defined with the new macro 🫶💜.
4.11. Transport Performance Metrics MIB (TPM MIB) ✨
okay so the TPM MIB [TPM] is giving drill-down energy 🔍 It keeps an eye on picked performance metrics and stats pulled from watching network packets and sub-application level transactions. It's basically APM's bestie: APM shows you the end-user's view, and TPM zooms in so you can see what's going on under the hood of those apps 💜 The metrics are defined by pointing at existing IETF, ITU and other standards organizations' docs, so nothing is made up from scratch. And it covers both passive and active traffic generation sources, so it watches the natural stuff and the stuff you generate on purpose 🦋
The TPM MIB includes the following functions:
- The tpmCapabilities Group
The tpmCapabilitiesGroup holds the objects and tables that show what the agent can do when it comes to measurement protocols and metrics 🎀
- The tpmAggregateReports Group
The tpmAggregateReportsGroup collects the aggregated statistical measurements for the report intervals you configure 📊
- The tpmCurrentReports Group
The tpmCurrentReportsGroup gathers the measurements that are still uncompleted for the current configured report, for transactions that get caught in progress 👀 Once a transaction finishes, its history gets saved too, so nothing gets lost 🌸
- The tpmExceptionReports Group
The tpmExceptionReportsGroup links up immediate notifications for transactions that go over certain thresholds from the apmExceptionGroup [APM] 🚨 It reports the aggregated sub-application measurements for any applications that are exceeding those thresholds, so you know exactly who's being dramatic 💀
4.12. Synthetic Sources for Performance Monitoring MIB (SSPM MIB)
The Synthetic Sources for Performance Monitoring MIB [SSPM] is all about artificially generating a) application-level, b) transport-level, and c) link-level traffic so you can keep an eye on system performance 🧚 Sometimes you want to control that synthetic traffic yourself while you're evaluating performance, and sometimes you don't need to! If you're happy with the naturally generated application-level traffic, you can just monitor what's already there and skip instrumenting anything fake 🙈 The SSPM MIB is the one that lets you configure and control the generation of that synthetic traffic when you do want it 💅
4.13. RMON MIB Extensions for High Capacity Alarms
okay this one is so needed 😭 Counter64 objects deserve the same alarm thresholding that Counter32 objects already get, and RMON-1 just wasn't built for that. The RMON-1 alarmTable objects and RMON-1 notification types are specific to 32-bit objects, so they can't properly monitor Counter64-based objects. So the extensions explicitly support Counter64-based objects, and they're completely independent of the existing RMON-1 alarm mechanisms 🌈
This MIB [RFC3434] contains the following functions:
- The hcAlarmControlObjects group
Controls how alarms get configured for high capacity MIB object instances 🎛️
- The hcAlarmCapabilities group
Describes the high capacity alarm capabilities that the agent provides ⭐
- The hcAlarmNotifications group
Brings in new rising and falling threshold notifications for high capacity objects 🔔
4.14. Real-Time Application Quality of Service Monitoring (RAQMON) MIB
so RMON is ready to level up and monitor end devices too, like IP phones, pagers, Instant Message Clients, mobile phones, and PDA devices 📱 This memo proposes extending the RMON Framework so that Real-time Application QoS information from these devices can be retrieved with SNMP. It doesn't matter what technology is used to do the measurements, which is a whole vibe ✨ The end-to-end user experience of QoS and performance for an application is a mix of device performance, transport network performance and the specific application context. Everything matters, bestie 💖
RAQMON [RAQMON-FRAMEWORK] is the common framework that identifies a set of application QoS parameters, plus a reporting mechanism. It uses a common protocol data unit (PDU) format between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC) to report QoS statistics, with RTCP and SNMP as the underlying transport protocols 🦋
See the RAQMON MIB [RAQMON-MIB] for more info about its components 💜
5. RMON Framework Components
the RMON Framework docs are all connected because they share a common purpose and similar collection methodologies, AND because they use common infrastructure components 🫶 Those shared components are:
- MediaIndependent Table
- Protocol Directory
- appDirectory
- DataSource
- Capabilities
- Control Tables
5.1. MediaIndependent Table
there are tons of data-link media types, and each one has its own unique features. But a lot of statistics are the same across most media, like counts of packets and octets 🍓 The media independent table holds those most common stats, and it acts as a super class that specific interface types inherit from. Which means the common stats can be monitored even for media types the agent doesn't recognize 🧚
For example, if the mediaindependentTable had existed before the etherStatsTable was defined, the etherStatsTable could have left out the etherStatsDropEvents, etherStatsOctets, etherStatsPkts objects. Iconic inheritance energy 👑
The Media Independent Table is defined in the High Capacity RMON MIB [RFC3434] 🌸
5.2. Protocol Directory
the second infrastructure component is the Protocol Directory Group, which is defined in the RMON-2 MIB [RFC2021] 💅 RMON-2's main goal was to extend the remote network monitoring agent's capabilities beyond the link layer, so it could monitor higher level protocols too. To do that, it needed a way to globally identify individual protocol encapsulations. That's what the Protocol Directory Group does, specifically the protocolDirID found in the protocolDirTable in the RMON-2 MIB 🔥
The Protocol Directory gives the agent an inventory of the protocols it can decode, count, categorize and time ✨ Its directory and objects are designed so you can add, delete and configure protocol encapsulations in the directory list. Protocol Directory entries are mainly identified by an object called the protocolDirID 🎀 The protocolDirID is a hierarchically formatted OCTET STRING that globally identifies individual protocol encapsulations. A protocol descriptor macro was defined in RFC 2895 [RFC2895] to describe the different protocol layers supported in the protocolDirID hierarchy 🧠 Basically, the protocolDirID is a tree built up from successive protocol encapsulations. Each layer is identified by a 4-octet identifier, which names the child protocol within the context of the parent protocol identified by the identifiers before it 🌳
Each protocol layer in the protocolDirID also has a 1-octet parameter field 🎛️ Each parameter points out options that are specific to that protocol, like whether the agent can count fragmented packets correctly, or track sessions for port mapped protocols (e.g., TFTP). These 1-octet parameter fields get concatenated, in order, in the protocolDirParameters object 💜
The protocolDirTable index is made up of the protocolDirID, the protocolDirParameters and their associated length fields. The index format looks like this:
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+Figure 3: the protocolDirTable INDEX format.
Here's an example protocolDirTable INDEX for SNMP over UDP over IP over Ethernet 🍭
16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
| | | | | | | |
+--+-------+-------+--------+---------+-+-------+
c ether2 ip udp snmp c param.c = 1-subidentifier count field
Figure 4: A protocolDirTable INDEX example for SNMP over UDP over IP over Ethernet.
the set of protocol layers that's defined right now is in RFC 2896 [RFC2896] 📚 RFC 2895 [RFC2895] explains the process for submitting new protocols to add to that set. Periodic updates to RFC 2896 are going to be published to bring in the new protocol definitions that have been submitted 🌈 Fun fact: RFC 2896 is the second version of the defined protocol macros, and it obsoletes RFC 2074 [RFC2074] 🙌 RFC 2895 also covers how to handle protocols that don't fit into this well-defined tree built from encapsulation protocol identifiers. RTP is an example of one of those, since it gets mapped to specific UDP ports through a separate signaling mechanism 🦋 Those get handled by the ianaAssigned protocols, as described in RFC 2895 🫶
The protocolDirTable is defined and used in the RMON-2 MIB [RFC2021], and other RMON WG MIBs are using it too, as well as other IETF defined MIBs 🌟 Examples include the APM MIB [APM], the TPM MIB [TPM] and the SSPM MIB [SSPM] 💖
As mentioned in previous sections, the protocolDirID is getting extended in two ways 🎉 First, there's work underway on a new set of protocol descriptor macros that extend the protocol encapsulation model to identify application layer verbs [RFC3395]. This extension was motivated by the work on the APM MIB and the TPM MIB 👀 Second, the APM MIB defines the apmAppDirectoryTable, which provides a directory of applications the agent can process. That gets discussed further in the following section 🧚 Put together, these extensions allow:
- The APM MIB to define and monitor the end-user's view of application performance 👑
- The TPM MIB to clearly specify the sub-transactions that make up the application it monitors, through the tpmTransMetricDirTable 🔍
- The SSPM MIB to generate synthetic application transactions by importing the appLocalIndex from the APM MIB 🍓
5.3. Application Directory and appLocalIndex ✨
okay so APM, TPM and related apps collect certain stats for each application or application verb they decode 📊🫶 Some apps and verbs are defined in the protocol directory, so they get their own protocolID and a matching protocolDirLocalIndex 💅 Other verbs are defined more dynamically by entries in the apmHttpFilterTable or apmUserDefinedAppTable 🌈 These dynamic ones do not get protocolDirID's assigned, so no protocolDirID for them 🙈
The APM MIB [APM] defines an important index called the appLocalIndex 🔑 For all app monitoring in the APM and TPM MIBs, apps are identified by integer values of the appLocalIndex. There's no single registry of apps (like there is for protocols) bc there are a few different mechanisms for registering one 😭 For each value of appLocalIndex, a corresponding entry will exist in one of several tables:
- The protocolDirTable - Some values of appLocalIndex correspond to protocolDirLocalIndex values assigned in the protocolDirTable. Each of these corresponds to a protocol defined by a protocolID.
- The apmHttpFilterTable - Some values of appLocalIndex correspond to apmHttpFilterAppLocalindex values assigned in the apmHttpFilterTable. Each of these corresponds to an application verb defined as a set of HTTP transactions that match a set of filters.
- The apmUserDefinedAppTable - Some values of appLocalIndex correspond to index values of the apmUserDefinedAppTable. Each of them corresponds to an application or application verb defined in a user-defined way.
Each value of appLocalIndex will only be registered in one of these tables. In effect, the appLocalIndex number space is the union of these number spaces, where these tables must work together to avoid assigning overlapping (duplicate) appLocalIndexes 🫣🧚
Each unique appLocalIndex value is also registered in the apmAppDirectoryTable, where a number of attributes of the application may be configured 💖
5.4. Data Source 🗂️
Most RMON functions use a DataSource as a pointer to the entity the data gets collected from 🎯 The DataSource is an object identifier that identifies one of three types of data sources:
ifIndex.<I>: Traditional RMON dataSources. Called 'port-based' forifType.<I>not equal to 'propVirtual(53)'.<I>is the ifIndex value.smonVlanDataSource.<V>: A dataSource of this form refers to a 'Packet-based VLAN' and is called a 'VLAN-based' dataSource.<V>is the VLAN ID as defined by the IEEE 802.1Q standard. The value is between 1 and 4094 inclusive, and it represents an 802.1Q VLAN-ID with a global scope within a given bridged domain, as defined by 802.1Q 🌸entPhysicalEntry.<N>: A dataSource of this form refers to a physical entity within the agent and is called an 'entity-based' dataSource.<N>is the value of the entPhysicalIndex in the entPhysicalTable 🍓
5.5. Capabilities 🎀
Probe Capabilities objects were introduced in the RMON MIB modules to help applications figure out the capabilities of the different probes in the domain 🔍 These objects use a BITS syntax (with the exception of some of the objects in the TPM and SSPM MIBs), and they list in an explicit manner the MIB groups supported by the probe, plus the functional capabilities of the specific RMON agents 📋 By reading these values, applications can know which RMON functions are usable without a trial-and-error process that could waste time and bandwidth in the operational flow ⏱️ These objects have the MAX-ACCESS of read-only, which defines their use as an indication of what is supported by a probe, and not a means to configure the probe for operational modes. An RMON agent SHOULD initiate the capabilities objects at agent initialization and SHOULD NOT modify the objects during operation 🙅♀️
Here's where each one lives:
- The probeCapabilities object in the RMON-2 MIB describes the capabilities of probes that support RMON, Token-Ring RMON and RMON-2.
- The smonCapabilities object in the SMON MIB describes the SMON-specific capabilities of probes that support the SMON MIB.
- The dataSourceCapsTable in the SMON MIB defines the capabilities of the SMON data sources on probes that support the RMON MIB.
- The interfaceTopNCaps object in the Interface TopN MIB defines the sorting capabilities supported by an agent that supports the Interface TopN MIB.
- The dsmonCapabilities object in the DSMON MIB provides an indication of the DSMON groups supported by an agent that supports the DSMON MIB.
- The tpmCapabilitiesGroup contains objects and tables, which show the measurement protocol and metric capabilities of an agent that supports the TPM MIB.
- The sspmCapabilitiesTable indicates whether a device supporting the SSPM MIB supports SSPM configuration of the corresponding AppLocalIndex.
- The hcAlarmCapabilities object provides an indication of the high capacity alarm capabilities supported by an agent that supports the HC-Alarm MIB 🚨
5.6. Control Tables 🗃️
The RMON MIB modules have a lot of complex functions, so they often need user configuration 🛠️ In many cases, the function needs parameters set up for a data collection operation, and the operation can only proceed once those parameters are fully set up 💫
Lots of functional groups in the RMON MIBs have one or more tables for setting up control parameters, plus one or more data tables where the results land 📥 The control tables are typically read-write, while the data tables are typically read-only. The parameters in the control table often describe the resulting data in the data table, so many of them can only be modified when the control entry is invalid 🙃 So the way to change them is to invalidate the control entry, which causes its deletion and the deletion of any associated data entries, and then create a new control entry with the proper parameters. Deleting the control entry is also a handy way to reclaim the resources the associated data used 🧹
To make control by multiple managers work, resources have to be shared among the managers. These resources are typically the memory and computation resources that a function requires 🧠
Two facilities ease cooperation between multiple managers as they create and use control tables 🤝 The first is the use of EntryStatus or RowStatus objects, which guarantee that two managers can avoid creating the same control entry. The second is the use of OwnerString objects in control tables, which provides these benefits:
- Provides information to facilitate sharing of already existing control entries instead of creating a new but identical entry.
- Provides information to allow the ultimate human owners of control entries to identify each other so they can cooperate in cases of conflict over resources.
- Provides information to allow software to identify control entries that it owns but has forgotten about (e.g., due to a crash or other error) so that it can re-use or free them.
- Provides information to allow an administrator to make an informed decision to override someone else's control entry when circumstances make it necessary.
- Provides information to identify control entries that are set up automatically when the device starts up.
See the RMON MIB [RFC2819] for further information on the use of control tables, EntryStatus/RowStatus, and OwnerStrings 📚💜
6. Relationship of the SSPM MIB with the APM and TPM MIBs ✨
Okay so bestie, APM and TPM can totally monitor the real traffic that actual end-users generate on the network 🌐, but they can also keep an eye on synthetically generated traffic 🧪. The SSPM MIB is the one that makes the fake traffic 🎀, but it doesn't do any monitoring itself. Monitoring the generated traffic is handed off to APM and TPM. Main character division of labour, honestly 💅.
Figure 5 is the big-picture diagram of the SSPM MIB architecture, with APM and TPM sitting in their roles 🦋. The RMON documents cover the "Control-Level" in this diagram and a bit of the "Synchronization Control-Level" 🫶. The underlying "Instrumentation-Level" is implementation dependent, so it's not in the RMON specs at all. Not our problem, babe 💀.
+----------------+
+----------| Application |----------+
| +----------------+ |
| | |
+--------------------------------+ |
| Synchronization Control | |
+--------------------------------+ |
| | |
V V V
+------------------+ +------------------+ +--------------+
|Traffic Generation| |Monitoring Metrics| |Data Reduction|
| Control | | Control | | Control |
+------------------+ +------------------+ +--------------+
| ^ | ^ | ^
| | | | | |
V | V | V |
+------------------+ +------------------+ +---------------+
|Traffic Generation| |Monitoring Metrics| |Data Reduction |
| Instrumentation| | Instrumentation| +-->|Instrumentation|
+------------------+ +------------------+ | +---------------+
| |
| |
Various levels | |
and span +-----------|
|
|
V
Reports
Figure 5: An SSPM Performance Monitoring SystemWait, I need to be honest here. That diagram got mangled while I was retyping it, so please use the copy below, which matches the original character for character 🙈:
+----------------+
+-------------| Application |-------------+
| +----------------+ |
| | |
+--------------------------------+ |
| Synchronization Control | |
+--------------------------------+ |
| | |
V V V
+------------------+ +------------------+ +--------------+
|Traffic Generation| |Monitoring Metrics| |Data Reduction|
| Control | | Control | | Control |
+------------------+ +------------------+ +--------------+
| ^ | ^ | ^
| | | | | |
V | V | V |
+------------------+ +------------------+ +---------------+
|Traffic Generation| |Monitoring Metrics| |Data Reduction |
| Instrumentation| | Instrumentation| +-->|Instrumentation|
+------------------+ +------------------+ | +---------------+
| |
| |
Various levels | |
and span +-----------|
|
|
V
Reports
Figure 5: An SSPM Performance Monitoring SystemIt's the job of the network management application to coordinate all the individual pieces of this performance management system 🧚.
Within the APM, TPM, and SSPM set of RMON MIB modules:
- APM MIB [APM] is responsible for the parts of "Monitoring Metrics Control" that are directly tied to the end-user's perceived application-level performance 👑. It also handles parts of "Data Reduction Control" and "Reports". And when the TPM MIB relies on the APM MIB's control tables for its own control, APM is providing some of the "Synchronization Control" for the reports from those two MIBs 🌈.
- TPM MIB [TPM] is responsible for parts of "Monitoring Metrics Control" 💜. It also handles parts of "Data Reduction Control" and "Reports" for sub-application-level transactions 🍓. Synchronization control with the APM MIB happens by choosing to rely on the APM MIB control tables inside the TPM MIB ✨.
- SSPM MIB [SSPM] is responsible for "Traffic Generation Control" when synthetic traffic is the thing being monitored 🔥. The other, and much more common, option is monitoring natural, user-generated traffic 🌸.
"Monitor Metrics Control" is basically hard-coded in the APM MIB 💅. Inside the TPM MIB, a metrics table is used to identify which metrics get monitored in a particular implementation 🦋. "Data Reduction Control" is also basically hard-coded into the MIB structure of both the APM MIB and the TPM MIB 🫶. These MIBs strictly specify which statistics get reported in a set of report tables 📊.
Both the TPM MIB and the SSPM MIB rely on the APM MIB's appLocalIndex to specify the application being monitored or generated 🎀. The APM MIB gives the end-user view of application performance, like the Whois transaction time 💖. The TPM MIB, through its tpmTransMetricDirTable, identifies a set of sub-application-level transactions and their metrics that are associated with the application 🧚. For example, a TPM MIB implementation could report the DNS lookup time, the TCP connect time (to the Whois Server), and the Whois Req/Resp download time 🌈. The SSPM MIB could be configured to generate these Whois transactions synthetically 🍓.
The testing model goes like this: first, configure the traffic generation instrumentation through the SSPM MIB control function ✨. This defines aspects of the synthetic traffic, such as application type, targets, etc. 🦋. Once traffic generation is configured, the network management application can set up the monitoring instrumentation through the APM MIB and TPM MIB 💜. These control the reporting periods, the type of data aggregation, and so on 👑. Once the tests are complete, the network management application retrieves the reports from the monitoring metrics control MIBs, like the APM MIB and TPM MIB 🔥.
7. Acknowledgements 🫶
This memo is a product of the RMON MIB working group 🌸. The authors also gratefully acknowledge the contributions of Lester D'Souza of NetScout Systems, Inc. 💖
8. References 📚
8.1. Normative References
[RFC2819] Waldbusser, S., "Remote Network Monitoring
Management Information Base", STD 59, RFC 2819,
May 2000.8.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
Eds., "Structure of Management Information Version
2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
J., Eds., "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
J., Eds., "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC1513] Waldbusser, S., "Token Ring Extensions to the
Remote Network Monitoring MIB", RFC 1513,
September 1993.
[RFC2021] Waldbusser, S., "Remote Network Monitoring
Management Information Base Version 2 using
SMIv2", RFC 2021, January 1997.
[RFC2895] Bierman, A., Bucci, C. and R. Iddon, "Remote
Network Monitoring Management Information Base
Protocol Identification Reference", RFC 2895,
August 2000.
[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote
Network Monitoring MIB Protocol Identifier
Macros", RFC 2896, August 2000.
[RFC2613] Waterman, R., Lahaye, B., Romascanu, D. and S.
Waldbusser, "Remote Network Monitoring MIB
Extensions for Switched Networks Version 1.0", RFC
2613, June 1999.
[RFC3144] Waldbusser, S., "Remote Monitoring MIB Extensions
for Interface Parameters Monitoring", RFC 3144,
August 2001.
[RFC3287] Bierman, A., "Remote Monitoring MIB Extensions for
Differentiated Services", RFC 3287, July 2002.
[RFC3273] Waldbusser, S., "Remote Network Monitoring
Management Information Base for High Capacity
Networks", RFC 3273, July 2002.
[APM] Waldbusser, S., "Application performance
measurement MIB", Work in Progress.
[RFC3395] Bierman, A., Bucci, C., Dietz, R. and A. Warth,
"Remote Network Monitoring MIB Protocol Identifier
Reference Extensions", RFC 3395, September 2002.
[TPM] Dietz, R. and R.G.Cole, "Application Performance
Measurement Framework Transport Performance
Metrics MIB", Work in Progress.
[SSPM] Kalbfleisch, K., Cole, R.G. and D. Romascanu,
"Definition of Managed Objects for Synthetic
Sources for Performance Monitoring Algorithms",
Work in Progress.
[RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring
MIB Extensions for High Capacity Alarms", RFC
3434, December 2002.
[RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB Using SMIv2", RFC 2233, November 1997.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[OWDP] Shalunov, S., Teitelbaum, B. and M. Zekauskas, "A
One-way Active Measurement Protocol", Work in
Progress.
[RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky,
"Real-time Application Quality of Service
Monitoring (RAQMON) Framework", Work in Progress.
[RAQMON-MIB] Siddiqui, A., Romascanu, D., Golovinsky, E. and R.
Smith, "Real-Time Application Quality of Service
Monitoring (RAQMON) MIB", Work in Progress.9. Security Considerations 🔐
This document is a description of existing documents and as such it does not have any security impact 💀. If you want to understand the security-related issues of the different RMON documents, go read the Security Considerations sections of the respective documents 🙈. Seriously, those are where the real drama lives.
10. Authors' Addresses 🏡
Steve Waldbusser 💌
Phone: +1 650-948-6500 Fax: +1 650-745-0671 EMail: waldbusser@nextbeacon.com
Carl W. Kalbfleisch 💌 NTT/VERIO 8700 Stemmons Freeway, Suite 211 Dallas, TX 75247 United States
Phone: +1 972-906-2034 EMail: cwk@verio.net
Robert G. Cole 💌 AT&T Labs Network Design and Performance Analysis Department 330 Saint John Street, 2nd Floor Havre de Grace, MD 21078 United States
Phone: +1 410-939-8732 Fax: +1 410-939-8732 EMail: rgcole@att.com
Dan Romascanu 💌 Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel
Phone: +972-3-645-8414 EMail: dromasca@avaya.com
11. Full Copyright Statement ✨
Okay bestie, the legal stuff 💅 Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈
This document and translations of it can be copied and handed out to anyone, and people can write derivative works that comment on it, explain it, or help people implement it. They can be prepared, copied, published, and distributed, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph stay on every copy and derivative work. 🦋
The one catch: this document itself may not be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it to develop Internet standards, where the copyright procedures in the Internet Standards process must be followed, or when you're translating it into a language other than English. 🎀
These permissions are perpetual, so the Internet Society and its successors or assignees can never take them back. 💖
Now the disclaimer, which is important 😭 This document and the information in it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🌸 Thank you to the Internet Society for keeping the lights on for the RFC Editor. We literally couldn't have these documents without that support 🧚
📦 where this page comes from
- ietf: rfc3577 2003-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms