RFC 2115
Management Information Base for Frame Relay DTEs Using SMIv2
Okay bestie, let's get into RFC 2115 🎀, which is titled Management Information Base for Frame Relay DTEs Using SMIv2 💖. C. Brown from Cadia Networks, Inc. and F. Baker from Cisco Systems wrote it in September 1997 🍓. It's a Standards Track doc, so it's an actual internet standard 👑. It obsoletes RFC 1315, so this one officially replaces that older version 🫶. There are no updates listed in the header, so it doesn't touch anything else.
1. Status of this Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 💅. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
2. Abstract ✨
This memo defines a chunk of the Management Information Base (MIB) for network management protocols in TCP/IP-based internets 🧚. Specifically, it defines objects for managing Frame Relay interfaces on DTEs 🦋.
Table of Contents
1 Status of this Memo ................................... 1
2 Abstract .............................................. 1
3 The SNMPv2 Network Management Framework ............... 2
4 Overview .............................................. 2
4.1 Frame Relay Operational Model ....................... 2
4.2 Textual Conventions ................................. 6
4.3 Structure of MIB .................................... 6
5 Changes from RFC 1315 ................................. 6
6 Definitions ........................................... 8
6.1 Data Link Connection Management Interface ........... 9
6.2 Circuit Table ....................................... 14
6.3 Error Table ......................................... 22
6.4 Trap Management ..................................... 25
7 Security Issues ....................................... 30
8 Acknowledgments ....................................... 30
9 Authors' Addresses .................................... 31
10 References ........................................... 313. The SNMPv2 Network Management Framework
okay so the major pieces of the SNMPv2 Network Management framework are described in these docs 💜:
- RFC 1902 [1] defines the Structure of Management Information (SMI), which is the stuff used for describing and naming objects for management purposes 🎀.
- STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects (MO) for the Internet suite of protocols 🌸.
- RFC 1905 [3] defines the protocol used for network access to managed objects 🔥.
The framework is adaptable and extensible, which is so iconic, because you can define new MIBs to suit the requirements of specific applications, protocols, or situations ✨.
Managed objects are accessed through a virtual information store called the MIB 🦋. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI 💅. Each object type is named by an OBJECT IDENTIFIER, which is an administratively assigned name 🧚. The object type together with an object instance uniquely identifies one specific instantiation of the object 🫶. For human convenience, a textual string called the descriptor is often used to refer to the object type 🌈.
4. Overview ✨
4.1. Frame Relay Operational Model
For this document, Frame Relay is viewed as a multi-access media, not as a group of point-to-point connections 🧚. The big idea is that Frame Relay is a single interface to the network (a physical connection) with many destinations or neighbors (virtual connections) 💖. This lets a network manager group all the virtual connections with their corresponding physical connection, which makes diagnostics and trouble shooting way simpler 🔥.
With the extension of the interfaces MIB, you can configure frame relay DLCs as individual interfaces and create ifTable entries for each one 👑. This is not recommended and is not directly supported by this MIB 🙈. Also, when demand circuits are in the picture, creating individual ifEntries for each one isn't possible 💀.
If you want to group DLCs together to associate them with a higher layer, or to associate a DLC with an unnumbered point-to-point service, the frame relay DTE MIB gives you an entry in the frCircuitEntry record 🎀. For example, say you configure a company proprietary protocol to run above several of the frame relay VCs. The basic layering looks something like this 🦋:
IP (ipaddrEntry 1 ) IP (ipaddrEntry 2) IP (ipaddrEntry 3)
| | |
| | |
| | proprietary protocol
| | layer (ifIndex 3)
| | |
| | |
DLCI 20 DLCI 30 DLCI 40/41/42
(ifIndex 2) (ifIndex 2) (ifIndex 2,
logical ifIndex 3)
| | |
| | |
|____________________|_____________________|
|
|
FR DLMCI (ifIndex.2)
|
|
Physical Interface (ifIndex.1)Now, a configuration where DLCIs 40, 41, and 42 are associated with a proprietary protocol layer, while DLCIs 20 and 30 run IP directly, can be expressed using a combo of frCircuitIfIndex and frCircuitLogicalIfIndex 💜. In that case, DLCIs 40, 41, and 42 use frCircuitIfIndex equal to the frame relay interface level (2), while their frCircuitLogicalIfIndex indicates the proprietary protocol (3) 🌸. DLCIs 20 and 30 have both instances set to the frame relay interface (2) ✨.
Object Meaning for Frame Relay Interface
______ _____________________________________
ifDescr As per DESCRIPTION in RFC 1573.
ifType The value allocated for Frame Relay
Interfaces - frameRelay (32).
ifMtu Set to maximum frame size in octets for
this frame relay interface.
ifSpeed The access rate for the frame relay
interface. This could be different from
the speed of the underlying physical
interface, e.g. in a fractional T1 case
the access rate could be 384 kbits/s (the
value reported in this object) whereas the
speed of the underlying interface would be
1.544 Mbits/s (the value reported in the
instance of ifSpeed for the ifEntry with
type ds1).
ifPhysAddress The primary address for this interface
assigned by the Frame Relay interface
provider. An octet string of zero length
if no address is used for this interface.
ifAdminStatus As per DESCRIPTION in RFC 1573.
ifOperStatus As per DESCRIPTION in RFC 1573.
ifLastChange As per DESCRIPTION in RFC 1573.
ifInOctets The number of received octets. This
includes not only the information field
(user data) but also the frame relay header
and CRC.
ifInUcastPkts The number of frames received on non-
multicast DLCIs
ifInDiscards The number of frames that were successfully
received but were discarded because of
format errors or because the VC was not
known. Format errors, in this case, are
any errors which would prevent the system
from recognizing the DLCI and placing the
error in the frCircuitDiscard category.
ifInErrors The number of received frames that are
discarded, because of an error.
Possible errors can be the following: the
frame relay frames were too long or were
too short, the frames had an invalid or
unrecognized DLCI values, or incorrect
header values.
ifInUnknownProtos Number of unknown or unsupported
upper layer protocol frames received
and discarded.
ifOutOctets The number of received octets. This
includes not only the information field
(user data) but also the frame relay header
and CRC.
ifOutUcastpkts The number of frames sent.
ifOutDiscards The number of frames discarded in the
transmit direction.
ifOutErrors The number of frames discarded in the
egress direction, because of errors.
ifName As per DESCRIPTION in RFC 1573.
ifInMulticastPkts The number of unerrored frames received
on a multicast DLCI.
ifInBroadcastPkts Always zero (0) as there are no broadcast
frames.
ifOutMulticastPkts The number of frames transmitted over a
multicast DLCI.
ifOutBroadcastPkts Always zero (0) as there are no broadcast
frames.
ifHCInOctets Only required when ifSpeed >= 155 Mbits/s.
See
details for ifInOctets.
ifHCOutOctets Only required when ifSpeed >= 155 Mbits/s.
See
details for ifInOctets.
ifLinkUpDownTrapEnble As per DESCRIPTION in RFC 1573.
ifHighSpeed The access rate of the frame relay interface
measured in Mbits/s. If the access rate is
less than 1 Mbits/s, this object returns 0.
ifPromiscuousMode Set to false(2).
ifConnectorPresent Set to false(2).4.2. Textual Conventions
This MIB document introduces one new data type as a textual convention 🧁. It's there to make the spec easier to read and to make comparing it with other specs easier where that fits 💅. The introduction of this textual convention has no effect on the syntax or the semantics of any managed objects 🙈. It's purely an artifact of the explanatory method. Objects defined using one of these conventions are always encoded using the rules that define the primitive type 🫶. So no changes to the SMI or the SNMP are needed to accommodate this textual convention, which is only adopted for the convenience of readers and writers chasing the elusive goal of clear, concise, and unambiguous MIB documents ✨.
The new data type is DLCI 🦋. DLCI refers to the range 0..DLCINumber and is used to refer to the valid Data Link Connection Indices 💜. DLCINumber is, by definition, the largest possible DLCI value under the configured Q.922 Address Format 👑.
4.3. Structure of MIB ✨
okay so the MIB is made of three groups 💅. One is for the DLCMI (Data Link Connection Management Interface), one is for the Circuits, and the last one is for errors. Frame Relay virtual circuits get added, deleted, and change availability all the time, and the network manager really needs to know when that happens 👀, so there's one trap for it. It's basically the Frame Relay cousin of the SNMP "Link Up" and "Link Down" traps 🦋.
5. Changes from RFC 1315 🎀
here's what changed from the last version of this doc, which was RFC 1315 💖:
- The MIB module went from SMIv1 to SMIv2 format. Heads up, this means the table indices now have access of "read-only" instead of "not-accessible", which is the usual value for index objects in SMIv2 🙈.
- The module name went from RFC1315-MIB to FRAME-RELAY-DTE-MIB 🧚.
- The textual convention "Index" got dropped from the MIB module, and "InterfaceIndex" from the interfaces MIB module, IF-MIB, is used in its place 💅.
- Objects frDlcmiStatus and frDlcmiRowStatus were added to table frDlcmiTable ✨.
- Values "itut933A(5)" (from CCITT Q933 Annex A) and "ansiT1617D1994(6)" (from ANSI T1.617a-1994 Annex D) were added to the enumerations for object frDlcmiState 🔥.
- The labels for the enumerated values of object frDlcmiAddressLen got renamed to remove their hyphens, because SMIv2 requires it 🌸.
- It's now clarified that the "management virtual circuit" (i.e. DLCI 0) is a member of the circuit table 🦋.
- These objects were added to table frCircuitTable: frCircuitMulticast, frCircuitType, frCircuitDiscards, frCircuitReceivedDEs, frCircuitSentDEs, frCircuitLogicalIfIndex, and frCircuitRowStatus 💖.
- The definition of object frCircuitReceivedOctets got clarified about which octets get counted 🫶.
- Objects frErrFaults and frErrFaultTime were added to table frErrTable 🌈.
- There's now clarification on the values of object frErrType 💜.
- Object frErrData got a size on its definition, and it's clarified what data to capture 🍓.
- The identifier for OID value { frameDelayDTE 4 } changed from frame-relay-globals to frameRelayTrapControl 👑.
- Object frTrapMaxRate was added ⭐.
- These object groups were created: frPortGroup, frCircuitGroup, frTrapGroup, frErrGroup, frPortGroup0, frCircuitGroup0, frTrapGroup0, and frErrGroup0 🎀.
- Notification group frNotificationGroup was created 🔥.
- Module compliances frCompliance and frCompliance0 were created 💅.
- Ranges were added to objects frCircuitCommittedBurst, frCircuitExcessBurst, and frCircuitThroughput ✨.
6. Definitions 💅
here's the MIB module itself, copied exactly 🫶:
FRAME-RELAY-DTE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32,
Integer32, NOTIFICATION-TYPE FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, TimeStamp FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF
transmission FROM RFC1213-MIB
InterfaceIndex FROM IF-MIB;
-- Frame Relay DTE MIB
frameRelayDTE MODULE-IDENTITY
LAST-UPDATED "9705010229Z" -- Thu May 1 02:29:46 PDT 1997
ORGANIZATION "IETF IPLPDN Working Group"
CONTACT-INFO
" Caralyn Brown
Postal: Cadia Networks, Inc.
1 Corporate Drive
Andover, Massachusetts 01810
Tel: +1 508 689 2400 x133
E-Mail: cbrown@cadia.com
Fred Baker
Postal: Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Tel: +1 408 526 425
E-Mail: fred@cisco.com"
DESCRIPTION
"The MIB module to describe the use of a Frame Relay
interface by a DTE."
REVISION "9705010229Z" -- Thu May 1 02:29:46 PDT 1997
DESCRIPTION
"Converted from SMIv1 to SMIv2. (Thus, indices are
read-only rather than being not-accessible.) Added
objects and made clarifications based on implementation
experience."
REVISION "9204010000Z"
DESCRIPTION
"Published as RFC 1315, the initial version of this MIB
module."
::= { transmission 32 }
--
-- the range of a Data Link Connection Identifier
--
DLCI ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The range of DLCI values. Note that this varies by
interface configuration; normally, interfaces may use
0..1023, but may be configured to use ranges as large
as 0..2^23."
SYNTAX Integer32(0..8388607)
--
-- Data Link Connection Management Interface
-- The variables that configure the DLC Management Interface.
frDlcmiTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrDlcmiEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Parameters for the Data Link Connection Management
Interface for the frame relay service on this
interface."
REFERENCE
"American National Standard T1.617-1991, Annex D"
::= { frameRelayDTE 1 }
frDlcmiEntry OBJECT-TYPE
SYNTAX FrDlcmiEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Parameters for a particular Data Link Connection
Management Interface."
INDEX { frDlcmiIfIndex }
::= { frDlcmiTable 1 }
FrDlcmiEntry ::=
SEQUENCE {
frDlcmiIfIndex InterfaceIndex,
frDlcmiState INTEGER,
frDlcmiAddress INTEGER,
frDlcmiAddressLen INTEGER,
frDlcmiPollingInterval Integer32,
frDlcmiFullEnquiryInterval Integer32,
frDlcmiErrorThreshold Integer32,
frDlcmiMonitoredEvents Integer32,
frDlcmiMaxSupportedVCs DLCI,
frDlcmiMulticast INTEGER,
frDlcmiStatus INTEGER,
frDlcmiRowStatus RowStatus
}
frDlcmiIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex value of the corresponding ifEntry."
::= { frDlcmiEntry 1 }
frDlcmiState OBJECT-TYPE
SYNTAX INTEGER {
noLmiConfigured (1),
lmiRev1 (2),
ansiT1617D (3), -- ANSI T1.617 Annex D
ansiT1617B (4), -- ANSI T1.617 Annex B
itut933A (5), -- CCITT Q933 Annex A
ansiT1617D1994 (6) -- ANSI T1.617a-1994 Annex D
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable states which Data Link Connection
Management scheme is active (and by implication, what
DLCI it uses) on the Frame Relay interface."
REFERENCE
"American National Standard T1.617-1991, American
National Standard T1.617a-1994, ITU-T Recommendation
Q.933 (03/93)."
::= { frDlcmiEntry 2 }
frDlcmiAddress OBJECT-TYPE
SYNTAX INTEGER {
q921 (1), -- 13 bit DLCI
q922March90 (2), -- 11 bit DLCI
q922November90 (3), -- 10 bit DLCI
q922 (4) -- Final Standard
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable states which address format is in use on
the Frame Relay interface."
::= { frDlcmiEntry 3 }
frDlcmiAddressLen OBJECT-TYPE
SYNTAX INTEGER {
twoOctets (2),
threeOctets (3),
fourOctets (4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable states the address length in octets. In
the case of Q922 format, the length indicates the
entire length of the address including the control
portion."
::= { frDlcmiEntry 4 }
frDlcmiPollingInterval OBJECT-TYPE
SYNTAX Integer32 (5..30)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is the number of seconds between successive
status enquiry messages."
REFERENCE
"American National Standard T1.617-1991, Section D.7
Timer T391."
DEFVAL { 10 }
::= { frDlcmiEntry 5 }
frDlcmiFullEnquiryInterval OBJECT-TYPE
SYNTAX Integer32 (1..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Number of status enquiry intervals that pass before
issuance of a full status enquiry message."
REFERENCE
"American National Standard T1.617-1991, Section D.7
Counter N391."
DEFVAL { 6 }
::= { frDlcmiEntry 6 }
frDlcmiErrorThreshold OBJECT-TYPE
SYNTAX Integer32 (1..10)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is the maximum number of unanswered Status
Enquiries the equipment shall accept before declaring
the interface down."
REFERENCE
"American National Standard T1.617-1991, Section D.5.1
Counter N392."
DEFVAL { 3 }
::= { frDlcmiEntry 7 }
frDlcmiMonitoredEvents OBJECT-TYPE
SYNTAX Integer32 (1..10)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is the number of status polling intervals over
which the error threshold is counted. For example, if
within 'MonitoredEvents' number of events the station
receives 'ErrorThreshold' number of errors, the
interface is marked as down."
REFERENCE
"American National Standard T1.617-1991, Section D.5.2
Counter N393."
DEFVAL { 4 }
::= { frDlcmiEntry 8 }
frDlcmiMaxSupportedVCs OBJECT-TYPE
SYNTAX DLCI
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum number of Virtual Circuits allowed for
this interface. Usually dictated by the Frame Relay
network.
In response to a SET, if a value less than zero or
higher than the agent's maximal capability is
configured, the agent should respond badValue"
::= { frDlcmiEntry 9 }
frDlcmiMulticast OBJECT-TYPE
SYNTAX INTEGER {
nonBroadcast (1),
broadcast (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This indicates whether the Frame Relay interface is
using a multicast service."
::= { frDlcmiEntry 10 }okay so we're still deep in the Definitions bestie 🎀 and this part is all about the frDlcmi bits and the whole circuit table 💅 the MIB is literally the blueprint, so every single line matters 🫶
frDlcmiStatus OBJECT-TYPE
SYNTAX INTEGER {
running (1), -- init complete, system running
fault (2), -- error threshold exceeded
initializing (3) -- system start up
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the status of the Frame Relay interface
as determined by the performance of the dlcmi. If no
dlcmi is running, the Frame Relay interface will stay
in the running state indefinitely."
::= { frDlcmiEntry 11 }
frDlcmiRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"SNMP Version 2 Row Status Variable. Writable objects
in the table may be written in any RowStatus state."
::= { frDlcmiEntry 12 }
--
-- A Frame Relay service is a multiplexing service. Data
-- Link Connection Identifiers enumerate virtual circuits
-- (permanent or dynamic) which are layered onto the underlying
-- circuit, represented by ifEntry. Therefore, each of the entries
-- in the Standard MIB's Interface Table with an IfType of
-- Frame Relay represents a Q.922 interface. Zero or more
-- virtual circuits are layered onto this interface and provide
-- interconnection with various remote destinations.
-- Each such virtual circuit is represented by an entry in the
-- circuit table. The management virtual circuit (i.e. DLCI 0)
-- is a virtual circuit by this definition and will be represented
-- with an entry in the circuit table.
-- Circuit Table
-- The table describing the use of the DLCIs attached to
-- each Frame Relay Interface.
frCircuitTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about specific Data
Link Connections (DLC) or virtual circuits."
::= { frameRelayDTE 2 }
frCircuitEntry OBJECT-TYPE
SYNTAX FrCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The information regarding a single Data Link
Connection. Discontinuities in the counters contained
in this table are indicated by the value in
frCircuitCreationTime."
INDEX { frCircuitIfIndex, frCircuitDlci }
::= { frCircuitTable 1 }okay the table is giving main character energy 👑 each row is one Data Link Connection and the index is frCircuitIfIndex plus frCircuitDlci 🦋
FrCircuitEntry ::=
SEQUENCE {
frCircuitIfIndex InterfaceIndex,
frCircuitDlci DLCI,
frCircuitState INTEGER,
frCircuitReceivedFECNs Counter32,
frCircuitReceivedBECNs Counter32,
frCircuitSentFrames Counter32,
frCircuitSentOctets Counter32,
frCircuitReceivedFrames Counter32,
frCircuitReceivedOctets Counter32,
frCircuitCreationTime TimeStamp,
frCircuitLastTimeChange TimeStamp,
frCircuitCommittedBurst Integer32,
frCircuitExcessBurst Integer32,
frCircuitThroughput Integer32,
frCircuitMulticast INTEGER,
frCircuitType INTEGER,
frCircuitDiscards Counter32,
frCircuitReceivedDEs Counter32,
frCircuitSentDEs Counter32,
frCircuitLogicalIfIndex InterfaceIndex,
frCircuitRowStatus RowStatus
}
frCircuitIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex Value of the ifEntry this virtual circuit
is layered onto."
::= { frCircuitEntry 1 }
frCircuitDlci OBJECT-TYPE
SYNTAX DLCI
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Data Link Connection Identifier for this virtual
circuit."
REFERENCE
"American National Standard T1.618-1991, Section 3.3.6"
::= { frCircuitEntry 2 }okay now the state, which is honestly so iconic 💖 it can be active, inactive or invalid, and the 'invalid' option is deprecated in favour of frCircuitRowStatus 🙈
frCircuitState OBJECT-TYPE
SYNTAX INTEGER {
invalid (1),
active (2),
inactive (3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates whether the particular virtual circuit is
operational. In the absence of a Data Link Connection
Management Interface, virtual circuit entries (rows)
may be created by setting virtual circuit state to
'active', or deleted by changing Circuit state to
'invalid'.
Whether or not the row actually disappears is left to
the implementation, so this object may actually read as
'invalid' for some arbitrary length of time. It is
also legal to set the state of a virtual circuit to
'inactive' to temporarily disable a given circuit.
The use of 'invalid' is deprecated in this SNMP Version
2 MIB, in favor of frCircuitRowStatus."
DEFVAL { active }
::= { frCircuitEntry 3 }
frCircuitReceivedFECNs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of frames received from the network indicating
forward congestion since the virtual circuit was
created. This occurs when the remote DTE sets the FECN
flag, or when a switch in the network enqueues the
frame to a trunk whose transmission queue is
congested."
REFERENCE
"American National Standard T1.618-1991, Section 3.3.3"
::= { frCircuitEntry 4 }
frCircuitReceivedBECNs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of frames received from the network indicating
backward congestion since the virtual circuit was
created. This occurs when the remote DTE sets the BECN
flag, or when a switch in the network receives the
frame from a trunk whose transmission queue is
congested."
REFERENCE
"American National Standard T1.618-1991, Section 3.3.4"
::= { frCircuitEntry 5 }the counters next, and they're all read-only so nobody's messing with them 🔥
frCircuitSentFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of frames sent from this virtual circuit
since it was created."
::= { frCircuitEntry 6 }
frCircuitSentOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets sent from this virtual circuit
since it was created. Octets counted are the full
frame relay header and the payload, but do not include
the flag characters or CRC."
::= { frCircuitEntry 7 }
frCircuitReceivedFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of frames received over this virtual circuit
since it was created."
::= { frCircuitEntry 8 }
frCircuitReceivedOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of octets received over this virtual circuit
since it was created. Octets counted include the full
frame relay header, but do not include the flag
characters or the CRC."
::= { frCircuitEntry 9 }
frCircuitCreationTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the virtual circuit was
created, whether by the Data Link Connection Management
Interface or by a SetRequest."
::= { frCircuitEntry 10 }
frCircuitLastTimeChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when last there was a change in
the virtual circuit state"
::= { frCircuitEntry 11 }and now the burst and throughput bits, which are a whole vibe 🌸 the measurement interval T depends on which values are set, so read those formulas carefully bestie ✨
frCircuitCommittedBurst OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the maximum amount of data, in
bits, that the network agrees to transfer under normal
conditions, during the measurement interval."
REFERENCE
"American National Standard T1.617-1991, Section
6.5.19"
DEFVAL { 0 } -- the default indicates no commitment
::= { frCircuitEntry 12 }
frCircuitExcessBurst OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the maximum amount of
uncommitted data bits that the network will attempt to
deliver over the measurement interval.
By default, if not configured when creating the entry,
the Excess Information Burst Size is set to the value
of ifSpeed."
REFERENCE
"American National Standard T1.617-1991, Section
6.5.19"
::= { frCircuitEntry 13 }
frCircuitThroughput OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Throughput is the average number of 'Frame Relay
Information Field' bits transferred per second across a
user network interface in one direction, measured over
the measurement interval.
If the configured committed burst rate and throughput
are both non-zero, the measurement interval, T, is
T=frCircuitCommittedBurst/frCircuitThroughput.
If the configured committed burst rate and throughput
are both zero, the measurement interval, T, is
T=frCircuitExcessBurst/ifSpeed."
REFERENCE
"American National Standard T1.617-1991, Section
6.5.19"
DEFVAL {0} -- the default value of Throughput is
-- "no commitment".
::= { frCircuitEntry 14 }last one in this bit is frCircuitMulticast, which says whether a VC is unicast or which kind of multicast it's signed up for 🦋 the default is unicast, so it's a normal VC unless you say otherwise 💜
frCircuitMulticast OBJECT-TYPE
SYNTAX INTEGER {
unicast (1),
oneWay (2),
twoWay (3),
nWay (4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This indicates whether this VC is used as a unicast VC
(i.e. not multicast) or the type of multicast service
subscribed to"
REFERENCE
"Frame Relay PVC Multicast Service and Protocol
Description Implementation: FRF.7 Frame Relay Forum
Technical Committe October 21, 1994"
DEFVAL {unicast}
-- the default value of frCircuitMulticast is
-- "unicast" (not a multicast VC).
::= { frCircuitEntry 15 }we're cooking 🍓 keep going and the rest of the circuit table is coming up next 🧚
frCircuitType OBJECT-TYPE SYNTAX INTEGER { static (1), dynamic (2) }
MAX-ACCESS read-only STATUS current DESCRIPTION "Indication of whether the VC was manually created (static), or dynamically created (dynamic) via the data link control management interface." ::= { frCircuitEntry 16 }
frCircuitDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound frames dropped because of format errors, or because the VC is inactive." ::= { frCircuitEntry 17 }
frCircuitReceivedDEs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames received from the network indicating that they were eligible for discard since the virtual circuit was created. This occurs when the remote DTE sets the DE flag, or when in remote DTE's switch detects that the frame was received as Excess Burst data." REFERENCE "American National Standard T1.618-1991, Section 3.3.4" ::= { frCircuitEntry 18 }
frCircuitSentDEs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of frames sent to the network indicating that they were eligible for discard since the virtual circuit was created. This occurs when the local DTE sets the DE flag, indicating that during Network congestion situations those frames should be discarded in preference of other frames sent without the DE bit set." REFERENCE
"American National Standard T1.618-1991, Section 3.3.4" ::= { frCircuitEntry 19 }
frCircuitLogicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "Normally the same value as frDlcmiIfIndex, but different when an implementation associates a virtual ifEntry with a DLC or set of DLCs in order to associate higher layer objects such as the ipAddrEntry with a subset of the virtual circuits on a Frame Relay interface. The type of such ifEntries is defined by the higher layer object; for example, if PPP/Frame Relay is implemented, the ifType of this ifEntry would be PPP. If it is not so defined, as would be the case with an ipAddrEntry, it should be of type Other." ::= { frCircuitEntry 20 }
frCircuitRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or destroy an existing row in the manner described in the definition of the RowStatus textual convention. Writable objects in the table may be written in any RowStatus state." ::= { frCircuitEntry 21 }
-- -- Error Table
-- The table describing errors encountered on each Frame -- Relay Interface.
frErrTable OBJECT-TYPE SYNTAX SEQUENCE OF FrErrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about Errors on the Frame Relay interface. Discontinuities in the counters contained in this table are the same as apply to the ifEntry associated with the Interface." ::= { frameRelayDTE 3 }
frErrEntry OBJECT-TYPE SYNTAX FrErrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The error information for a single frame relay interface." INDEX { frErrIfIndex } ::= { frErrTable 1 }
FrErrEntry ::= SEQUENCE { frErrIfIndex InterfaceIndex, frErrType INTEGER, frErrData OCTET STRING, frErrTime TimeStamp, frErrFaults Counter32, frErrFaultTime TimeStamp }
frErrIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex Value of the corresponding ifEntry." ::= { frErrEntry 1 }
frErrType OBJECT-TYPE SYNTAX INTEGER { unknownError(1), receiveShort(2), receiveLong(3), illegalAddress(4), unknownAddress(5), dlcmiProtoErr(6), dlcmiUnknownIE(7), dlcmiSequenceErr(8), dlcmiUnknownRpt(9), noErrorSinceReset(10) }
MAX-ACCESS read-only STATUS current DESCRIPTION "The type of error that was last seen on this interface:
receiveShort: frame was not long enough to allow demultiplexing - the address field was incomplete, or for virtual circuits using Multiprotocol over Frame Relay, the protocol identifier was missing or incomplete.
receiveLong: frame exceeded maximum length configured for this interface.
illegalAddress: address field did not match configured format.
unknownAddress: frame received on a virtual circuit which was not active or administratively disabled.
dlcmiProtoErr: unspecified error occurred when attempting to interpret link maintenance frame.
dlcmiUnknownIE: link maintenance frame contained an Information Element type which is not valid for the configured link maintenance protocol.
dlcmiSequenceErr: link maintenance frame contained a sequence number other than the expected value.
dlcmiUnknownRpt: link maintenance frame contained a Report Type Information Element whose value was not valid for the configured link maintenance protocol.
noErrorSinceReset: no errors have been detected since the last cold start or warm start." ::= { frErrEntry 2 }
frErrData OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..1600)) MAX-ACCESS read-only STATUS current DESCRIPTION "An octet string containing as much of the error packet as possible. As a minimum, it must contain the Q.922 Address or as much as was delivered. It is desirable to include all header and demultiplexing information." ::= { frErrEntry 3 }
frErrTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at which the error was detected." ::= { frErrEntry 4 }
frErrFaults OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the interface has gone down since it was initialized." ::= { frErrEntry 5 }
frErrFaultTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time when the interface was taken down due to excessive errors. Excessive errors is defined as the time when a DLCMI exceeds the frDlcmiErrorThreshold number of errors within frDlcmiMonitoredEvents. See FrDlcmiEntry for further details." ::= { frErrEntry 6 }
--
-- Frame Relay Trap Control
frameRelayTrapControl OBJECT IDENTIFIER ::= { frameRelayDTE 4 }
-- the following highly unusual OID is as it is for compatibility -- with RFC 1315, the SNMP V1 predecessor of this document. frameRelayTraps OBJECT IDENTIFIER ::= { frameRelayDTE 0 } frTrapState OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates whether the system produces the frDLCIStatusChange trap." DEFVAL { disabled } ::= { frameRelayTrapControl 1 }
frTrapMaxRate OBJECT-TYPE SYNTAX Integer32 (0..3600000) MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the number of milliseconds that must elapse between trap emissions. If events occur more rapidly, the impementation may simply fail to trap, or may queue traps until an appropriate time." DEFVAL { 0 } -- no minimum elapsed period is specified ::= { frameRelayTrapControl 2 }
-- Data Link Connection Management Interface Related Traps
frDLCIStatusChange NOTIFICATION-TYPE OBJECTS { frCircuitState } STATUS current
DESCRIPTION "This trap indicates that the indicated Virtual Circuit has changed state. It has either been created or invalidated, or has toggled between the active and inactive states. If, however, the reason for the state change is due to the DLCMI going down, per-DLCI traps should not be generated." ::= { frameRelayTraps 1 } -- conformance information
frConformance OBJECT IDENTIFIER ::= { frameRelayDTE 6 }
frGroups OBJECT IDENTIFIER ::= { frConformance 1 } frCompliances OBJECT IDENTIFIER ::= { frConformance 2 }
-- compliance statements frCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { frPortGroup, frCircuitGroup }
GROUP frErrGroup DESCRIPTION "This optional group is used for debugging Frame Relay Systems."
GROUP frTrapGroup DESCRIPTION "This optional group is used for the management of asynchronous notifications by Frame Relay Systems."
GROUP frNotificationGroup DESCRIPTION "This optional group defines the asynchronous notifications generated by Frame Relay Systems."
OBJECT frDlcmiRowStatus MIN-ACCESS read-only DESCRIPTION "Row creation is not required for the frDlcmiTable."
OBJECT frCircuitRowStatus
MIN-ACCESS read-only DESCRIPTION "Row creation is not required for the frCircuitTable."
::= { frCompliances 1 }
frCompliance0 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for objects and the trap defined in RFC 1315." MODULE -- this module MANDATORY-GROUPS { frPortGroup0, frCircuitGroup0 }
GROUP frErrGroup0 DESCRIPTION "This optional group is used for debugging Frame Relay Systems."
GROUP frTrapGroup0 DESCRIPTION "This optional group is used for the management of asynchronous notifications by Frame Relay Systems."
Okay bestie, the MIB definitions are wrapping up, so here's the rest of the module, verbatim, because the object names have to match exactly 💅
GROUP frNotificationGroup
DESCRIPTION
"This optional group defines the asynchronous
notifications generated by Frame Relay Systems."
::= { frCompliances 2 }
-- units of conformance
frPortGroup OBJECT-GROUP
OBJECTS {
frDlcmiIfIndex, frDlcmiState, frDlcmiAddress,
frDlcmiAddressLen, frDlcmiPollingInterval,
frDlcmiFullEnquiryInterval, frDlcmiErrorThreshold,
frDlcmiMonitoredEvents, frDlcmiMaxSupportedVCs,
frDlcmiMulticast, frDlcmiStatus, frDlcmiRowStatus
}
STATUS current
DESCRIPTION
"The objects necessary to control the Link Management
Interface for a Frame Relay Interface as well as
maintain the error statistics on this interface."
::= { frGroups 1 }
frCircuitGroup OBJECT-GROUP
OBJECTS {
frCircuitIfIndex, frCircuitDlci, frCircuitState,
frCircuitReceivedFECNs, frCircuitReceivedBECNs,
frCircuitSentFrames, frCircuitSentOctets,
frCircuitReceivedFrames, frCircuitReceivedOctets,
frCircuitCreationTime, frCircuitLastTimeChange,
frCircuitCommittedBurst, frCircuitExcessBurst,
frCircuitThroughput, frCircuitMulticast,
frCircuitType, frCircuitDiscards,
frCircuitReceivedDEs, frCircuitSentDEs,
frCircuitLogicalIfIndex, frCircuitRowStatus
}
STATUS current
DESCRIPTION
"The objects necessary to control the Virtual Circuits
layered onto a Frame Relay Interface."
::= { frGroups 2 }
frTrapGroup OBJECT-GROUP
OBJECTS { frTrapState, frTrapMaxRate }
STATUS current
DESCRIPTION
"The objects necessary to control a Frame Relay
Interface's notification messages."
::= { frGroups 3 }
frErrGroup OBJECT-GROUP
OBJECTS {
frErrIfIndex, frErrType, frErrData, frErrTime,
frErrFaults, frErrFaultTime
}
STATUS current
DESCRIPTION
"Objects designed to assist in debugging Frame Relay
Interfaces."
::= { frGroups 4 }
frNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { frDLCIStatusChange }
STATUS current
DESCRIPTION
"Traps which may be used to enhance event driven
management of the interface."
::= { frGroups 5 }
frPortGroup0 OBJECT-GROUP
OBJECTS {
frDlcmiIfIndex, frDlcmiState, frDlcmiAddress,
frDlcmiAddressLen, frDlcmiPollingInterval,
frDlcmiFullEnquiryInterval, frDlcmiErrorThreshold,
frDlcmiMonitoredEvents, frDlcmiMaxSupportedVCs,
frDlcmiMulticast
}
STATUS current
DESCRIPTION
"The objects necessary to control the Link Management
Interface for a Frame Relay Interface as well as
maintain the error statistics on this interface from
RFC 1315."
::= { frGroups 6 }
frCircuitGroup0 OBJECT-GROUP
OBJECTS {
frCircuitIfIndex, frCircuitDlci, frCircuitState,
frCircuitReceivedFECNs, frCircuitReceivedBECNs,
frCircuitSentFrames, frCircuitSentOctets,
frCircuitReceivedFrames, frCircuitReceivedOctets,
frCircuitCreationTime, frCircuitLastTimeChange,
frCircuitCommittedBurst, frCircuitExcessBurst,
frCircuitThroughput
}
STATUS current
DESCRIPTION
"The objects necessary to control the Virtual Circuits
layered onto a Frame Relay Interface from RFC 1315."
::= { frGroups 7 }
frErrGroup0 OBJECT-GROUP
OBJECTS {
frErrIfIndex, frErrType, frErrData, frErrTime
}
STATUS current
DESCRIPTION
"Objects designed to assist in debugging Frame Relay
Interfaces from RFC 1315."
::= { frGroups 8 }
frTrapGroup0 OBJECT-GROUP
OBJECTS { frTrapState }
STATUS current
DESCRIPTION
"The objects necessary to control a Frame Relay
Interface's notification messages from RFC 1315."
::= { frGroups 9 }
END7. Security Issues ✨
Okay, this one's short but it's a big deal 🔒 Security for this MIB is entirely covered by the SNMP Security Architecture, so it hasn't been expanded inside the contents of this MIB at all. 🫶
8. Acknowledgments 🌸
This document was originally produced by the IP Over Large Public Data Networks (IPLPDN) Working Group, and has since been carried on in the PPP Working Group, sort of. Currently, the Ion Working Group is its host. 🦋
Special thanks to James Watt of Newbridge Networks for his fine suggestions and pastable text. 💜
9. Authors' Addresses 💖
The authors, with their contact details exactly as they appear in the original:
Caralyn Brown
Cadia Networks, Inc.
1 Corporate Dirve
Andover, Massachusetts 01810
Telephone: +1 508 689 2400 x133
E-Mail: cbrown@cadia.com
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Telephone +1 408 526 4257
E-Mail: fred@cisco.com10. References 📚
Here are all ten references, word for word:
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Structure of Management Information
for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1902, January 1996.
[2] McCloghrie, K., and M. Rose, Editors, "Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems,
Performance Systems International, March 1991.
[3] Case, J., Fedor, M., Schoffstall, M., and J. Davin. " A
Simple Network Management Protocol (SNMP)", STD 15, RFC
1157, SNMP Research, Performance Systems International,
MIT Lab for Computer Science, May 1990.
[4] SNMPv2 Working Group, 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.
[5] McCloghrie, K. and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC 1573, Hughes LAN
Systems, FTP Software, January 1994.
[6] T. Bradley, C. Brown, A. Malis, "Multiprotocol
Interconnect over Frame Relay", RFC 1490, 07/26/1993.
[7] International Telegraph and Telephone Consultative
Committee, "ISDN Data Link Layer Specification for Frame
Mode Bearer Services", CCITT Recommendation Q.922, 19
April 1991.
[8] American National Standard For Telecommunications -
Integrated Services Digital Network - Frame Relay Bearer
Service - Architectural Framework and Service
Description, ANSI T1.606-1991, 18 June 1991.
[9] American National Standard For Telecommunications -
Integrated Services Digital Network - Digital Subscriber
Signalling System No. 1 - Signaling Specification for
Frame Relay Bearer Service, ANSI T1.617-1991, 18 June
1991.
[10] American National Standard For Telecommunications -
Integrated Services Digital Network - Core Aspects of
Frame Protocol for Use with Frame Relay Bearer Service,
ANSI T1.618-1991, 18 June 1991.📦 where this page comes from
- ietf: rfc2115 1997-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms