RFC 3202
Definitions of Managed Objects for Frame Relay Service Level Definitions
RFC 3202: Definitions of Managed Objects for Frame Relay Service Level Definitions 🎀
Okay bestie, so this one is RFC 3202 🦋. It's a Standards Track doc from January 2002, written by R. Steinberger (Paradyne Networks) and O. Nicklass (RAD Data Communications Ltd.). Its title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Status of This Memo 📜
This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💌. For where this protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1) 🧐. Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract ✨
This memo extends the Management Information Base (MIB) that network management protocols use in TCP/IP-based internets 🌸. Specifically, it adds objects for managing the Frame Relay Service Level Definitions 💜.
Table of Contents 📚
1. The SNMP Management Framework ............................... 2
2. Conventions ................................................. 3
3. Overview .................................................... 3
3.1. Frame Relay Service Level Definitions ..................... 4
3.2. Terminology ............................................... 5
3.3. Network Model ............................................. 5
3.4. Reference Points .......................................... 6
3.5. Measurement Methodology ................................... 8
3.6. Theory of Operation ....................................... 9
3.6.1. Capabilities Discovery .................................. 9
3.6.2. Determining Reference Points for Row Creation ........... 10
3.6.2.1. Graphical Examples of Reference Points ................ 11
3.6.2.1.1. Edge-to-Edge Interface Reference Point Example ...... 12
3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example ... 13
3.6.2.1.3. End-to-End Using Reference Point Example ............ 14
3.6.3. Creation Process ........................................ 15
3.6.4. Destruction Process ..................................... 15
3.6.4.1. Manual Row Destruction ................................ 15
3.6.4.2. Automatic Row Destruction ............................. 16
3.6.5. Modification Process .................................... 16
3.6.6. Collection Process ...................................... 16
3.6.6.1. Remote Polling ........................................ 16
3.6.6.2. Sampling .............................................. 17
3.6.6.3. User History .......................................... 17
3.6.7. Use of MIB Module in Calculation of Service Level
Definitions .................................................... 17
3.6.8. Delay ................................................... 20
3.6.9. Frame Delivery Ratio .................................... 20
3.6.10. Data Delivery Ratio .................................... 21
3.6.11. Service Availability ................................... 21
4. Relation to Other MIB Modules ............................... 22
5. Structure of the MIB Module ................................. 23
5.1. frsldPvcCtrlTable ......................................... 23
5.2. frsldSmplCtrlTable ........................................ 23
5.3. frsldPvcDataTable ......................................... 23
5.4. frsldPvcSampleTable ....................................... 24
5.5. frsldCapabilities ......................................... 24
6. Persistence of Data ......................................... 24
7. Object Definitions .......................................... 24
8. Acknowledgments ............................................. 61
9. References .................................................. 61
10. Security Considerations .................................... 63
11. Authors' Addresses ......................................... 63
12. Full Copyright Statement ................................... 641. The SNMP Management Framework 🧚
The SNMP Management Framework currently has five major pieces 💅:
- An overall architecture, described in RFC 2571 [1].
- Mechanisms for describing and naming objects and events for management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
- A set of fundamental applications described in RFC 2573 [14], plus the view-based access control mechanism described in RFC 2575 [15].
If you want a friendlier intro to the current SNMP Management Framework, check out RFC 2570 [16] 🫶.
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🗂️. Objects in the MIB are defined using the mechanisms in the SMI 🔍.
This memo specifies a MIB module that is compliant with SMIv2 ✅. A MIB conforming to SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be turned into textual descriptions in SMIv1 during translation. However, losing that machine readable information is not considered to change the semantics of the MIB 🙈.
2. Conventions 💖
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [22] 🎀. These are the official BCP 14 key words, so read them carefully bestie 👑.
3. Overview 🦋
This section gives an overview and some background on how to use this MIB module 🌷.
This MIB module covers the items needed to manage the Frame Relay Forum's Implementation Agreement for Service Level Definitions (FRF.13 [17]). Right now, it applies to these values of the ifType variable in the Internet-standard MIB:
frameRelay (32)frameRelayService (44)
3.1. Frame Relay Service Level Definitions 📈
The frame relay service level definitions cover specific characteristics of a frame relay service that can help with these tasks 💅:
- Evaluating frame relay service providers, offerings or products.
- Measuring Quality of Service.
- Enforcing Service Level Agreements.
- Planning or describing a frame relay network.
FRF.13 [17] defines the following parameters as a sufficient set of values to get those tasks done ✨.
- Delay: The amount of time, in microseconds, from when a frame exits the source to when it reaches the destination. NOTE: FRF.13 [17] defines this value in terms of milliseconds 🙃.
- Frame Delivery Ratio: The ratio of the number of frames delivered to the destination versus the number of frames sent by the source. This ratio can be further divided by inspecting either only the frames within the CIR or only the frames in excess of the CIR 📦.
- Data Delivery Ratio: The ratio of the amount of data delivered to the destination versus the amount of data sent by the source. This ratio can be further divided by inspecting either only the data within the CIR or only the data in excess of the CIR 💧.
- Service Availability: The amount of time the frame relay service was not available. FRF.13 [17] defines three types of availability statistics: Mean Time to Repair, Virtual Connection Availability, and Mean Time Between Service Outages. The last two require information about scheduled outage time. It is assumed that the network management software will maintain scheduled outage time information, so it is not included in the MIB module 🛠️.
Check FRF.13 [17] for more details 🔗.
3.2. Terminology 📖
- CIR: The Committed Information Rate (CIR) is the subscriber data rate, expressed in bits/second, that the network commits to deliver under normal network conditions [18].
- DLCI: Data Link Connection Identifier [18].
- Logical Port: This term models the Frame Relay "interface" on a device [18].
- NNI: Network to Network Interface [18].
- Permanent Virtual Connection (PVC): A virtual connection whose end-points and bearer capabilities are defined at subscription time [18].
- Reference Point (RP): The point of reference within the network model where calculations or data collection take place.
- UNI: User to Network Interface [18].
3.3. Network Model 🗺️
The basic model, shown in Figure 1 below, has two frame relay DTE endpoints connected to a network cloud through a frame relay UNI interface 🌥️. The network cloud can contain zero or more internal frame relay NNI connections that link multiple networks together. Calculations and data collection can happen at any reference point within the network 🧠.
+-------------+ +-------------+
| Frame Relay | | Frame Relay |
| DTE Device | | DTE Device |
+------+------+ +------+------+
| |
UNI UNI
Connection Connection
| |
+------+------+ NNI +-------------+ NNI +------+------+
| Network A +------------+ Network B +------------+ Network C |
+-------------+ Connection +-------------+ Connection +-------------+
Figure 1
Frame Relay Network Reference Model3.4. Reference Points ✨
okay so the collection and calculations for the service level stuff happen at two reference points in the network 🫶 these are the exact spots where frames get logged for the service level info. the reference points the MIB module uses are in figure 2 below 🦋 and ngl, the module also lets you have proprietary reference points, which MAY exist anywhere in the network that isn't already a defined reference point 💅 what those mean is insignificant unless the device manufacturer defines them, so that's their call 🙈
+---------------------------+
|+-----------+ +-----------+|
|| | |Measurement||
||Frame Relay---Engine --(Source RP)----+
||DTE | |(If Exists)|| |
|+-----------+ +-----------+| |
+---------------------------+ |
Frame Relay Source |
+------------------------------------------+
| Frame Relay Network
| +----------------------------------+
| | +------------------------------+ |
| | | +---------+ +---------+ | |
| | | | | | Traffic | | |
+--(Ingress RP)--- L1 / L2 --- Policing| | |
| | | Control | | Engine | | |
| | +---------+ +----|----+ | |
| | | | |
| | (Traffic Policing RP)| |
| +------------------|-----------+ |
| Ingress Node | |
| | |
| +-----------|-----------+ |
| | Intermediate Nodes | |
| +-----------|-----------+ |
| | |
| Egress Node | |
| +--------------|-----------+ |
| | (Egress Queue Input RP) | |
| | | | |
| | +-------+------+ | |
| | | Egress Queue | | |
| | +-------+------+ | |
| | | | |
| | (Egress Queue Output RP) | |
| +--------------|-----------+ |
+--------------------|-------------+
Frame Relay Destination |
+---------------------------+ +-----------+
|+-----------+ +-----------+| |
|| | |Measurement|| |
||Frame Relay---Engine --(Destination RP)--+
||DTE | |(If Exists)||
|+-----------+ +-----------+|
+---------------------------+
Figure 2
Reference Points (FRF.13 [17])the MIB variables frsldPvcCtrlTransmitRP and frsldPvcCtrlReceiveRP let you view and configure the reference points where the calculations happen 🎀 these are specific to whatever device they're on. frame relay devices are both frame sources and frame destinations 🔥 the definitions in this MIB module cover how a pair of devices on the network path interact. the same device can totally use different reference points for calculating and collecting stats, depending on whether the referenced frame is sent or received by that device 🌈 when the device is a frame source, the value of frsldPvcCtrlTransmitRP shows the reference point used for all source calculations for the specified PVC. when it's a frame destination, frsldPvcCtrlReceiveRP shows the reference point used for all destination calculations for that PVC.
for example, FRF.13 [17] defines an Edge-to-Edge Egress Queue measurement domain as a domain where measurement happens between an Ingress Reference Point and an Egress Queue Input Reference Point 🧚 for this domain between a source device and a destination device, frsldPvcCtrlTransmitRP on the source device would be set to ingTxLocalRP(2), and frsldPvcCtrlReceiveRP on the destination device would be set to eqiRxLocalRP(4). it's usually the case that the reference points would be equivalent on the remote device when monitoring frames going the opposite direction, but there is no requirement for them to be so 🤷♀️
it can be seen from the example above that a total of four reference points are required to collect info for both directions of traffic flow 💜 the reference points represent the transmit and receive directions at both ends of a PVC. if a device has knowledge of the info from the remote device, it's possible to collect the stats from a single device. this is not always the case though 😭 in most instances, two devices will need to be monitored to capture a complete description of the service level on a PVC. the reference points a single device can monitor are contained in the frsldRPCaps object.
3.5. Measurement Methodology 🍓
this document neither recommends nor suggests a method of implementation. that's left to the device manufacturer, and it should be independent of the data that's actually collected 💅
periodic collection of this data can be done by polling the data table, using the sample tables, or using the user history group of RFC 2021 [19] 📊
3.6. Theory of Operation 🌸
the following sections explain how to use this MIB module ✨ they cover row handling, data collection, and data calculation. the recommendations in here are suggestions for implementation, and they don't imply that they're the only method that can be used for those operations 🫶
3.6.1. Capabilities Discovery 🔍
three objects are provided specifically to help the network manager figure out what the device can do with this MIB module 👑
frsldPvcCtrlWriteCaps: This object reports the write capabilities of the PVC Control Table. use it to see which objects can be modified. it only needs to be referenced if row creation or modification is going to happen.frsldSmplCtrlWriteCaps: This object reports the write capabilities of the Sample Control Table. use it to see which objects can be modified. the group only needs to be referenced if the sample tables are going to be used to collect historical info.frsldRPCaps: This object reports the reference points where the device is capable of collecting info. this object needs to be referenced if row creation is going to happen in the PVC Control Table. devices can only create rows containing supported reference points.
these objects don't mean there's no need for an Agent Capabilities macro for devices that don't fully support every object in this MIB module 🙈 they're there to help with the ensured network management operations of this MIB module when it comes to row creation and modification.
there are also four more objects that report and control the memory utilization of this MIB module 🧠 they are frsldMaxPvcCtrls, frsldNumPvcCtrls, frsldMaxSmplCtrls are frsldNumSmplCtrls. together they let a manager control how much memory gets allocated for this MIB module's specific utilization, by setting the maximum allowed allocation of controls 💖
3.6.2. Determining Reference Points for Row Creation 🦋
the performance of a PVC is monitored by evaluating the unidirectional flow of frames from an ingress point to an egress point ✨ reference points describe where each of the two measurements gets made. monitoring both of the unidirectional flows that make up the PVC's frame traffic takes a total of four reference points, as shown in Figures 3 through 5 🎀 a monitoring point that evaluates traffic is restricted to counting frames that pass the reference points hosted locally on that monitoring point. so if the monitoring point is near the ingress point of the flow, it counts the frames entering the frame relay network. the complete picture of frame loss for the unidirectional flow needs info from the downstream reference point, which lives at another (remote) monitoring point 😭
the local monitoring point MAY be implemented so the info from the downstream monitoring point gets moved to it using implementation-specific mechanisms 🧚 in that case, all the info needed to calculate frame loss becomes available from the local measurement point. the local measurement point agent can report all the objects in the FrsldPvcDataEntry row, meaning the counts for offered frames entering the network and delivered frames exiting the network 🔥
alternatively, the local monitoring point MAY be restricted to counts of frames observed on the local device only 🙈 in this case, the objects of the FrsldPvcDataEntry row that report what happened on the remote device aren't available.
here's the list of possible valid reference points for an FRF.13 SLA, from the source reference point to the destination reference point, in both directions 🌈
- Local Information Only
Local Device: srcLocalRP, desLocalRP
Remote Device: srcLocalRP, desLocalRP- Remote Information Only
Local Device: srcRemoteRP, desRemoteRP
Remote Device: srcRemoteRP, desRemoteRP- Mixed Two Device Model 1 (Local Device Always Transmitter)
Local Device: srcLocalRP, desRemoteRP
Remote Device: srcLocalRP, desRemoteRP- Mixed Two Device Model 2 (Local Device Always Receiver)
Local Device: srcRemoteRP, desLocalRP
Remote Device: srcRemoteRP, desLocalRP- Mixed One Device Model 1 (Directional Rows)
First Row: srcRemoteRP, desLocalRP (Receiver Row)
Second Row: srcLocalRP, desRemoteRP (Sender Row)- Mixed One Device Model 2 (Device Based Rows)
First Row: srcLocalRP, desLocalRP (Local Row)
Second Row: srcRemoteRP, desRemoteRP (Remote Row)every one of the combinations above is valid and gives the same info 💅
the following steps are recommended for finding which reference points need to be configured 👑
- Locate both of the devices at either end of the PVC to be monitored. 🧚
- Determine the capabilities by referencing the
frsldRPCapsobject of each device. 🔍 - Locate the best combination of the two devices so that the necessary reference points are all represented. 🫶
- If any one of the necessary reference points doesn't exist in the combination of the two devices, it's not possible to monitor the FRF.13 defined SLA between the two reference point on the PVC. 😭
3.6.2.1. Graphical Examples of Reference Points ✨
okay so FRF.13 [17] defines three specific combos of reference points: Edge-to-Edge Interface, Edge-to-Edge Egress Queue, and End-to-End 🎀 The sections below walk through valid reference points for each one.
It's super common for a device to know either only local info or both local and remote info, so we'll illustrate both cases for each example 🧚
3.6.2.1.1. Edge-to-Edge Interface Reference Point Example 🦋
Device 1 Device 2
+-------------+ +-------------+
| Ingress | | Egress |
| +-----+ | | +-----+ |
|(A)| | | Traffic Flow | | |(B)|
-->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->-->
| | | | From Device 1 to 2 | | | |
| +-----+ | | +-----+ |
| | | |
| Egress | | Ingress |
| +-----+ | | +-----+ |
|(D)| | | Traffic Flow | | |(C)|
<--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<--
| | | | From Device 2 to 1 | | | |
| +-----+ | | +-----+ |
+-------------+ +-------------+
where (A), (B), (C) and (D) are reference points
Figure 3okay for devices with only local knowledge, you need one row on each device, like this:
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 2 = eqoRxLocalRP(5)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 1 = eqoRxLocalRP(5)so a single row gets created on Device 1 holding reference points (A) and (D), and a single row gets created on Device 2 holding (C) and (B) 💅
for devices with both local and remote knowledge, the two rows can live in any combo on either device 🌈 in this example, the transmitting devices handle the info about the flow they originate. Only one row per device is needed here, bestie 🫶
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 1 = eqoRxRemoteRP(11)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 2 = eqoRxRemoteRP(11)3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example 🌸
Device 1 Device 2
+-------------+ +-------------+
| Ingress | | Egress |
| +-----+ | | +-----+ |
|(A)| | | Traffic Flow |(B)| | |
-->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->-->
| | | | From Device 1 to 2 | | | |
| +-----+ | | +-----+ |
| | | |
| Egress | | Ingress |
| +-----+ | | +-----+ |
| | |(D)| Traffic Flow | | |(C)|
<--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<--
| | | | From Device 2 to 1 | | | |
| +-----+ | | +-----+ |
+-------------+ +-------------+
where (A), (B), (C) and (D) are reference points
Figure 4same energy here, just with the egress queue vibes 🔥 for devices with only local knowledge, one row goes on each device:
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 2 = eqiRxLocalRP(4)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 1 = eqiRxLocalRP(4)so a single row is created on Device 1 containing (A) and (D), and a single row is created on Device 2 containing (C) and (B) ✨
for devices with both local and remote knowledge, the two rows can exist in any combination on either device 💜 again the transmitting devices take responsibility for the info about the flow they're the origin of, and only one row per device is required for this example:
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 1 = eqiRxRemoteRP(10)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 2 = eqiRxRemoteRP(10)3.6.2.1.3. End-to-End Using Reference Point Example 🍓
Device 1 Device 2
+-------------+ +-------------+
| Source | | Destination |
| +-----+ | | +-----+ |
|(A)| | | Traffic Flow | | |(B)|
-->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->-->
| | | | From Device 1 to 2 | | | |
| +-----+ | | +-----+ |
| | | |
| Destination | | Source |
| +-----+ | | +-----+ |
|(D)| | | Traffic Flow | | |(C)|
<--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<--
| | | | From Device 2 to 1 | | | |
| +-----+ | | +-----+ |
+-------------+ +-------------+
where (A), (B), (C) and (D) are reference points
Figure 5last one, the end-to-end vibe 👑 for devices with only local knowledge, one row per device:
(A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1)
(B) frsldPvcCtlrReceiveRP for Device 2 = desLocalRP(1)
(C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1)
(D) frsldPvcCtlrReceiveRP for Device 1 = desLocalRP(1)a single row is created on Device 1 containing (A) and (D), and a single row is created on Device 2 containing (C) and (B) 🦋
for devices with both local and remote knowledge, the two rows can exist in any combo on either device. The transmitting devices are responsible for the flow they originate, and only one row per device is needed:
(A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1)
(B) frsldPvcCtlrReceiveRP for Device 1 = desRemoteRP(7)
(C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1)
(D) frsldPvcCtlrReceiveRP for Device 2 = desRemoteRP(7)3.6.3. Creation Process 🛠️
in some cases, devices will automatically fill in the rows of the PVC Control Table and possibly the Sample Control Table 🤖 but a lot of the time, a network manager has to create rows by hand.
manual row creation goes like this:
- Ensure the PVC exists between the two devices.
- Determine the necessary reference points for row creation.
- Create the row(s) in each device as needed.
- Create the row(s) in the sample control tables if desired.
3.6.4. Destruction Process 💀
3.6.4.1. Manual Row Destruction 🙅♀️
manual row destruction is straightforward ✨ any row can be destroyed, and its resources freed, by setting its status object (either frsldPvcCtrlStatus or frsldSmplCtrlStatus) to destroy(6). Heads up: when frsldPvcCtrlStatus is set to destroy(6), all the associated sample control, sample, and data table rows get destroyed too. Similarly, setting frsldSmplCtrlStatus to destroy(6) destroys all its sample rows.
ThefrsldPvcCtrlPurgeobjects don't apply to manual row destruction. If you set the row todestroy(6)manually, the rows are destroyed as part of that set.
3.6.4.2. Automatic Row Destruction 🤖
rows in the tables can be destroyed automatically based on whether the DLCI they rely on still exists 🌙 this is controlled by the frsldPvcCtrlPurge and frsldPvcCtrlDeleteOnPurge objects. When a DLCI no longer exists in the device, the data in the tables has no relation to anything known on the network. But there might be a reason to keep the historic info around for a short while after a DLCI is destroyed or removed. If the basis for the row is gone, the row gets destroyed at the end of the purge interval controlled by frsldPvcCtrlPurge.
the effects of automatic row destruction are the same as manual row destruction 💅
3.6.5. Modification Process ✏️
all read-create items in this MIB module can be modified at any time, as long as they're fully supported 💖 write access isn't required. To make life easier, frsldPvcCtrlWriteCaps and frsldSmplCtrlWriteCaps tell you which of the read-create variables can actually be written on a particular device.
3.6.6. Collection Process 📊
3.6.6.1. Remote Polling 📡
this MIB module supports data collection through remote polling of the free running counters in the PVC Data Table. Remote polling is a super common way to capture real-time stats: a remote management station polls the device to gather the info it wants 🔥 it's recommended that all statistics for a single PVC get collected in a single PDU.
the following objects are designed around the concept of real-time polling:
frsldPvcDataMissedPollsfrsldPvcDataFrDeliveredCfrsldPvcDataFrDeliveredEfrsldPvcDataFrOfferedCfrsldPvcDataFrOfferedEfrsldPvcDataDataDeliveredCfrsldPvcDataDataDeliveredEfrsldPvcDataDataOfferedCfrsldPvcDataDataOfferedEfrsldPvcDataHCFrDeliveredCfrsldPvcDataHCFrDeliveredEfrsldPvcDataHCFrOfferedCfrsldPvcDataHCFrOfferedEfrsldPvcDataHCDataDeliveredCfrsldPvcDataHCDataDeliveredEfrsldPvcDataHCDataOfferedCfrsldPvcDataHCDataOfferedEfrsldPvcDataUnavailableTimefrsldPvcDataUnavailables
3.6.6.2. Sampling 🧁
the sample tables let you look back at historic data without the extra overhead of polling 🌷 at key periods, a network management station can grab the samples it needs. This lets the manager collect data at times that least affect the active network traffic, which is very considerate of them 🫶
the sample data can be collected using a series of SNMP getNext or getBulk operations. The value of frsldPvcSmplIdx increments with each new collection bucket, so managers can skip info they've already collected. Just be careful, though: the value can roll over after a long period of time ⏳
the start and end times of a collection period tell the manager what the actual collection period was. There can be discontinuities in the sample table, so you should reference both start and end 💜
3.6.6.3. User History
Okay so user history (defined in RFC 2021 [19]) is an alternative way to get the same perks as the sample table, but it uses the objects you already have for real-time polling 🫶. Some devices MAY have the ability to use user history and opt not to support the sample tables 💅. If that's the case, the info from the data table can be used to define a group of user history objects ✨.
3.6.7. Use of MIB Module in Calculation of Service Level Definitions
The objects in this MIB module can be used to calculate the stats defined in FRF.13 [17] 🧮. This part describes the calcs for one direction of the data flow, i.e., data sent from local transmitter to a remote receiver. A complete bidirectional picture would need calcs from both directions 👑. For the purposes of this description, the reference points used SHOULD consistently represent data that is sent by one device and received by the other 🎀.
A complete evaluation needs the combo of two uni-directional flows 💖. A management station is able to combine all of the calculated info into one conceptual row. Doing this requires that each of the metrics are collected for both flow directions and grouped by direction. If the info is split between two devices, the management station must know which two devices to communicate with for the collection of all information 🙈. The grouping of information SHOULD be from ingress to egress in each flow direction 🦋.
The calcs below use the following terminology 🌸:
DelayAvgThe average delay on the PVC. This is represented within the MIB module byfrsldPvcSmplDelayAvg.FrDeliveredCThe number of frames received by the receiving device through the receive reference point that were delivered within CIR. This is represented within the MIB module by one offrsldPvcDataFrDeliveredC,frsldPvcDataHCFrDeliveredC,frsldPvcSmplFrDeliveredC, orfrsldPvcSmplHCFrDeliveredC.FrDeliveredEThe number of frames received by the receiving device through the receive reference point that were delivered in excess of CIR. This is represented within the MIB module by one offrsldPvcDataFrDeliveredE,frsldPvcDataHCFrDeliveredE,frsldPvcSmplFrDeliveredE, orfrsldPvcSmplHCFrDeliveredE.FrOfferedCThe number of frames offered by the transmitting device through the transmit reference point that were sent within CIR. This is represented within the MIB module by one offrsldPvcDataFrOfferedC,frsldPvcDataHCFrOfferedC,frsldPvcSmplFrOfferedC, orfrsldPvcSmplHCFrOfferedC.FrOfferedEThe number of frames offered by the transmitting device through the transmit reference point that were sent in excess of CIR. This is represented within the MIB module by one offrsldPvcDataFrOfferedE,frsldPvcDataHCFrOfferedE,frsldPvcSmplFrOfferedE, orfrsldPvcSmplHCFrOfferedE.DataDeliveredCThe number of octets received by the receiving device through the receive reference point that were delivered within CIR. This is represented within the MIB module by one offrsldPvcDataDataDeliveredC,frsldPvcDataHCDataDeliveredC,frsldPvcSmplDataDeliveredC, orfrsldPvcSmplHCDataDeliveredC.DataDeliveredEThe number of octets received by the receiving device through the receive reference point that were delivered in excess of CIR. This is represented within the MIB module by one offrsldPvcDataDataDeliveredE,frsldPvcDataHCDataDeliveredE,frsldPvcSmplDataDeliveredE, orfrsldPvcSmplHCDataDeliveredE.DataOfferedCThe number of octets offered by the transmitting device through the transmit reference point that were sent within CIR. This is represented within the MIB module by one offrsldPvcDataDataOfferedC,frsldPvcDataHCDataOfferedC,frsldPvcSmplDataOfferedC, orfrsldPvcSmplHCDataOfferedC.DataOfferedEThe number of octets offered by the transmitting device through the transmit reference point that were sent in excess of CIR. This is represented within the MIB module by one offrsldPvcDataDataOfferedE,frsldPvcDataHCDataOfferedE,frsldPvcSmplDataOfferedE, orfrsldPvcSmplHCDataOfferedE.UnavailableTimeThe amount of time the PVC was not available during the interval of interest. This is represented within the MIB module by eitherfrsldPvcDataUnavailableTimeorfrsldPvcSmplUnavailableTime.UnavailablesThe number of times the PVC was declared to be unavailable during the interval of interest. This is represented within the MIB module by eitherfrsldPvcDataUnavailablesorfrsldPvcSmplUnavailables.
3.6.8. Delay
The frame transfer delay is defined as the amount of time elapsed, in microseconds, from the time a frame exits the source to the time it reaches the destination ⏱️. The average delay can be found using the MIB variable described in DelayAvg above. The delay may be calculated as either round trip or one way, and this info is held in the frsldPvcCtrlDelayType MIB variable 🧠. If the delay be calculated as round trip, the value of DelayAvg represents the average of the total delays of the round trips. In this case, the manager SHOULD divide the value returned by the agent by two to obtain the frame transfer delay ➗. In the case that frsldPvcCtrlDelayType is oneWay, the value of DelayAvg represents the average of the frame transfer delays and SHOULD be used as is 💜.
3.6.9. Frame Delivery Ratio
The frame delivery ratio is defined as the total number of frames delivered to the destination divided by the frames offered by the source 📦. The destination values can be obtained using FrDeliveredC and FrDeliveredE. The source values can be obtained using FrOfferedC and FrOfferedE.
FrDeliveredC + FrDeliveredE
Frame Delivery Ratio = ---------------------------
FrOfferedC + FrOfferedE
FrDeliveredC
Committed Frame Delivery Ratio = ------------
FrOfferedC
FrDeliveredE
Excess Frame Delivery Ratio = ------------
FrOfferedE3.6.10. Data Delivery Ratio
The data delivery ratio is defined as the total amount of data delivered to the destination divided by the data offered by the source 🍓. The destination values can be obtained using DataDeliveredC and DataDeliveredE. The source values can be obtained using DataOfferedC and DataOfferedE.
DataDeliveredC + DataDeliveredE
Data Delivery Ratio = -------------------------------
DataOfferedC + DataOfferedE
DataDeliveredC
Committed Data Delivery Ratio = --------------
DataOfferedC
DataDeliveredE
Excess Data Delivery Ratio = --------------
DataOfferedE3.6.11. Service Availability
Some forms of service availability measurement defined in FRF.13 [17] require knowledge of the amount of time the network is allowed to be unavailable during the period of measurement 🕰️. This is called the excluded outage time and will be represented in the measurements below as ExcludedTime. It is assumed that the management software will maintain this information, because it often relates to specific times and dates that many devices are not capable of maintaining 📅. Further, it may change based on a moving maintenance window that the device cannot track well 🌈.
Mean Time to Repair (FRMTTR) = 0 if Unavailables is 0.
UnavailableTime
Otherwise, FRMTTR = ---------------
Unavailables
Virtual Connection Availability (FRVCA) = 0 if IntervalTime equals
ExcludedTime.
IntervalTime - ExcludedTime - UnavailableTime
Otherwise, FRVCA = --------------------------------------------- *100
IntervalTime - ExcludedTime
Mean Time Between Service Outages (FRMTBSO) = 0 if Unavailables is 0.
Otherwise, FRMTBSO = IntervalTime - ExcludedTime - UnavailableTime
---------------------------------------------
Unavailables4. Relation to Other MIB Modules ✨
There is no explicit relation to any other frame relay MIB module, nor are any required to implement this MIB module 🎀. However, there is a need for knowledge of ifIndexes and some understanding of DLCIs. The ifIndex info can be found in the IF-MIB [21], which is required. The DLCI info can be found in either the Frame Relay DTE MIB (RFC 2115) [20] or the Frame Relay Network Services MIB (RFC 2954) [18]; however, neither is required 🧩.
Upon setting of frsldPvcCtrlStatus in the frsldPvcCtrlTable to active(1), the system can be in one of the following three states 🦋:
(1) The respective DLCI is known and is active. This corresponds to a state in which frPVCEndptRowStatus is active(1) and frPVCEndptRcvdSigStatus is either active(2) or none(4) for the Frame Relay Network Services MIB (RFC 2954) [18]. For the Frame Relay DTE MIB, the same state is shown by frCircuitRowStatus of active(1) and frCircuitState of active(2).
(2) The respective DLCI has not been created. This corresponds to a state in which the row with either frPVCEndptDLCIIndex or frCircuitDlci equal to the respective DLCI does not exist in either the frPVCEndptTable or the frCircuitTable, respectively.
(3) The respective DLCI has just been removed. This corresponds to a state in which either frPVCEndptRowStatus is no longer active(1) or frPVCEndptRcvdSigStatus is no longer active(2) or none(4) for the Frame Relay Network Services MIB (RFC 2954) [18]. For the Frame Relay DTE MIB, the same state is shown when either frCircuitRowStatus is no longer active(1) or frCircuitState is no longer active(2).
For the first case, the row in the frsldPvcDataTable will be filled. If frsldSmplCtrlStatus in the frsldSmplCtrlTable for the respective DLCI is also active, the frsldPvcSampleTable will be filled as well 📊.
For the second case, the respective rows will not be added to any of the data or sample tables, and frsldPvcCtrlStatus SHOULD report notReady(3) 🙅♀️.
For the third case, frsldPvcCtrlDeleteOnPurge should direct the behavior of the system. If all tables are purged, this case will be equivalent to the second case above. Otherwise, frsldPvcCtrlStatus SHOULD remain active(1) 💫.
5. Structure of the MIB Module 🌷
The FRSLD-MIB consists of the following components:
frsldPvcCtrlTablefrsldSmplCtrlTablefrsldPvcDataTablefrsldPvcSampleTablefrsldCapabilities
Refer to the compliance statement defined within for a definition of what objects MUST be implemented 👑💖
5.1. frsldPvcCtrlTable 💖
okay bestie, this is the boss table 👑 frsldPvcCtrlTable is the central control table for the whole Frame Relay Service Level Definitions MIB. It holds the variables that control the parameters needed to calculate the objects in all the other tables ✨
A row in this table MUST exist in order for a row to exist in any other table in this MIB module. no control row, no rows anywhere else, periodt 🙅♀️
5.2. frsldSmplCtrlTable 🎀
this one is optional 🧚 It lets you control how sampling of the data in the data table works.
5.3. frsldPvcDataTable 🍓
this is where the calculated data lives 🧮 It relies on the configuration coming from the control table.
5.4. frsldPvcSampleTable 🦋
this table holds samples of the delivery and availability info from the data table, plus delay info calculated over the sample period 📊 It relies on config from both the control table and the sample control table, so it's a whole team effort 🫶
5.5. frsldCapabilities 🌈
this is a group of objects that define the write capabilities of the read-create objects in the tables above. basically it tells you what you're allowed to write 💅
6. Persistence of Data ✨
okay so the data in frsldPvcCtrlTable and frsldSmplCtrlTable SHOULD persist through power cycles 💾 But lowkey, the readiness rules still apply. That means a row can get reprovisioned as notReady(3) if the underlying DLCI doesn't persist, so don't be shocked 😭
The data collected in the other tables SHOULD NOT persist through power cycles, because the reference TimeStamp is no longer valid after a reboot ⏰ no cap, that makes total sense 🥹
7. Object Definitions 🧚
FRSLD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Gauge32, Integer32,
Counter64, TimeTicks, mib-2 FROM SNMPv2-SMI
CounterBasedGauge64 FROM HCNUM-TC
TEXTUAL-CONVENTION, RowStatus,
TimeStamp FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
ifIndex FROM IF-MIB
DLCI FROM FRAME-RELAY-DTE-MIB;
frsldMIB MODULE-IDENTITY
LAST-UPDATED "200201030000Z" -- January 3, 2002
ORGANIZATION "IETF Frame Relay Service MIB Working Group"
CONTACT-INFO
"IETF Frame Relay Service MIB (frnetmib) Working Group
WG Charter: http://www.ietf.org/html.charters/
frnetmib-charter.html
WG-email: frnetmib@sunroof.eng.sun.com
Subscribe: frnetmib-request@sunroof.eng.sun.com
Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib
Chair: Andy Malis
Vivace Networks
Email: Andy.Malis@vivacenetworks.com
WG editor: Robert Steinberger
Paradyne Networks and
Fujitsu Network Communications
Email: robert.steinberger@fnc.fujitsu.com
Co-author: Orly Nicklass
RAD Data Communications Ltd.
EMail: Orly_n@rad.co.il"
DESCRIPTION
"The MIB module to describe generic objects for
FRF.13 Frame Relay Service Level Definitions."
REVISION "200201030000Z" -- January 3, 2002
DESCRIPTION
"Initial version, published as RFC 3202"
::= { mib-2 95 }
--
-- Textual Conventions
--
FrsldTxRP ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The reference point a PVC uses for calculation
of transmitter related statistics.
The valid values for this type of object are as follows:
- srcLocalRP(1) for the local source
- ingTxLocalRP(2) for the local ingress queue input
- tpTxLocalRP(3) for the local traffic policing
- eqiTxLocalRP(4) for the local egress queue input
- eqoTxLocalRP(5) for the local egress queue output
- otherTxLocalRP(6) for any other local transmit point
- srcRemoteRP(7) for the remote source
- ingTxLocalRP(8) for the remote ingress queue input
- tpTxLocalRP(9) for the remote traffic policing
- eqiTxRemoteRP(10) for the remote egress queue input
- eqoTxRemoteRP(11) for the remote egress queue output
- otherTxRemoteRP(12) for any other remote xmit point"
REFERENCE
"FRF.13: Section 2.3"
SYNTAX INTEGER {
srcLocalRP(1),
ingTxLocalRP(2),
tpTxLocalRP(3),
eqiTxLocalRP(4),
eqoTxLocalRP(5),
otherTxLocalRP(6),
srcRemoteRP(7),
ingTxRemoteRP(8),
tpTxRemoteRP(9),
eqiTxRemoteRP(10),
eqoTxRemoteRP(11),
otherTxRemoteRP(12)
}
FrsldRxRP ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The reference point a PVC uses for calculation
of receiver related statistics.
The valid values for this object are as follows:
- desLocalRP(1) for the local destination
- ingRxLocalRP(2) for the local ingress queue input
- tpRxLocalRP(3) for the local traffic policing
- eqiRxLocalRP(4) for the local egress queue input
- eqoRxLocalRP(5) for the local egress queue output
- otherRxLocalRP(6) for any other local receive point
- desRemoteRP(7) for the remote destination
- ingRxRemoteRP(8) for the remote ingress input
- tpRxRemoteRP(9) for the remote traffic policing
- eqiRxRemoteRP(10) for the remote egress queue input
- eqoRxRemoteRP(11) for the remote egress queue output
- otherRxRemoteRP(12) for any other remote receive point"
REFERENCE
"FRF.13: Section 2.3"
SYNTAX INTEGER {
desLocalRP(1),
ingRxLocalRP(2),
tpRxLocalRP(3),
eqiRxLocalRP(4),
eqoRxLocalRP(5),
otherRxLocalRP(6),
desRemoteRP(7),
ingRxRemoteRP(8),
tpRxRemoteRP(9),
eqiRxRemoteRP(10),
eqoRxRemoteRP(11),
otherRxRemoteRP(12)
}
--
-- Base Objects
---
frsldObjects OBJECT IDENTIFIER ::= { frsldMIB 1 }
frsldCapabilities OBJECT IDENTIFIER ::= { frsldMIB 2 }
frsldConformance OBJECT IDENTIFIER ::= { frsldMIB 3 }
-- The Frame Relay Service Level Definitions PVC Control Table
--
-- This table is used to define and display the parameters of
-- service level definitions on individual PVCs.
frsldPvcCtrlTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldPvcCtrlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
PVC control table."
::= { frsldObjects 1 }
frsldPvcCtrlEntry OBJECT-TYPE
SYNTAX FrsldPvcCtrlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions PVC control table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP}
::= { frsldPvcCtrlTable 1 }
FrsldPvcCtrlEntry ::=
SEQUENCE {
--
-- Index Control Variables
--
frsldPvcCtrlDlci DLCI,
frsldPvcCtrlTransmitRP FrsldTxRP,
frsldPvcCtrlReceiveRP FrsldRxRP,
frsldPvcCtrlStatus RowStatus,
--
-- Service Level Definitions Setup Variables
--
frsldPvcCtrlPacketFreq Integer32,
--
-- Delay Specific Setup Variables
--
frsldPvcCtrlDelayFrSize Integer32,
frsldPvcCtrlDelayType INTEGER,
frsldPvcCtrlDelayTimeOut Integer32,
--
-- Data Persistence Control Variables
--
frsldPvcCtrlPurge Integer32,
frsldPvcCtrlDeleteOnPurge INTEGER,
frsldPvcCtrlLastPurgeTime TimeStamp
}
frsldPvcCtrlDlci OBJECT-TYPE
SYNTAX DLCI
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of this object is equal to the DLCI
value for this PVC."
::= { frsldPvcCtrlEntry 1 }
frsldPvcCtrlTransmitRP OBJECT-TYPE
SYNTAX FrsldTxRP
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The reference point this PVC uses for calculation
of transmitter related statistics. This object
together with frsldPvcCtrlReceiveRP define the
measurement domain."
REFERENCE
"FRF.13: Section 2.3"
::= { frsldPvcCtrlEntry 2 }
frsldPvcCtrlReceiveRP OBJECT-TYPE
SYNTAX FrsldRxRP
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The reference point this PVC uses for calculation
of receiver related statistics. This object
together with frsldPvcCtrlTransmitRP define the
measurement domain."
::= { frsldPvcCtrlEntry 3 }
frsldPvcCtrlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of the current row. This object is
used to add, delete, and disable rows in this
table. When the status changes to active(1) for the
first time, a row will also be added to the data
table below. This row SHOULD not be removed until
the status is changed to deleted.
When this object is set to destroy(6), all associated
sample and data table rows will also be deleted.
When this object is changed from active(1) to any
other valid value, the defined purge behavior will
affect the data and sample tables.
The rows added to this table MUST have a valid
ifIndex and an ifType related to frame relay. Further,
the reference points referred to by frsldPvcCtrlTransmitRP
and frsldPvcCtrlReceiveRP MUST be supported (see the
frsldRPCaps object).
If at any point the row is not in the active(1) state
and the DLCI no longer exists, the state SHOULD
report notReady(3).
The data in this table SHOULD persist through power
cycles. The symantics of readiness for the rows still
applies. This means that it is possible for a row to be
reprovisioned as notReady(3) if the underlying DLCI does
not persist."
::= { frsldPvcCtrlEntry 4 }
frsldPvcCtrlPacketFreq OBJECT-TYPE
SYNTAX Integer32 (0..3600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The frequency in seconds between initiation of
specialized packets used to collect delay and / or
delivery information as supported by the device.
A value of zero indicates that no packets will
be sent."
DEFVAL { 60 }
::= { frsldPvcCtrlEntry 5 }okay bestie, the delay and purge settings are where it gets spicy 🌶️💅
frsldPvcCtrlDelayFrSize OBJECT-TYPE
SYNTAX Integer32 (1..8188)
UNITS "octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The size of the payload in the frame used for
calculation of network delay."
DEFVAL { 128 }
::= { frsldPvcCtrlEntry 6 }
frsldPvcCtrlDelayType OBJECT-TYPE
SYNTAX INTEGER {
oneWay(1),
roundTrip(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of delay measurement performed."
REFERENCE
"FRF.13: Section 3"
::= { frsldPvcCtrlEntry 7 }
frsldPvcCtrlDelayTimeOut OBJECT-TYPE
SYNTAX Integer32 (1..3600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A delay frame will count as a missed poll if
it is not updated in the time specified by
frsldPvcCtrlDelayTimeOut."
DEFVAL { 60 }
::= { frsldPvcCtrlEntry 8 }
frsldPvcCtrlPurge OBJECT-TYPE
SYNTAX Integer32 (0..172800) -- up to 48 hours
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the amount of time the device
will wait, after discovering that a DLCI does not exist,
the DLCI was deleted or the value of frsldPvcCtrlStatus
changes from active(1) to either notInService(2) or
notReady(3), prior to automatically purging the history
in the sample tables and resetting the data in the data
tables to all zeroes. If frsldPvcCtrlStatus is manually
set to destroy(6), this object does not apply."
DEFVAL { 0 }
::= { frsldPvcCtrlEntry 9 }
frsldPvcCtrlDeleteOnPurge OBJECT-TYPE
SYNTAX INTEGER {
none(1),
sampleContols(2),
all(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether rows will
automatically be deleted from the tables
when the information is purged.
- A value of none(1) indicates that no rows
will deleted. The last known values will
be preserved.
- A value of sampleControls(2) indicates
that all associated sample control rows
will be deleted.
- A value of all(3) indicates that all
associated rows SHOULD be deleted."
DEFVAL { all }
::= { frsldPvcCtrlEntry 10 }
frsldPvcCtrlLastPurgeTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the value of sysUpTime
at the time the information was last purged.
This value SHOULD be set to the sysUpTime
upon setting frsldPvcCtrlStatus to active(1)
for the first time. Each time a
discontinuity in the counters occurs, this
value MUST be set to the sysUpTime.
If frsldPvcCtrlStatus has never been active(1),
this object SHOULD return 0.
This object SHOULD be used as the discontinuity
timer for the counters in frsldPvcDataTable."
::= { frsldPvcCtrlEntry 11 }the sampling control table is next, and it's giving organised 🗂️🫶
-- The Frame Relay Service Level Definitions Sampling Control
-- Table
--
-- This table is used to define the sample control parameters
-- of service level definitions on individual PVCs.
frsldSmplCtrlTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldSmplCtrlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
sampling control table."
::= { frsldObjects 2 }
frsldSmplCtrlEntry OBJECT-TYPE
SYNTAX FrsldSmplCtrlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions sample control table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP,
frsldSmplCtrlIdx }
::= { frsldSmplCtrlTable 1 }
FrsldSmplCtrlEntry ::=
SEQUENCE {
--
-- Index Control Variables
--
frsldSmplCtrlIdx Integer32,
frsldSmplCtrlStatus RowStatus,
--
-- Collection Control Variables
--
frsldSmplCtrlColPeriod Integer32,
frsldSmplCtrlBuckets Integer32,
frsldSmplCtrlBucketsGranted Integer32
}
frsldSmplCtrlIdx OBJECT-TYPE
SYNTAX Integer32 (1..256)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index for this row in the
sample control table."
::= { frsldSmplCtrlEntry 1 }
frsldSmplCtrlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of the current row. This object is
used to add, delete, and disable rows in this
table. This row SHOULD NOT be removed until the
status is changed to destroy(6). When the status
changes to active(1), the collection in the sample
tables below will be activated.
The rows added to this table MUST have a valid
ifIndex, an ifType related to frame relay,
frsldPvcCtrlDlci MUST exist for the specified
ifIndex and frsldPvcCtrlStatus MUST have a
value of active(1).
The value of frsldPvcCtrlStatus MUST be active(1)
to transition this object to active(1). If
the value of frsldPvcCtrlStatus becomes anything
other than active(1) when the state of this object
is not active(1), this object SHOULD be set to
notReady(3).
The data in this table SHOULD persist through power
cycles. The symantics of readiness for the rows still
applies. This means that it is possible for a row to be
reprovisioned as notReady(3) if the underlying DLCI does
not persist."
::= { frsldSmplCtrlEntry 2 }
frsldSmplCtrlColPeriod OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The amount of time in seconds that defines a
period of collection for the statistics.
At the end of each period, the statistics will be
sampled and a row is added to the sample table."
::= { frsldSmplCtrlEntry 3 }
frsldSmplCtrlBuckets OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of discrete buckets over which the
data statistics are sampled.
When this object is created or modified, the device
SHOULD attempt to set the frsldSmplCtrlBuckets-
Granted to a value as close as is possible
depending upon the implementation and the available
resources."
DEFVAL { 60 }
::= { frsldSmplCtrlEntry 4 }
frsldSmplCtrlBucketsGranted OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of discrete buckets granted. This
object will return 0 until frsldSmplCtrlStatus is
set to active(1). At that time the buckets will be
allocated depending upon implementation and
available resources."
::= { frsldSmplCtrlEntry 5 }and now we're on to the PVC data table, the one that polling systems actually care about 📈✨
-- The Frame Relay Service Level Definitions PVC Data Table
--
-- This table contains the accumulated values of
-- the collected data. This table is the table that should
-- be referenced by external polling mechanisms if time
-- based polling be desired.
frsldPvcDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldPvcDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
data table.
This table contains accumulated values of the
collected data. It is the table that should be
referenced by external polling mechanisms if
time based polling be desired."
::= { frsldObjects 3 }
frsldPvcDataEntry OBJECT-TYPE
SYNTAX FrsldPvcDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions data table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP}
::= { frsldPvcDataTable 1 }
FrsldPvcDataEntry ::=
SEQUENCE {
frsldPvcDataMissedPolls Counter32,
frsldPvcDataFrDeliveredC Counter32,
frsldPvcDataFrDeliveredE Counter32,
frsldPvcDataFrOfferedC Counter32,
frsldPvcDataFrOfferedE Counter32,
frsldPvcDataDataDeliveredC Counter32,
frsldPvcDataDataDeliveredE Counter32,
frsldPvcDataDataOfferedC Counter32,
frsldPvcDataDataOfferedE Counter32,
frsldPvcDataHCFrDeliveredC Counter64,
frsldPvcDataHCFrDeliveredE Counter64,
frsldPvcDataHCFrOfferedC Counter64,
frsldPvcDataHCFrOfferedE Counter64,
frsldPvcDataHCDataDeliveredC Counter64,
frsldPvcDataHCDataDeliveredE Counter64,
frsldPvcDataHCDataOfferedC Counter64,
frsldPvcDataHCDataOfferedE Counter64,
frsldPvcDataUnavailableTime TimeTicks,
frsldPvcDataUnavailables Counter32
}
frsldPvcDataMissedPolls OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of polls that have been determined
to be missed. These polls are typically associated
with the calculation of delay but may also be
used for the calculation of other statistics. If an
anticipated poll is not received in a reasonable
amount of time, it should be counted as missed.
The value used to determine the reasonable amount
of time is contained in frsldPvcCtrlDelayTimeOut.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
::= { frsldPvcDataEntry 1 }
frsldPvcDataFrDeliveredC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR.okay so we're still deep in the object definitions 💅 these frsldPvcData counters are giving main character energy, and every single one leans on FRF.13 and ends with the same discontinuity note 🦋
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcDataEntry 2 }
frsldPvcDataFrDeliveredE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliverede)"
::= { frsldPvcDataEntry 3 }
frsldPvcDataFrOfferedC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcDataEntry 4 }
frsldPvcDataFrOfferedE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcDataEntry 5 }
frsldPvcDataDataDeliveredC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcDataEntry 6 }
frsldPvcDataDataDeliveredE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcDataEntry 7 }
frsldPvcDataDataOfferedC OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcDataEntry 8 }
frsldPvcDataDataOfferedE OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcDataEntry 9 }
frsldPvcDataHCFrDeliveredC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR. This object is a 64-bit version
of frsldPvcDataFrDeliveredC.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcDataEntry 10 }
frsldPvcDataHCFrDeliveredE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR. This object is a 64-bit
version of frsldPvcDataFrDeliveredE.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliverede)"
::= { frsldPvcDataEntry 11 }
frsldPvcDataHCFrOfferedC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR. This object is
a 64-bit version of frsldPvcDataFrOfferedC.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcDataEntry 12 }
frsldPvcDataHCFrOfferedE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR. This
object is a 64-bit version of frsldPvcDataFrOfferedE.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcDataEntry 13 }
frsldPvcDataHCDataDeliveredC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR. This object is a 64-bit version of
frsldPvcDataDataDeliveredC.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcDataEntry 14 }
frsldPvcDataHCDataDeliveredE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR. This object is a 64-bit
version of frsldPvcDataDataDeliveredE.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcDataEntry 15 }
frsldPvcDataHCDataOfferedC OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR. This object is
a 64-bit version of frsldPvcDataDataOfferedC.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcDataEntry 16 }
frsldPvcDataHCDataOfferedE OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR.
This object is a 64-bit version of
frsldPvcDataDataOfferedE.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcDataEntry 17 }
frsldPvcDataUnavailableTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time this PVC was declared unavailable
for any reason since this row was created."
REFERENCE
"FRF.13: Section 6.1 (OutageTime)"
::= { frsldPvcDataEntry 18 }
frsldPvcDataUnavailables OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this PVC was declared unavailable
for any reason since this row was created.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times as indicated by
frsldPvcCtrlLastPurgeTime."
REFERENCE
"FRF.13: Section 6.1 (OutageCount)"
::= { frsldPvcDataEntry 19 }
-- The Frame Relay Service Level Definitions PVC Sample Table
--
-- This table contains the sampled delay, delivery and
-- availability information.
frsldPvcSampleTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrsldPvcSampleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Service Level Definitions
sample table."
::= { frsldObjects 4 }
frsldPvcSampleEntry OBJECT-TYPE
SYNTAX FrsldPvcSampleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Service Level
Definitions data sample table."
INDEX { ifIndex, frsldPvcCtrlDlci,
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP,
frsldSmplCtrlIdx, frsldPvcSmplIdx }
::= { frsldPvcSampleTable 1 }more MIB goodies coming up in the next part 🌸🎀
Okay bestie, the sample table is where the real tea is 💖 Every bucket has its own little stats box, and I need you to see how each object points back at FRF.13 🧚✨
FrsldPvcSampleEntry ::=
SEQUENCE {
frsldPvcSmplIdx Integer32,
frsldPvcSmplDelayMin Gauge32,
frsldPvcSmplDelayMax Gauge32,
frsldPvcSmplDelayAvg Gauge32,
frsldPvcSmplMissedPolls Gauge32,
frsldPvcSmplFrDeliveredC Gauge32,
frsldPvcSmplFrDeliveredE Gauge32,
frsldPvcSmplFrOfferedC Gauge32,
frsldPvcSmplFrOfferedE Gauge32,
frsldPvcSmplDataDeliveredC Gauge32,
frsldPvcSmplDataDeliveredE Gauge32,
frsldPvcSmplDataOfferedC Gauge32,
frsldPvcSmplDataOfferedE Gauge32,
frsldPvcSmplHCFrDeliveredC CounterBasedGauge64,
frsldPvcSmplHCFrDeliveredE CounterBasedGauge64,
frsldPvcSmplHCFrOfferedC CounterBasedGauge64,
frsldPvcSmplHCFrOfferedE CounterBasedGauge64,
frsldPvcSmplHCDataDeliveredC CounterBasedGauge64,
frsldPvcSmplHCDataDeliveredE CounterBasedGauge64,
frsldPvcSmplHCDataOfferedC CounterBasedGauge64,
frsldPvcSmplHCDataOfferedE CounterBasedGauge64,
frsldPvcSmplUnavailableTime TimeTicks,
frsldPvcSmplUnavailables Gauge32,
frsldPvcSmplStartTime TimeStamp,
frsldPvcSmplEndTime TimeStamp
}
frsldPvcSmplIdx OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The bucket index of the current sample. This
increments once for each new bucket in the
table."
::= { frsldPvcSampleEntry 1 }
frsldPvcSmplDelayMin OBJECT-TYPE
SYNTAX Gauge32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum delay reported in microseconds measured
for any information packet that arrived during this
interval.
A value of zero means that no data is available."
REFERENCE
"FRF.13: Section 3.1 (FTD)"
::= { frsldPvcSampleEntry 2 }
frsldPvcSmplDelayMax OBJECT-TYPE
SYNTAX Gauge32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The largest delay reported in microseconds measured
for any information packet that arrived during this
interval.
A value of zero means that no data is available."
REFERENCE
"FRF.13: Section 3.1 (FTD)"
::= { frsldPvcSampleEntry 3 }
frsldPvcSmplDelayAvg OBJECT-TYPE
SYNTAX Gauge32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average delay reported in microseconds measured
for all delay packets that arrived during this
interval.
A value of zero means that no data is available."
REFERENCE
"FRF.13: Section 3.1 (FTD)"
::= { frsldPvcSampleEntry 4 }
frsldPvcSmplMissedPolls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of polls that were missed during
this interval."
::= { frsldPvcSampleEntry 5 }
frsldPvcSmplFrDeliveredC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrDeliveredC."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcSampleEntry 6 }
frsldPvcSmplFrDeliveredE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR during this interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrDeliveredE."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliverede))"
::= { frsldPvcSampleEntry 7 }
frsldPvcSmplFrOfferedC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrOfferedC."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcSampleEntry 8 }
frsldPvcSmplFrOfferedE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCFrOfferedE."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcSampleEntry 9 }
frsldPvcSmplDataDeliveredC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataDeliveredC."
REFERENCE
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcSampleEntry 10 }
frsldPvcSmplDataDeliveredE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlDeliveredRP and determined to have been
sent in excess of the CIR during this interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataDeliveredE."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcSampleEntry 11 }
frsldPvcSmplDataOfferedC OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataOfferredC."
REFERENCE
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcSampleEntry 12 }
frsldPvcSmplDataOfferedE OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval.
If it is the case that the high capacity counters
are also used, this MUST report the value of the
lower 32 bits of the CounterBasedGauge64 value of
frsldPvcSmplHCDataOfferedE."
REFERENCE
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcSampleEntry 13 }
frsldPvcSmplHCFrDeliveredC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval. This object
is a 64-bit version of frsldPvcSmplFrDeliveredC."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcSampleEntry 14 }
frsldPvcSmplHCFrDeliveredE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR during this interval.
This object is a 64-bit version of frsldPvcSmpl-
FrDeliveredE."
REFERENCE
"FRF.13: Section 4.1 (FramesDeliverede)"
::= { frsldPvcSampleEntry 15 }
frsldPvcSmplHCFrOfferedC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval. This object is a 64-bit version of
frsldPvcSmplFrOfferedC."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcSampleEntry 16 }
frsldPvcSmplHCFrOfferedE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval. This object is a 64-bit
version of frsldPvcSmplFrOfferedE."
REFERENCE
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcSampleEntry 17 }
frsldPvcSmplHCDataDeliveredC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent within CIR during this interval. This value
is a 64-bit version of frsldPvcSmplDataDeliveredC."
REFERENCE
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcSampleEntry 18 }
frsldPvcSmplHCDataDeliveredE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were received at
frsldPvcCtrlReceiveRP and determined to have been
sent in excess of the CIR during this interval. This
value is a 64-bit version of frsldPvcSmplData-
DeliveredE."
REFERENCE
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcSampleEntry 19 }okay so we're picking up right where the object definitions left off 💅 this chunk is all about the HC (64-bit) sample counters, the outage stats, the sample timestamps, and the capabilities group that tells managers what a device can actually do 👑
frsldPvcSmplHCDataOfferedC OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP within CIR during this
interval. This value is a 64-bit version of
frsldPvcSmplDataOfferedC."
REFERENCE
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcSampleEntry 20 }
frsldPvcSmplHCDataOfferedE OBJECT-TYPE
SYNTAX CounterBasedGauge64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets that were offered through
frsldPvcCtrlTransmitRP in excess of the CIR
during this interval. This object is a 64-bit
version of frsldPvcSmplDataOfferedE."
REFERENCE
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcSampleEntry 21 }
frsldPvcSmplUnavailableTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time this PVC was declared
unavailable for any reason during this interval."
REFERENCE
"FRF.13: Section 6.1 (OutageTime)"
::= { frsldPvcSampleEntry 22 }
frsldPvcSmplUnavailables OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this PVC was declared
unavailable for any reason during this interval."
REFERENCE
"FRF.13: Section 6.1 (OutageCount)"
::= { frsldPvcSampleEntry 23 }
frsldPvcSmplStartTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this sample interval
started."
::= { frsldPvcSampleEntry 24 }
frsldPvcSmplEndTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this sample interval
ended. No data will be reported and the row will
not appear in the table until the sample has
been collected."
::= { frsldPvcSampleEntry 25 }
-- Capabilities Group
-- This group provides capabilities objects for the tables
-- that control configuration.
frsldPvcCtrlWriteCaps OBJECT-TYPE
SYNTAX BITS {
frsldPvcCtrlStatus(0),
frsldPvcCtrlPacketFreq(1),
frsldPvcCtrlDelayFrSize(2),
frsldPvcCtrlDelayType(3),
frsldPvcCtrlDelayTimeOut(4),
frsldPvcCtrlPurge(5),
frsldPvcCtrlDeleteOnPurge(6)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the write capabilities
for the read-create objects of the PVC Control
table. If the corresponding bit is enabled (1),
the agent supports writes to that object."
::= { frsldCapabilities 1 }
frsldSmplCtrlWriteCaps OBJECT-TYPE
SYNTAX BITS {
frsldSmplCtrlStatus(0),
frsldSmplCtrlBuckets(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the write capabilities
for the read-create objects of the Sample Control
table. If the corresponding bit is enabled (1),
the agent supports writes to that object."
::= { frsldCapabilities 2 }
frsldRPCaps OBJECT-TYPE
SYNTAX BITS {
srcLocalRP(0),
ingTxLocalRP(1),
tpTxLocalRP(2),
eqiTxLocalRP(3),
eqoTxLocalRP(4),
otherTxLocalRP(5),
srcRemoteRP(6),
ingTxRemoteRP(7),
tpTxRemoteRP(8),
eqiTxRemoteRP(9),
eqoTxRemoteRP(10),
otherTxRemoteRP(11),
desLocalRP(12),
ingRxLocalRP(13),
tpRxLocalRP(14),
eqiRxLocalRP(15),
eqoRxLocalRP(16),
otherRxLocalRP(17),
desRemoteRP(18),
ingRxRemoteRP(19),
tpRxRemoteRP(20),
eqiRxRemoteRP(21),
eqoRxRemoteRP(22),
otherRxRemoteRP(23)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the reference points that
the agent supports. This object allows the management
application to discover which rows can be created on
a specific device."
::= { frsldCapabilities 3 }
frsldMaxPvcCtrls OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of control rows that can be created
in frsldPvcCtrlTable. Sets to this object lower than
the current value of frsldNumPvcCtrls should result in
inconsistentValue."
::= { frsldCapabilities 4 }
frsldNumPvcCtrls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of rows in frsldPvcCtrlTable."
::= { frsldCapabilities 5 }
frsldMaxSmplCtrls OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of control rows that can be created
in frsldSmplCtrlTable. Sets to this object lower than
the current value of frsldNumSmplCtrls should result in
inconsistentValue."
::= { frsldCapabilities 6 }
frsldNumSmplCtrls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of rows in frsldSmplCtrlTable."
::= { frsldCapabilities 7 }
-- Conformance Information
frsldMIBGroups OBJECT IDENTIFIER ::= { frsldConformance 1 }
frsldMIBCompliances OBJECT IDENTIFIER ::= { frsldConformance 2 }
--
-- Compliance Statements
--
frsldCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
which support with Frame Relay Service Level
Definitions. This group defines the minimum
level of support required for compliance."
MODULE -- this module
MANDATORY-GROUPS { frsldPvcReqCtrlGroup,
frsldPvcReqDataGroup,
frsldCapabilitiesGroup}
GROUP frsldPvcHCFrameDataGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces with corresponding instance of ifSpeed
greater than 650,000,000 bits/second."
GROUP frsldPvcHCOctetDataGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces with corresponding instance of ifSpeed
greater than 650,000,000 bits/second."
GROUP frsldPvcPacketGroup
DESCRIPTION
"This group is optional. Network interfaces that
allow control of the packets used to collect
information are encouraged to implement this
group."
GROUP frsldPvcDelayCtrlGroup
DESCRIPTION
"This group is optional. Network interfaces that
offer control of the delay measurement are
strongly encouraged to implement this group."
GROUP frsldPvcSampleCtrlGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces that allow data sampling."
GROUP frsldPvcDelayDataGroup
DESCRIPTION
"This group is only mandatory when
frsldPvcDelayCtrlGroup is implemented. It is
strongly encouraged that any device capable
of measuring delay implement this group."
GROUP frsldPvcSampleDelayGroup
DESCRIPTION
"This group is only mandatory when both
frsldPvcSampleCtrlGroup and frsldPvcDelayDataGroup
are supported."
GROUP frsldPvcSampleDataGroup
DESCRIPTION
"This group is mandatory whenever
frsldPvcSampleCtrlGroup is supported."
GROUP frsldPvcSampleHCFrameGroup
DESCRIPTION
"This group is mandatory whenever both
frsldPvcSampleCtrlGroup and frsldPvcHCFrameDataGroup
are supported."
GROUP frsldPvcSampleHCDataGroup
DESCRIPTION
"This group is mandatory whenever both
frsldPvcSampleCtrlGroup and frsldPvcHCOctetDataGroup
are supported."
GROUP frsldPvcSampleAvailGroup
DESCRIPTION
"This group is mandatory whenever
frsldPvcSampleCtrlGroup is supported."
GROUP frsldPvcSampleGeneralGroup
DESCRIPTION
"This group is mandatory whenever
frsldPvcSampleCtrlGroup is supported."
OBJECT frsldPvcCtrlStatus
SYNTAX RowStatus { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Row creation can be done outside of the scope of
the SNMP protocol. If this object is implemented
with max-access of read-only, then the only value
that MUST be returned is active(1) and
frsldPvcCtrlWriteCaps MUST return 0 for the
frsldPvcCtrlStatus(0) bit."
OBJECT frsldPvcCtrlPurge
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. If this object is
implemented with a max-access of read-only, then
the frsldPvcCtrlPurge(5) bit must return 0."
OBJECT frsldPvcCtrlDeleteOnPurge
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. If this object is
implemented with a max-access of read-only, then
the frsldPvcCtrlDeleteOnPurge(6) bit must return
0."the compliance bit at the end is where the MUSTs get serious 🙈 if you implement frsldPvcCtrlStatus as read-only, active(1) is the only value you can return, and frsldPvcCtrlWriteCaps has to return 0 for that bit. no vibes-based implementing, bestie 💀
more coming up next, stay tuned 🦋🎀
Okay so picking up right where the compliance bit left off 💖 these are the MIN-ACCESS notes, then all the conformance groups 🎀
OBJECT frsldMaxPvcCtrls
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required if the device either
dynamically allocates memory or statically allocates
a fixed number of entries. In the case of static
allocation, the device should always report the
correct maximum number of controls. In the case
of dynamic allocation, the device SHOULD always
report a number greater than frsldNumPvcCtrls
when allocation is possible and a number equal to
frsldNumPvcCtrls when allocation is not possible."
OBJECT frsldMaxSmplCtrls
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required if the device either
dynamically allocates memory or statically allocates
a fixed number of entries. In the case of static
allocation, the device should always report the
correct maximum number of controls. In the case
of dynamic allocation, the device SHOULD always
report a number greater than frsldNumSmplCtrls
when allocation is possible and a number equal to
frsldNumSmplCtrls when allocation is not possible."
::= { frsldMIBCompliances 1 }
--
-- Units of Conformance
--
frsldPvcReqCtrlGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlStatus,
frsldPvcCtrlPurge,
frsldPvcCtrlDeleteOnPurge,
frsldPvcCtrlLastPurgeTime
}
STATUS current
DESCRIPTION
"A collection of required objects providing
control information applicable to a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 1 }
frsldPvcPacketGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlPacketFreq
}
STATUS current
DESCRIPTION
"A collection of optional objects providing packet
level control information applicable to a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 2 }
frsldPvcDelayCtrlGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlDelayFrSize,
frsldPvcCtrlDelayType,
frsldPvcCtrlDelayTimeOut
}
STATUS current
DESCRIPTION
"A collection of optional objects providing delay
control information applicable to a PVC which
implements Service Level Definitions.
If this group is implemented, frsldPvcPacketGroup
and frsldPvcDelayDataGroup MUST also be implemented."
::= { frsldMIBGroups 3 }
frsldPvcSampleCtrlGroup OBJECT-GROUP
OBJECTS {
frsldSmplCtrlStatus,
frsldSmplCtrlColPeriod,
frsldSmplCtrlBuckets,
frsldSmplCtrlBucketsGranted
}
STATUS current
DESCRIPTION
"A collection of optional objects providing sample
control information applicable to a PVC which
implements Service Level Definitions.
If this group is implemented, frsldPvcReqDataGroup
and frsldPvcSampleGeneralGroup MUST also be
implemented."
::= { frsldMIBGroups 4 }
frsldPvcReqDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataFrDeliveredC,
frsldPvcDataFrDeliveredE,
frsldPvcDataFrOfferedC,
frsldPvcDataFrOfferedE,
frsldPvcDataDataDeliveredC,
frsldPvcDataDataDeliveredE,
frsldPvcDataDataOfferedC,
frsldPvcDataDataOfferedE,
frsldPvcDataUnavailableTime,
frsldPvcDataUnavailables
}
STATUS current
DESCRIPTION
"A collection of required objects providing data
collected on a PVC which implements Service
Level Definitions."
::= { frsldMIBGroups 5 }
frsldPvcDelayDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataMissedPolls
}
STATUS current
DESCRIPTION
"A collection of optional objects providing delay
data collected on a PVC which implements Service
Level Definitions.
If this group is implemented, frsldPvcDelayCtrlGroup
MUST also be implemented."
::= { frsldMIBGroups 6 }
frsldPvcHCFrameDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataHCFrDeliveredC,
frsldPvcDataHCFrDeliveredE,
frsldPvcDataHCFrOfferedC,
frsldPvcDataHCFrOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity frame data collected on a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 7 }
frsldPvcHCOctetDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcDataHCDataDeliveredC,
frsldPvcDataHCDataDeliveredE,
frsldPvcDataHCDataOfferedC,
frsldPvcDataHCDataOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity octet data collected on a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 8 }
frsldPvcSampleDelayGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplDelayMin,
frsldPvcSmplDelayMax,
frsldPvcSmplDelayAvg,
frsldPvcSmplMissedPolls
}
STATUS current
DESCRIPTION
"A collection of optional objects providing delay
sample data collected on a PVC which implements
Service Level Definitions.
If this group is implemented, frsldPvcDelayCtrlGroup
MUST also be implemented."
::= { frsldMIBGroups 9 }
frsldPvcSampleDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplFrDeliveredC,
frsldPvcSmplFrDeliveredE,
frsldPvcSmplFrOfferedC,
frsldPvcSmplFrOfferedE,
frsldPvcSmplDataDeliveredC,
frsldPvcSmplDataDeliveredE,
frsldPvcSmplDataOfferedC,
frsldPvcSmplDataOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing data
and frame delivery sample data collected on a PVC
which implements Service Level Definitions.
If this group is implemented, frsldPvcReqDataGroup
MUST also be implemented."
::= { frsldMIBGroups 10 }
frsldPvcSampleHCFrameGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplHCFrDeliveredC,
frsldPvcSmplHCFrDeliveredE,
frsldPvcSmplHCFrOfferedC,
frsldPvcSmplHCFrOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity frame delivery sample data collected on a PVC
which implements Service Level Definitions.
If this group is implemented, frsldPvcHCFrameDataGroup
MUST also be implemented."
::= { frsldMIBGroups 11 }
frsldPvcSampleHCDataGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplHCDataDeliveredC,
frsldPvcSmplHCDataDeliveredE,
frsldPvcSmplHCDataOfferedC,
frsldPvcSmplHCDataOfferedE
}
STATUS current
DESCRIPTION
"A collection of optional objects providing high
capacity data delivery sample data collected on a PVC
which implements Service Level Definitions.
If this group is implemented, frsldPvcHCOctetDataGroup
MUST also be implemented."
::= { frsldMIBGroups 12 }
frsldPvcSampleAvailGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplUnavailableTime,
frsldPvcSmplUnavailables
}
STATUS current
DESCRIPTION
"A collection of optional objects providing
availability sample data collected on a PVC which
implements Service Level Definitions.
If this group is implemented, frsldPvcReqDataGroup
MUST also be implemented."
::= { frsldMIBGroups 13 }
frsldPvcSampleGeneralGroup OBJECT-GROUP
OBJECTS {
frsldPvcSmplStartTime,
frsldPvcSmplEndTime
}
STATUS current
DESCRIPTION
"A collection of optional objects providing
general sample data collected on a PVC which
implements Service Level Definitions."
::= { frsldMIBGroups 14 }
frsldCapabilitiesGroup OBJECT-GROUP
OBJECTS {
frsldPvcCtrlWriteCaps,
frsldSmplCtrlWriteCaps,
frsldRPCaps,
frsldMaxPvcCtrls,
frsldNumPvcCtrls,
frsldMaxSmplCtrls,
frsldNumSmplCtrls
}
STATUS current
DESCRIPTION
"A collection of required objects providing
capability information and control for this
MIB module."
::= { frsldMIBGroups 15 }
END8. Acknowledgments 🫶
This doc was made by the Frame Relay Service MIB Working Group 💅 It's based on the Frame Relay Forum's implementation agreement on service level definitions, FRF.13 [17] ✨
The editors wanna thank these lovelies for their helpful comments 🌸
- Ken Rehbehn, Visual Networks 🎀
- Santa Dasu, Quick Eagle Networks 🦋
9. References ✨
okay bestie, time for the receipts 🧾 these are all the docs this spec leans on, so you can go read the source if you want the full tea:
- [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
- [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
- [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
- [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
- [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
- [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
- [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
- [16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
- [17] Frame Relay Forum Technical Committee, "Service Level Definitions Implementations Agreement", FRF.13, August 1998.
- [18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000.
- [19] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
- [20] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.
- [21] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Security Considerations 🔐
this part is serious, so listen up 👀 a bunch of the management objects in this MIB are marked with a MAX-ACCESS of read-write and/or read-create. those objects can be sensitive or vulnerable depending on the network you're running. if SET operations happen in a non-secure environment without proper protection, they can really mess with network operations 😭
plain SNMPv1 is not a secure environment all by itself 💀 and even if the network underneath is secure (say, you're using IPSec), there's still no control over who on that secure network gets to access and do GET/SET (read/change/create/delete) on the objects in this MIB.
the move is to think about the security features that come with the SNMPv3 framework. specifically, the User-based Security Model in RFC 2574 [12] and the View-based Access Control Model in RFC 2575 [15] are recommended 🫶
and then it's on the customer/user to make sure the SNMP entity that gives access to this MIB is set up properly, so only the principals (users) with legit rights can actually GET or SET (change/create/delete) those objects. the access control is yours to configure, babe 💅
11. Authors' Addresses 💌
the people who wrote this spec, with their contact details copied exactly:
Robert Steinberger
Fujitsu Network Communications
2801 Telecom Parkway
Richardson, TX 75082
Phone: 1-972-479-4739
EMail: robert.steinberger@fnc.fujitsu.com
Orly Nicklass, Ph.D
RAD Data Communications Ltd.
12 Hanechoshet Street
Tel Aviv, Israel 69710
Phone: 972 3 7659969
EMail: Orly_n@rad.co.il12. Full Copyright Statement 🎀
Copyright (C) The Internet Society (2002). All Rights Reserved.
so here's the legal bit, but make it cute ✨ anyone can copy and share this document, and translations of it. people can also write derivative works that comment on or explain it or help people implement it, and publish and distribute those in whole or in part with zero restrictions, as long as the copyright notice and this paragraph show up on every copy and derivative work.
BUT the document itself can't be changed in any way. that means no stripping out the copyright notice or the references to the Internet Society or other Internet organizations. the only exceptions are developing Internet standards (in which case you have to follow the Internet Standards process copyright procedures) or translating it into languages other than English 🌈
the limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 💜
this document and the information in it are provided on an "AS IS" basis 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, Internet Society 💖
📦 where this page comes from
- ietf: rfc3202 2002-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms