As per Relevance of the word reference, we have this rfc below:
Network Working Group R.
Request for Comments: 3202 Paradyne
Category: Standards Track O.
RAD Data Communications Ltd
January 2002
Definitions of Managed
for Frame Relay Service Level
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This memo defines an extension of the Management Information
(MIB) for use with network management protocols in TCP/IP-
internets. In particular, it defines objects for managing the
Relay Service Level Definitions
Table of
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
Steinberger & Nicklass Standards Track [Page 1]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
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
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 ................................... 64
1. The SNMP Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described in
16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
second version, called SMIv2, is described in STD 58, RFC 2578
[5], RFC 2579 [6] and RFC 2580 [7].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [8]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9] and
Steinberger & Nicklass Standards Track [Page 2]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
1906 [10]. The third version of the message protocol is
SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
[12].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [8]. A second set of
operations and associated PDU formats is described in RFC 1905
[13].
o A set of fundamental applications described in RFC 2573 [14]
the view-based access control mechanism described in RFC 2575
[15].
A more detailed introduction to the current SNMP Management
can be found in RFC 2570 [16].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB
2.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL,
they appear in this document, are to be interpreted as described
RFC 2119 [22].
3.
This MIB module addresses the items required to manage the
Relay Forum's Implementation Agreement for Service Level
(FRF.13 [17]). At present, this applies to these values of
ifType variable in the Internet-standard MIB
o frameRelay (32)
o frameRelayService (44)
Steinberger & Nicklass Standards Track [Page 3]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
This section provides an overview and background of how to use
MIB module
3.1. Frame Relay Service Level
The frame relay service level definitions address
characteristics of a frame relay service that can be used
facilitate the following tasks
o Evaluation of frame relay service providers, offerings
products
o Measurement of Quality of Service
o Enforcement of Service Level Agreements
o Planning or describing a frame relay network
The following parameters are defined in FRF.13 [17] as a
set of values to accomplish the tasks previously stated
o Delay - The amount of time elapsed, in microseconds, from the
a frame exits the source to the time it reaches the destination
NOTE: FRF.13 [17] defines this value in terms of milliseconds
o Frame Delivery Ratio - The ratio of the number of frames
to the destination versus the number of frames sent by the source
This ratio can be further divided by inspecting either only
frames within the CIR or only the frames in excess of the CIR
o Data Delivery Ratio - The ratio of the amount of data delivered
the destination versus the amount of data sent by the source
This ratio can be further divided by inspecting either only
data within the CIR or only the data in excess of the CIR
o Service Availability - The amount of time the frame relay
was not available. There are three types of
statistics defined in FRF.13 [17]: Mean Time to Repair,
Connection Availability, and Mean Time Between Service Outages
The later two require information about the scheduled outage time
It is assumed that scheduled outage time information will
maintained by the network management software, so it is
included in the MIB module
Consult FRF.13 [17] for more details
Steinberger & Nicklass Standards Track [Page 4]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
3.2.
o CIR - The Committed Information Rate (CIR) is the subscriber
rate (expressed in bits/second) that the network commits
deliver under normal network conditions [18].
o DLCI - Data Link Connection Identifier [18].
o Logical Port - This term is used to model the Frame
"interface" on a device [18].
o NNI - Network to Network Interface [18].
o Permanent Virtual Connection (PVC) - A virtual connection that
its end-points and bearer capabilities defined at
time [18].
o Reference Point (RP) - The point of reference within the
model at which the calculations or data collection takes place
o UNI - User to Network Interface [18].
3.3. Network
The basic model, as illustrated in figure 1 below, contains two
relay DTE endpoints connected to a network cloud via a frame
UNI interface. The network cloud can contain zero or more
frame relay NNI connections that interconnect multiple networks.
calculations and data collection can be performed at any
point within the network
+-------------+ +-------------+
| Frame Relay | | Frame Relay |
| DTE Device | | DTE Device |
+------+------+ +------+------+
| |
UNI
Connection
| |
+------+------+ NNI +-------------+ NNI +------+------+
| Network A +------------+ Network B +------------+ Network C |
+-------------+ Connection +-------------+ Connection +-------------+
Figure 1
Frame Relay Network Reference
Steinberger & Nicklass Standards Track [Page 5]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
3.4. Reference
The collection and calculations of the service level
apply to two reference points within the network. These two
are the locations where the frames are referenced in the
of the service level specific information. The reference points
in the MIB module are shown in figure 2 below. For completeness,
module also allows for proprietary reference points which MAY
anywhere in the network that is not a previously defined
point. The meaning of the proprietary reference points
insignificant unless defined by the device manufacturer
Steinberger & Nicklass Standards Track [Page 6]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
+---------------------------+
|+-----------+ +-----------+|
|| | |Measurement||
||Frame Relay---Engine --(Source RP)----+
||DTE | |(If Exists)|| |
|+-----------+ +-----------+| |
+---------------------------+ |
Frame Relay Source |
+------------------------------------------+
| Frame Relay
| +----------------------------------+
| | +------------------------------+ |
| | | +---------+ +---------+ | |
| | | | | | 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])
Steinberger & Nicklass Standards Track [Page 7]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
The MIB variables frsldPvcCtrlTransmitRP and
allow the user to view and configure the reference points at
the calculations occur. These variables are specific to the
on which they are located. Frame relay devices act as both
sources and frame destinations. The definitions in this MIB
apply to the interaction of a pair of devices on the network path
The same device can potentially use different reference points
calculation and collection of the statistics based on whether
referenced frame is sent or received by the device. When the
is acting as a frame source, the value of
reflects the reference point used for all source
pertaining to the specified PVC. When the device is acting as
frame destination, the value of frsldPvcCtrlReceiveRP reflects
reference point used for all destination calculations pertaining
the specified PVC
For example, FRF.13 [17] defines an Edge-to-Edge Egress
measurement domain as a domain in which measurement is
between an Ingress Reference Point and an Egress Queue
Reference Point. For this domain between a source device and
destination device, the value of frsldPvcCtrlTransmitRP for
source device would be set to ingTxLocalRP(2) and the value
frsldPvcCtrlReceiveRP for the destination device would be set
eqiRxLocalRP(4). While it is usually the case that the
points would be equivalent on the remote device when
frames going in the opposite direction, there is no requirement
them to be so
It can be seen from the above example that a total of four
points are required in order to collect information for
directions of traffic flow. The reference points represent
transmit and receive directions at both ends of a PVC. If a
has knowledge of the information from the remote device, it
possible to collect the statistics from a single device. This is
always the case. In most instances, two devices will need to
monitored to capture a complete description of the service level on
PVC. The reference points a single device is capable of
are contained in the frsldRPCaps object
3.5. Measurement
This document neither recommends nor suggests a method
implementation. This is left to the device manufacturer and
be independent of the data that is actually collected
Periodic collection of this data can be performed through
polling of the data table, use of the sample tables or use of
user history group of RFC 2021 [19].
Steinberger & Nicklass Standards Track [Page 8]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
3.6. Theory of
The following sections describe how to use this MIB module.
include row handling, data collection and data calculation.
recommendations here in are suggestions as to implementation and
not infer that they are the only method that can be used to
such operations
3.6.1. Capabilities
Three objects are provided specifically to aid the network manager
discovering the capabilities of the device with respect to this
module
o frsldPvcCtrlWriteCaps This object reports the write
of the PVC Control Table. Use this
to determine which objects can be modified
This need only be referenced if
creation or modification is to
performed
o frsldSmplCtrlWriteCaps This object reports the write
of the Sample Control Table. Use
object to determine which objects can
modified. The group need only
referenced if the sample tables will
used to collect historical information
o frsldRPCaps This object reports the reference points
which the device is capable of
information. This object needs to
referenced if row creation is to
performed in the PVC Control Table
Devices can only create rows
supported reference points
These objects do not imply that there is no need for an
Capabilities macro for devices that do not fully support every
in this MIB module. They are provided specifically to aid in
ensured network management operations of this MIB module with
to row creation and modification
An additional four objects are provided to report and control
the utilization of this MIB module. These objects
frsldMaxPvcCtrls, frsldNumPvcCtrls, frsldMaxSmplCtrls
frsldNumSmplCtrls. Together, they allow a manager to control
Steinberger & Nicklass Standards Track [Page 9]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
amount of memory allocated for specific utilization by this
module. This is done by setting the maximum allowed allocation
controls
3.6.2. Determining Reference Points for Row
The performance of a PVC is monitored by evaluating the uni
directional flow of frames from an ingress point to an egress point
Reference points describe where each of the two measurements
made. Monitoring both of the uni-directional flows that make-up
PVC frame traffic requires a total of four reference points as
in Figures 3 through 5. A monitoring point that evaluates traffic
restricted to counting frames that pass the reference points
locally on the monitoring point. Thus, if the monitoring point
near the ingress point of the flow, it will count the frames
into the frame relay network. The complete picture of frame loss
the uni-directional flow requires information from the
reference point located at another (remote) monitoring point
The local monitoring point MAY be implemented in such way that
information from the downstream monitoring point is moved to
local monitoring point using implementation-specific mechanisms.
this case all information required to calculate frame loss
available from the local measurement point. The local
point agent is capable of reporting all the objects in
FrsldPvcDataEntry row - the counts for offered frames entering
network and delivered frames exiting the network
Alternatively, the local monitoring point MAY be restricted to
of frames observed on the local device only. In this case,
objects of the FrsldPvcDataEntry row reporting what happened on
remote device are not available
The following list shows the possible valid reference points for
FRF.13 SLA from the source reference point to the
reference point in both directions
o Local Information
Local Device: srcLocalRP,
Remote Device: srcLocalRP,
o Remote Information
Local Device: srcRemoteRP,
Remote Device: srcRemoteRP,
Steinberger & Nicklass Standards Track [Page 10]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
o Mixed Two Device Model 1 (Local Device Always Transmitter
Local Device: srcLocalRP,
Remote Device: srcLocalRP,
o Mixed Two Device Model 2 (Local Device Always Receiver
Local Device: srcRemoteRP,
Remote Device: srcRemoteRP,
o Mixed One Device Model 1 (Directional Rows
First Row: srcRemoteRP, desLocalRP (Receiver Row
Second Row: srcLocalRP, desRemoteRP (Sender Row
o Mixed One Device Model 2 (Device Based Rows
First Row: srcLocalRP, desLocalRP (Local Row
Second Row: srcRemoteRP, desRemoteRP (Remote Row
Each of the above combinations is valid and provides the
information
The following steps are recommended to find which reference
need to be configured
1) Locate both of the devices at either end of the PVC to
monitored
2) Determine the capabilities by referencing the frsldRPCaps
of each device
3) Locate the best combination of the two devices such that
necessary reference points are all represented
4) If any one of the necessary reference points does not exist in
combination of the two devices, it is not possible to monitor
FRF.13 defined SLA between the two reference point on the PVC
3.6.2.1. Graphical Examples of Reference
FRF.13 [17] defines three specific combinations of reference points
Edge-to-Edge Interface, Edge-to-Edge Egress Queue and End-to-End
Examples of valid reference points that may be used for each of
are discussed in the sections below
Steinberger & Nicklass Standards Track [Page 11]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
It is often the case that a device knows as a minimum either
local information or both local and remote information.
these are two common examples, each will be illustrated below
3.6.2.1.1. Edge-to-Edge Interface Reference Point
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
Figure 3
For devices with only local knowledge, one row is required on
device as follows
(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)
In which a single row is created on Device 1 containing
points (A) and (D), and a single row is created on Device 2
containing reference points (C) and (B).
For devices with both local and remote knowledge, the two rows
exist in any combination on either device. For this example,
transmitting devices will be responsible for information
the flow for which they are the origin. Only one row is required
device for this example
Steinberger & Nicklass Standards Track [Page 12]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
(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
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
Figure 4
For devices with only local knowledge, one row is required on
device as follows
(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)
In which a single row is created on Device 1 containing
points (A) and (D), and a single row is created on Device 2
containing reference points (C) and (B).
Steinberger & Nicklass Standards Track [Page 13]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
For devices with both local and remote knowledge, the two rows
exist in any combination on either device. For this example,
transmitting devices will be responsible for information
the flow for which they are the origin. Only one row is required
device 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
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
Figure 5
For devices with only local knowledge, one row is required on
device as follows
(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)
Steinberger & Nicklass Standards Track [Page 14]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
In which a single row is created on Device 1 containing
points (A) and (D), and a single row is created on Device 2
containing reference points (C) and (B).
For devices with both local and remote knowledge, the two rows
exist in any combination on either device. For this example,
transmitting devices will be responsible for information
the flow for which they are the origin. Only one row is required
device for this example
(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
In some cases, devices will automatically populate the rows of
Control Table and potentially the Sample Control Table. However,
many cases, it may be necessary for a network manager to
create rows
Manual creation of rows requires the following steps
1) Ensure the PVC exists between the two devices
2) Determine the necessary reference points for row creation
3) Create the row(s) in each device as needed
4) Create the row(s) in the sample control tables if desired
3.6.4. Destruction
3.6.4.1. Manual Row
Manual row destruction is straight forward. Any row can be
and the resources allocated to it are freed by setting the value
its status object (either frsldPvcCtrlStatus or frsldSmplCtrlStatus
to destroy(6). It should be noted that when frsldPvcCtrlStatus
set to destroy(6) all associated sample control, sample and
table rows will also be destroyed. Similarly,
frsldSmplCtrlStatus is set to destroy(6) all sample rows will also
Steinberger & Nicklass Standards Track [Page 15]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
destroyed. The frsldPvcCtrlPurge objects do not apply to manual
destruction. If the row is set to destroy(6) manually, the rows
destroyed as part of the set
3.6.4.2. Automatic Row
Rows is the tables may be destroyed automatically based on
existence of the DLCI on which they rely. This behavior
controlled by the frsldPvcCtrlPurge and
objects. When a DLCI no longer exists in the device, the data in
tables has no relation to anything known on the network. However
there may be some need to keep the historic information active for
short period after the destruction or removal of a DLCI. If
basis for the row no longer exists, the row will be destroyed at
end of the purge interval that is controlled by frsldPvcCtrlPurge
The effects of automatic row destruction are the same as manual
destruction
3.6.5. Modification
All read-create items in this MIB module can be modified at any
if they are fully supported. Write access is not required.
simplify the use of the MIB frsldPvcCtrlWriteCaps
frsldSmplCtrlWriteCaps state which of the read-create variables
actually be written on a particular device
3.6.6. Collection
3.6.6.1. Remote
This MIB module supports data collection through remote polling
the free running counters in the PVC Data Table. Remote polling is
common method used to capture real-time statistics. A
management station polls the device to collect the
information. It is recommended all statistics for a single PVC
collected in a single PDU
The following objects are designed around the concept of real-
polling
o
o
o
o
o
o
o
Steinberger & Nicklass Standards Track [Page 16]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
o
o
o
o
o
o
o
o
o
o
o
o
3.6.6.2.
The sample tables provide the ability to historically sample
without requiring the additional overhead of polling. At
periods, a network management station can collect the samples needed
This method allows the manager to perform the collection of data
times that will least affect the active network traffic
The sample data can be collected using a series of SNMP getNext
getBulk operations. The value of frsldPvcSmplIdx increments
each new collection bucket. This allows the managers to
information that has already been collected. However, care should
taken in that the value can roll over after a long period of time
The start and end times of a collection period allow the manager
know what the actual period of collection was. It is possible
there to be discontinuities in the sample table, so both start
end should be referenced
3.6.6.3. User
User history, as defined in RFC 2021 [19], is an
mechanism that can be used to get the same benefits as the
table by using the objects provided for real-time polling.
devices MAY have the ability to use user history and opt not
support the sample tables. If this is the case, the information
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
The objects in this MIB module can be used to calculate
statistics defined in FRF.13 [17]. The description below
the calculations for one direction of the data flow, i.e., data
from local transmitter to a remote receiver. A complete set
bidirectional information would require calculations based on
Steinberger & Nicklass Standards Track [Page 17]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
directions. For the purposes of this description, the
points used SHOULD consistently represent data that is sent by
device and received by the other
A complete evaluation requires the combination of two uni-
flows. It is possible for a management station to combine all of
calculated information into one conceptual row. Doing this
that each of the metrics are collected for both flow directions
grouped by direction If the information is split between
devices, the management station must know which two devices
communicate with for the collection of all information. The
of information SHOULD be from ingress to egress in each
direction
The calculations below use the following terminology
o
The average delay on the PVC. This is represented within
MIB module by frsldPvcSmplDelayAvg
o
The number of frames received by the receiving device
the receive reference point that were delivered within CIR
This is represented within the MIB module by one
frsldPvcDataFrDeliveredC, frsldPvcDataHCFrDeliveredC
frsldPvcSmplFrDeliveredC, or frsldPvcSmplHCFrDeliveredC
o
The number of frames received by the receiving device
the receive reference point that were delivered in excess
CIR. This is represented within the MIB module by one
frsldPvcDataFrDeliveredE, frsldPvcDataHCFrDeliveredE
frsldPvcSmplFrDeliveredE, or frsldPvcSmplHCFrDeliveredE
o
The number of frames offered by the transmitting device
the transmit reference point that were sent within CIR.
is represented within the MIB module by one
frsldPvcDataFrOfferedC, frsldPvcDataHCFrOfferedC
frsldPvcSmplFrOfferedC, or frsldPvcSmplHCFrOfferedC
Steinberger & Nicklass Standards Track [Page 18]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
o
The number of frames offered by the transmitting device
the transmit reference point that were sent in excess of CIR
This is represented within the MIB module by one
frsldPvcDataFrOfferedE, frsldPvcDataHCFrOfferedE
frsldPvcSmplFrOfferedE, or frsldPvcSmplHCFrOfferedE
o
The number of octets received by the receiving device
the receive reference point that were delivered within CIR
This is represented within the MIB module by one
frsldPvcDataDataDeliveredC, frsldPvcDataHCDataDeliveredC
frsldPvcSmplDataDeliveredC, or frsldPvcSmplHCDataDeliveredC
o
The number of octets received by the receiving device
the receive reference point that were delivered in excess
CIR. This is represented within the MIB module by one
frsldPvcDataDataDeliveredE, frsldPvcDataHCDataDeliveredE
frsldPvcSmplDataDeliveredE, or frsldPvcSmplHCDataDeliveredE
o
The number of octets offered by the transmitting device
the transmit reference point that were sent within CIR.
is represented within the MIB module by one
frsldPvcDataDataOfferedC, frsldPvcDataHCDataOfferedC
frsldPvcSmplDataOfferedC, or frsldPvcSmplHCDataOfferedC
o
The number of octets offered by the transmitting device
the transmit reference point that were sent in excess of CIR
This is represented within the MIB module by one
frsldPvcDataDataOfferedE, frsldPvcDataHCDataOfferedE
frsldPvcSmplDataOfferedE, or frsldPvcSmplHCDataOfferedE
o
The amount of time the PVC was not available during
interval of interest. This is represented within the
module by either frsldPvcDataUnavailableTime
frsldPvcSmplUnavailableTime
Steinberger & Nicklass Standards Track [Page 19]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
o
The number of times the PVC was declared to be
during the interval of interest. This is represented
the MIB module by either frsldPvcDataUnavailables
frsldPvcSmplUnavailables
3.6.8.
The frame transfer delay is defined as the amount of time elapsed,
microseconds, from the time a frame exits the source to the time
reaches the destination. The average delay can be found using
MIB variable described in DelayAvg above. The delay may
calculated as either round trip or one way, and this information
held in the frsldPvcCtrlDelayType MIB variable. If the delay
calculated as round trip, the value of DelayAvg represents
average of the total delays of the round trips. In this case,
manager SHOULD divide the value returned by the agent by two
obtain the frame transfer delay. In the case
frsldPvcCtrlDelayType is oneWay, the value of DelayAvg represents
average of the frame transfer delays and SHOULD be used as is
3.6.9. Frame Delivery
The frame delivery ratio is defined as the total number of
delivered to the destination divided by the frames offered by
source. The destination values can be obtained using
and FrDeliveredE. The source values can be obtained using
and FrOfferedE
FrDeliveredC +
Frame Delivery Ratio = ---------------------------
FrOfferedC +
Committed Frame Delivery Ratio = ------------
Excess Frame Delivery Ratio = ------------
Steinberger & Nicklass Standards Track [Page 20]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
3.6.10. Data Delivery
The data delivery ratio is defined as the total amount of
delivered to the destination divided by the data offered by
source. The destination values can be obtained using
and DataDeliveredE. The source values can be obtained
DataOfferedC and DataOfferedE
DataDeliveredC +
Data Delivery Ratio = -------------------------------
DataOfferedC +
Committed Data Delivery Ratio = --------------
Excess Data Delivery Ratio = --------------
3.6.11. Service
Some forms of service availability measurement defined in FRF.13 [17]
require knowledge of the amount of time the network is allowed to
unavailable during the period of measurement. This is called
excluded outage time and will be represented in the
below as ExcludedTime. It is assumed that the management
will maintain this information in that it often relates to
times and dates that many devices are not capable of maintaining
Further, it may change based on a moving maintenance window that
device cannot track well
Mean Time to Repair (FRMTTR) = 0 if Unavailables is 0.
Otherwise, FRMTTR = ---------------
Virtual Connection Availability (FRVCA) = 0 if IntervalTime
ExcludedTime
IntervalTime - ExcludedTime -
Otherwise, FRVCA = --------------------------------------------- *100
IntervalTime -
Mean Time Between Service Outages (FRMTBSO) = 0 if Unavailables is 0.
Steinberger & Nicklass Standards Track [Page 21]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
Otherwise, FRMTBSO = IntervalTime - ExcludedTime -
---------------------------------------------
4. Relation to Other MIB
There is no explicit relation to any other frame relay MIB module
are any required to implement this MIB module. However, there is
need for knowledge of ifIndexes and some understanding of DLCIs.
ifIndex information can be found in the IF-MIB [21] which
required. The DLCI information can be found in either the
Relay DTE MIB (RFC 2115) [20] or the Frame Relay Network Services
(RFC 2954) [18]; however, neither is required
Upon setting of frsldPvcCtrlStatus in the frsldPvcCtrlTable
active(1) the system can be in one of the following three states
(1) The respective DLCI is known and is active. This corresponds
a state in which frPVCEndptRowStatus is active(1)
frPVCEndptRcvdSigStatus is either active(2) or none(4) for
Frame Relay Network Services MIB (RFC 2954) [18]. For the
Relay DTE MIB, the same state is shown by frCircuitRowStatus
active(1) and frCircuitState of active(2).
(2) The respective DLCI has not been created. This corresponds to
state in which the row with either frPVCEndptDLCIIndex
frCircuitDlci equal to the respective DLCI does not exist
either the frPVCEndptTable or the frCircuitTable respectively
(3) The respective DLCI has just been removed. This corresponds to
state in which either frPVCEndptRowStatus is no longer active(1)
or frPVCEndptRcvdSigStatus is no longer active(2) or none(4)
the Frame Relay Network Services MIB (RFC 2954) [18]. For
Frame Relay DTE MIB, the same state is shown when
frCircuitRowStatus is no longer active(1) or frCircuitState is
longer active(2).
For the first case, the row in the frsldPvcDataTable will be filled
If frsldSmplCtrlStatus in the frsldSmplCtrlTable for the
DLCI is also `active' the frsldPvcSampleTable will be filled as well
For the second case, the respective rows will not be added to any
the data or sample tables and frsldPvcCtrlStatus SHOULD
notReady(3).
Steinberger & Nicklass Standards Track [Page 22]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
For the third case, frsldPvcCtrlDeleteOnPurge should direct
behavior of the system. If all tables are purged, this case will
equivalent to the second case above. Otherwise,
SHOULD remain active(1).
5. Structure of the MIB
The FRSLD-MIB consists of the following components
o
o
o
o
o
Refer to the compliance statement defined within for a definition
what objects MUST be implemented
5.1.
The frsldPvcCtrlTable is the central control table for operations
the Frame Relay Service Level Definitions MIB. It provides
to control the parameters required to calculate the objects in
other tables
A row in this table MUST exist in order for a row to exist in
other table in this MIB module
5.2.
This is an optional table to allow control of sampling of the data
the data table
5.3.
This table contains the calculated data. It relies on
from the control table
Steinberger & Nicklass Standards Track [Page 23]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
5.4.
This table contains samples of the delivery and
information from the data table as well as delay
calculated over the sample period. It relies on configuration
both the control table and the sample control table
5.5.
This is a group of objects that define write capabilities of
read-create objects in the tables above
6. Persistence of
The data in frsldPvcCtrlTable and frsldSmplCtrlTable SHOULD
through power cycles. Note, however, that the symantics of
for the rows still applies. This means that it is possible for a
to be reprovisioned as notReady(3) if the underlying DLCI does
persist. The data collected in the other tables SHOULD NOT
through power cycles in that the reference TimeStamp is no
valid
7. Object
FRSLD-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE
Counter32, Gauge32, Integer32,
Counter64, TimeTicks, mib-2 FROM SNMPv2-
CounterBasedGauge64 FROM HCNUM-
TEXTUAL-CONVENTION, RowStatus
TimeStamp FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-
ifIndex FROM IF-
DLCI FROM FRAME-RELAY-DTE-MIB
frsldMIB MODULE-
LAST-UPDATED "200201030000Z" -- January 3, 2002
ORGANIZATION "IETF Frame Relay Service MIB Working Group
CONTACT-
"IETF Frame Relay Service MIB (frnetmib) Working
WG Charter: http://www.ietf.org/html.charters
frnetmib-charter.
WG-email: frnetmib@sunroof.eng.sun.
Subscribe: frnetmib-request@sunroof.eng.sun.
Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/
Steinberger & Nicklass Standards Track [Page 24]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
Chair: Andy
Vivace
Email: Andy.Malis@vivacenetworks.
WG editor: Robert
Paradyne Networks
Fujitsu Network
Email: robert.steinberger@fnc.fujitsu.
Co-author: Orly
RAD Data Communications Ltd
EMail: Orly_n@rad.co.il
"The MIB module to describe generic objects
FRF.13 Frame Relay Service Level Definitions."
REVISION "200201030000Z" -- January 3, 2002
"Initial version, published as RFC 3202"
::= { mib-2 95 }
--
-- Textual
--
FrsldTxRP ::= TEXTUAL-
STATUS
"The reference point a PVC uses for
of transmitter related statistics
The valid values for this type of object are as follows
- srcLocalRP(1) for the local
- ingTxLocalRP(2) for the local ingress queue
- tpTxLocalRP(3) for the local traffic
- eqiTxLocalRP(4) for the local egress queue
- eqoTxLocalRP(5) for the local egress queue
- otherTxLocalRP(6) for any other local transmit
- srcRemoteRP(7) for the remote
- ingTxLocalRP(8) for the remote ingress queue
- tpTxLocalRP(9) for the remote traffic
- eqiTxRemoteRP(10) for the remote egress queue
- eqoTxRemoteRP(11) for the remote egress queue
- otherTxRemoteRP(12) for any other remote xmit point
"FRF.13: Section 2.3"
SYNTAX INTEGER {
srcLocalRP(1),
ingTxLocalRP(2),
tpTxLocalRP(3),
Steinberger & Nicklass Standards Track [Page 25]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
eqiTxLocalRP(4),
eqoTxLocalRP(5),
otherTxLocalRP(6),
srcRemoteRP(7),
ingTxRemoteRP(8),
tpTxRemoteRP(9),
eqiTxRemoteRP(10),
eqoTxRemoteRP(11),
otherTxRemoteRP(12)
}
FrsldRxRP ::= TEXTUAL-
STATUS
"The reference point a PVC uses for
of receiver related statistics
The valid values for this object are as follows
- desLocalRP(1) for the local
- ingRxLocalRP(2) for the local ingress queue
- tpRxLocalRP(3) for the local traffic
- eqiRxLocalRP(4) for the local egress queue
- eqoRxLocalRP(5) for the local egress queue
- otherRxLocalRP(6) for any other local receive
- desRemoteRP(7) for the remote
- ingRxRemoteRP(8) for the remote ingress
- tpRxRemoteRP(9) for the remote traffic
- eqiRxRemoteRP(10) for the remote egress queue
- eqoRxRemoteRP(11) for the remote egress queue
- otherRxRemoteRP(12) for any other remote receive point
"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)
}
--
Steinberger & Nicklass Standards Track [Page 26]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
-- Base
---
frsldObjects OBJECT IDENTIFIER ::= { frsldMIB 1 }
frsldCapabilities OBJECT IDENTIFIER ::= { frsldMIB 2 }
frsldConformance OBJECT IDENTIFIER ::= { frsldMIB 3 }
-- The Frame Relay Service Level Definitions PVC Control
--
-- This table is used to define and display the parameters
-- service level definitions on individual PVCs
frsldPvcCtrlTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The Frame Relay Service Level
PVC control table."
::= { frsldObjects 1 }
frsldPvcCtrlEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"An entry in the Frame Relay Service
Definitions PVC control table."
INDEX { ifIndex, frsldPvcCtrlDlci
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP
::= { frsldPvcCtrlTable 1 }
FrsldPvcCtrlEntry ::=
SEQUENCE {
--
-- Index Control
--
frsldPvcCtrlDlci DLCI
frsldPvcCtrlTransmitRP FrsldTxRP
frsldPvcCtrlReceiveRP FrsldRxRP
frsldPvcCtrlStatus RowStatus
--
-- Service Level Definitions Setup
--
frsldPvcCtrlPacketFreq Integer32,
--
-- Delay Specific Setup
--
Steinberger & Nicklass Standards Track [Page 27]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
frsldPvcCtrlDelayFrSize Integer32,
frsldPvcCtrlDelayType INTEGER
frsldPvcCtrlDelayTimeOut Integer32,
--
-- Data Persistence Control
--
frsldPvcCtrlPurge Integer32,
frsldPvcCtrlDeleteOnPurge INTEGER
frsldPvcCtrlLastPurgeTime
}
frsldPvcCtrlDlci OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The value of this object is equal to the
value for this PVC."
::= { frsldPvcCtrlEntry 1 }
frsldPvcCtrlTransmitRP OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The reference point this PVC uses for
of transmitter related statistics. This
together with frsldPvcCtrlReceiveRP define
measurement domain."
"FRF.13: Section 2.3"
::= { frsldPvcCtrlEntry 2 }
frsldPvcCtrlReceiveRP OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The reference point this PVC uses for
of receiver related statistics. This
together with frsldPvcCtrlTransmitRP define
measurement domain."
::= { frsldPvcCtrlEntry 3 }
frsldPvcCtrlStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
Steinberger & Nicklass Standards Track [Page 28]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
"The status of the current row. This object
used to add, delete, and disable rows in
table. When the status changes to active(1) for
first time, a row will also be added to the
table below. This row SHOULD not be removed
the status is changed to deleted
When this object is set to destroy(6), all
sample and data table rows will also be deleted
When this object is changed from active(1) to
other valid value, the defined purge behavior
affect the data and sample tables
The rows added to this table MUST have a
ifIndex and an ifType related to frame relay. Further
the reference points referred to by
and frsldPvcCtrlReceiveRP MUST be supported (see
frsldRPCaps object).
If at any point the row is not in the active(1)
and the DLCI no longer exists, the state
report notReady(3).
The data in this table SHOULD persist through
cycles. The symantics of readiness for the rows
applies. This means that it is possible for a row to
reprovisioned as notReady(3) if the underlying DLCI
not persist."
::= { frsldPvcCtrlEntry 4 }
frsldPvcCtrlPacketFreq OBJECT-
SYNTAX Integer32 (0..3600)
UNITS "seconds
MAX-ACCESS read-
STATUS
"The frequency in seconds between initiation
specialized packets used to collect delay and /
delivery information as supported by the device
A value of zero indicates that no packets
be sent."
DEFVAL { 60 }
::= { frsldPvcCtrlEntry 5 }
frsldPvcCtrlDelayFrSize OBJECT-
SYNTAX Integer32 (1..8188)
UNITS "octets
Steinberger & Nicklass Standards Track [Page 29]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
MAX-ACCESS read-
STATUS
"The size of the payload in the frame used
calculation of network delay."
DEFVAL { 128 }
::= { frsldPvcCtrlEntry 6 }
frsldPvcCtrlDelayType OBJECT-
SYNTAX INTEGER {
oneWay(1),
roundTrip(2)
}
MAX-ACCESS read-
STATUS
"The type of delay measurement performed."
"FRF.13: Section 3"
::= { frsldPvcCtrlEntry 7 }
frsldPvcCtrlDelayTimeOut OBJECT-
SYNTAX Integer32 (1..3600)
UNITS "seconds
MAX-ACCESS read-
STATUS
"A delay frame will count as a missed poll
it is not updated in the time specified
frsldPvcCtrlDelayTimeOut."
DEFVAL { 60 }
::= { frsldPvcCtrlEntry 8 }
frsldPvcCtrlPurge OBJECT-
SYNTAX Integer32 (0..172800) -- up to 48
UNITS "seconds
MAX-ACCESS read-
STATUS
"This object defines the amount of time the
will wait, after discovering that a DLCI does not exist
the DLCI was deleted or the value of
changes from active(1) to either notInService(2)
notReady(3), prior to automatically purging the
in the sample tables and resetting the data in the
tables to all zeroes. If frsldPvcCtrlStatus is
set to destroy(6), this object does not apply."
DEFVAL { 0 }
Steinberger & Nicklass Standards Track [Page 30]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
::= { frsldPvcCtrlEntry 9 }
frsldPvcCtrlDeleteOnPurge OBJECT-
SYNTAX INTEGER {
none(1),
sampleContols(2),
all(3)
}
MAX-ACCESS read-
STATUS
"This object defines whether rows
automatically be deleted from the
when the information is purged
- A value of none(1) indicates that no
will deleted. The last known values
be preserved
- A value of sampleControls(2)
that all associated sample control
will be deleted
- A value of all(3) indicates that
associated rows SHOULD be deleted."
DEFVAL { all }
::= { frsldPvcCtrlEntry 10 }
frsldPvcCtrlLastPurgeTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"This object returns the value of
at the time the information was last purged
This value SHOULD be set to the
upon setting frsldPvcCtrlStatus to active(1)
for the first time. Each time
discontinuity in the counters occurs,
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
timer for the counters in frsldPvcDataTable."
::= { frsldPvcCtrlEntry 11 }
-- The Frame Relay Service Level Definitions Sampling
--
Steinberger & Nicklass Standards Track [Page 31]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
--
-- This table is used to define the sample control
-- of service level definitions on individual PVCs
frsldSmplCtrlTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The Frame Relay Service Level
sampling control table."
::= { frsldObjects 2 }
frsldSmplCtrlEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"An entry in the Frame Relay Service
Definitions sample control table."
INDEX { ifIndex, frsldPvcCtrlDlci
frsldPvcCtrlTransmitRP, frsldPvcCtrlReceiveRP
frsldSmplCtrlIdx }
::= { frsldSmplCtrlTable 1 }
FrsldSmplCtrlEntry ::=
SEQUENCE {
--
-- Index Control
--
frsldSmplCtrlIdx Integer32,
frsldSmplCtrlStatus RowStatus
--
-- Collection Control
--
frsldSmplCtrlColPeriod Integer32,
frsldSmplCtrlBuckets Integer32,
frsldSmplCtrlBucketsGranted Integer32
}
frsldSmplCtrlIdx OBJECT-
SYNTAX Integer32 (1..256)
MAX-ACCESS not-
STATUS
"The unique index for this row in
sample control table."
::= { frsldSmplCtrlEntry 1 }
Steinberger & Nicklass Standards Track [Page 32]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
frsldSmplCtrlStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of the current row. This object
used to add, delete, and disable rows in
table. This row SHOULD NOT be removed until
status is changed to destroy(6). When the
changes to active(1), the collection in the
tables below will be activated
The rows added to this table MUST have a
ifIndex, an ifType related to frame relay
frsldPvcCtrlDlci MUST exist for the
ifIndex and frsldPvcCtrlStatus MUST have
value of active(1).
The value of frsldPvcCtrlStatus MUST be active(1)
to transition this object to active(1).
the value of frsldPvcCtrlStatus becomes
other than active(1) when the state of this
is not active(1), this object SHOULD be set
notReady(3).
The data in this table SHOULD persist through
cycles. The symantics of readiness for the rows
applies. This means that it is possible for a row to
reprovisioned as notReady(3) if the underlying DLCI
not persist."
::= { frsldSmplCtrlEntry 2 }
frsldSmplCtrlColPeriod OBJECT-
SYNTAX Integer32 (1..2147483647)
UNITS "seconds
MAX-ACCESS read-
STATUS
"The amount of time in seconds that defines
period of collection for the statistics
At the end of each period, the statistics will
sampled and a row is added to the sample table."
::= { frsldSmplCtrlEntry 3 }
frsldSmplCtrlBuckets OBJECT-
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-
STATUS
Steinberger & Nicklass Standards Track [Page 33]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
"The number of discrete buckets over which
data statistics are sampled
When this object is created or modified, the
SHOULD attempt to set the frsldSmplCtrlBuckets
Granted to a value as close as is
depending upon the implementation and the
resources."
DEFVAL { 60 }
::= { frsldSmplCtrlEntry 4 }
frsldSmplCtrlBucketsGranted OBJECT-
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-
STATUS
"The number of discrete buckets granted.
object will return 0 until frsldSmplCtrlStatus
set to active(1). At that time the buckets will
allocated depending upon implementation
available resources."
::= { frsldSmplCtrlEntry 5 }
-- The Frame Relay Service Level Definitions PVC Data
--
-- This table contains the accumulated values
-- the collected data. This table is the table that
-- be referenced by external polling mechanisms if
-- based polling be desired
frsldPvcDataTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The Frame Relay Service Level
data table
This table contains accumulated values of
collected data. It is the table that should
referenced by external polling mechanisms
time based polling be desired."
::= { frsldObjects 3 }
frsldPvcDataEntry OBJECT-
SYNTAX
MAX-ACCESS not-
Steinberger & Nicklass Standards Track [Page 34]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
STATUS
"An entry in the Frame Relay Service
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-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of polls that have been
to be missed. These polls are typically
with the calculation of delay but may also
used for the calculation of other statistics. If
anticipated poll is not received in a
amount of time, it should be counted as missed
The value used to determine the reasonable
of time is contained in frsldPvcCtrlDelayTimeOut
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
Steinberger & Nicklass Standards Track [Page 35]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
frsldPvcCtrlLastPurgeTime."
::= { frsldPvcDataEntry 1 }
frsldPvcDataFrDeliveredC OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of frames that were received
frsldPvcCtrlReceiveRP and determined to have
sent within CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcDataEntry 2 }
frsldPvcDataFrDeliveredE OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of frames that were received
frsldPvcCtrlReceiveRP and determined to have
sent in excess of the CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 4.1 (FramesDeliverede)"
::= { frsldPvcDataEntry 3 }
frsldPvcDataFrOfferedC OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of frames that were offered
frsldPvcCtrlTransmitRP within CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
Steinberger & Nicklass Standards Track [Page 36]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 4.1 (FramesOfferedc)"
::= { frsldPvcDataEntry 4 }
frsldPvcDataFrOfferedE OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of frames that were offered
frsldPvcCtrlTransmitRP in excess of the CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 4.1 (FramesOfferede)"
::= { frsldPvcDataEntry 5 }
frsldPvcDataDataDeliveredC OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of octets that were received
frsldPvcCtrlReceiveRP and determined to have
sent within CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 5.1 (DataDeliveredc)"
::= { frsldPvcDataEntry 6 }
frsldPvcDataDataDeliveredE OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of octets that were received
frsldPvcCtrlReceiveRP and determined to have
sent in excess of the CIR
Discontinuities in the value of this counter
Steinberger & Nicklass Standards Track [Page 37]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 5.1 (DataDeliverede)"
::= { frsldPvcDataEntry 7 }
frsldPvcDataDataOfferedC OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of octets that were offered
frsldPvcCtrlTransmitRP within CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 5.1 (DataOfferedc)"
::= { frsldPvcDataEntry 8 }
frsldPvcDataDataOfferedE OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of octets that were offered
frsldPvcCtrlTransmitRP in excess of the CIR
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 5.1 (DataOfferede)"
::= { frsldPvcDataEntry 9 }
frsldPvcDataHCFrDeliveredC OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS
"The number of frames that were received
frsldPvcCtrlReceiveRP and determined to have
sent within CIR. This object is a 64-bit
of frsldPvcDataFrDeliveredC
Steinberger & Nicklass Standards Track [Page 38]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as indicated
frsldPvcCtrlLastPurgeTime."
"FRF.13: Section 4.1 (FramesDeliveredc)"
::= { frsldPvcDataEntry 10 }
frsldPvcDataHCFrDeliveredE OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS
"The number of frames that were received
frsldPvcCtrlReceiveRP and determined to have
sent in excess of the CIR. This object is a 64-
version of frsldPvcDataFrDeliveredE
Discontinuities in the value of this counter
occur at re-initialization of the management
and at other times as 