summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2115.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2115.txt')
-rw-r--r--doc/rfc/rfc2115.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc2115.txt b/doc/rfc/rfc2115.txt
new file mode 100644
index 0000000..4e64518
--- /dev/null
+++ b/doc/rfc/rfc2115.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group C. Brown
+Request for Comments: 2115 Cadia Networks, Inc.
+Obsoletes: 1315 F. Baker
+Category: Standards Track Cisco Systems
+ September 1997
+
+
+
+ Management Information Base for Frame Relay DTEs
+ Using SMIv2
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+
+2. Abstract
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in TCP/IP- based internets.
+ In particular, 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 ........................................... 31
+
+
+
+
+
+Brown & Baker Standards Track [Page 1]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+3. The SNMPv2 Network Management Framework
+
+ The major components of the SNMPv2 Network Management framework are
+ described in the documents listed below.
+
+ o RFC 1902 [1] defines the Structure of Management
+ Information (SMI), the mechanisms used for describing and
+ naming objects for the purpose of management.
+
+ o STD 17, RFC 1213 [2] defines MIB-II, the core set of
+ managed objects (MO) for the Internet suite of protocols.
+
+ o RFC 1905 [3] defines the protocol used for network access
+ to managed objects.
+
+ The framework is adaptable/extensible by defining new MIBs to suit
+ the requirements of specific applications/protocols/situations.
+
+ Managed objects are accessed via a virtual information store, the
+ MIB. Objects in the MIB are defined using the subset of Abstract
+ Syntax Notation One (ASN.1) defined in the SMI. In particular, each
+ object type is named by an OBJECT IDENTIFIER, which is an
+ administratively assigned name. The object type together with an
+ object instance serves to uniquely identify a specific instantiation
+ of the object. For human convenience, often a textual string, termed
+ the descriptor, is used to refer to the object type.
+
+4. Overview
+
+4.1. Frame Relay Operational Model
+
+ For the purposes of understanding this document, Frame Relay is
+ viewed as a multi-access media, not as a group of point- to-point
+ connections. This model proposes that Frame Relay is a single
+ interface to the network (physical connection) with many destinations
+ or neighbors (virtual connections). This view enables a network
+ manager the ability to group all virtual connections with their
+ corresponding physical connection thereby allowing simpler
+ diagnostics and trouble shooting.
+
+ With the extension of the interfaces MIB, it is possible to configure
+ frame relay DLCs as individual interfaces and create ifTable entries
+ for each. This is not recommended and is not directly supported by
+ this MIB. Additionally, in the presence of demand circuits creation
+ of individual ifEntries for each is not possible.
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 2]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ Should the user wish 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 provides an entry in the
+ frCircuitEntry record. For example, suppose one were to configure a
+ company proprietary protocol to run above several of the frame relay
+ VCs. The basic layering would look something like the following:
+
+ 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)
+
+
+
+A configuration which specified that DLCI 40, 41,and 42 were associated
+with a proprietary protocol layer, while DLCI 20 and 30 were to run IP
+directly can now be expressed using a combination of frCircuitIfIndex
+and frCircuitLogicalIfIndex. In this particular case DLCIs 40, 41 and
+42 would use frCircuitIfIndex equal to the frame relay interface level
+(2) while their frCircuitLogicalIfIndex would indicate the proprietary
+protocol (3). DLCIs 20 and 30 would 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.
+
+
+
+
+Brown & Baker Standards Track [Page 3]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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.
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 4]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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).
+
+
+
+Brown & Baker Standards Track [Page 5]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+4.2. Textual Conventions
+
+ One new data type is introduced as a textual convention in this MIB
+ document. This textual convention enhances the readability of the
+ specification and can ease comparison with other specifications if
+ appropriate. It should be noted that the introduction of this
+ textual conventions has no effect on either the syntax nor the
+ semantics of any managed objects. The use of this is merely an
+ artifact of the explanatory method used. Objects defined in terms of
+ one of these methods are always encoded by means of the rules that
+ define the primitive type. Hence, no changes to the SMI or the SNMP
+ are necessary to accommodate this textual conventions which is
+ adopted merely for the convenience of readers and writers in pursuit
+ of 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
+ possible under the configured Q.922 Address Format.
+
+4.3. Structure of MIB
+
+ The MIB is composed of three groups, one defining the Data Link
+ Connection Management Interface (DLCMI), one describing the Circuits,
+ and a third describing errors.
+
+ During normal operation, Frame Relay virtual circuits will be added,
+ deleted and change availability. The occurrence of such changes is of
+ interest to the network manager and therefore, one trap is defined,
+ intended to be corollary to the SNMP "Link Up" and "Link Down" traps.
+
+5. Changes from RFC 1315
+
+ Below are listed the changes from the previously published version
+ this document, which was RFC 1315:
+
+ o The MIB module was converted from SMIv1 to SMIv2 format.
+ Note: due to this, the table indices have access of
+ "read-only" instead of "not-accessible", which is the
+ typical value for index objects in SMIv2.
+
+ o The module name was changed from RFC1315-MIB to FRAME-
+ RELAY-DTE-MIB.
+
+ o The textual convention "Index" was dropped from the MIB
+ module and "InterfaceIndex" from the interfaces MIB
+ module, IF-MIB, was used in its place.
+
+
+
+Brown & Baker Standards Track [Page 6]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+ o Objects frDlcmiStatus and frDlcmiRowStatus were added to
+ table frDlcmiTable.
+
+ o Added values "itut933A(5)" (from CCITT Q933 Annex A) and
+ "ansiT1617D1994(6)" (from ANSI T1.617a-1994 Annex D) to
+ the enumerations for object frDlcmiState.
+
+ o The labels for the enumerated values for object
+ frDlcmiAddressLen were renamed to remove their hyphens as
+ required by SMIv2.
+
+ o Added clarification that the "management virtual circuit"
+ (i.e. DLCI 0) is a member of the circuit table.
+
+ o Added the following objects to table frCircuitTable:
+ frCircuitMulticast, frCircuitType, frCircuitDiscards,
+ frCircuitReceivedDEs, frCircuitSentDEs,
+ frCircuitLogicalIfIndex, and frCircuitRowStatus.
+
+ o The definition of object frCircuitReceivedOctets was
+ clarified as to which octets were counted.
+
+ o Added the objects frErrFaults and frErrFaultTime to table
+ frErrTable.
+
+ o Added clarification to the values of object frErrType.
+
+ o Added size on definition of object frErrData and
+ clarified what data to capture.
+
+ o Changed identififier for OID value { frameDelayDTE 4 }
+ from frame-relay-globals to frameRelayTrapControl.
+
+ o Added object frTrapMaxRate.
+
+
+ o Created object groups frPortGroup, frCircuitGroup,
+ frTrapGroup, frErrGroup, frPortGroup0, frCircuitGroup0,
+ frTrapGroup0, and frErrGroup0.
+
+ o Created notification group frNotificationGroup.
+
+ o Created module compliances frCompliance and
+ frCompliance0.
+
+ o Added ranges to objects frCircuitCommittedBurst,
+ frCircuitExcessBurst, and frCircuitThroughput.
+
+
+
+Brown & Baker Standards Track [Page 7]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+6. Definitions
+
+ 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 }
+
+
+
+Brown & Baker Standards Track [Page 8]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+
+ --
+ -- 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 }
+
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 9]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+
+Brown & Baker Standards Track [Page 10]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+
+ 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 }
+
+
+
+
+
+Brown & Baker Standards Track [Page 11]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 12]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+
+ 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 }
+
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 13]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 14]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+ 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 }
+
+
+
+
+Brown & Baker Standards Track [Page 15]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+ 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 }
+
+
+ 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 }
+
+
+
+
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 16]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+ 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
+
+
+
+Brown & Baker Standards Track [Page 17]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 18]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+ 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
+
+
+
+Brown & Baker Standards Track [Page 19]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ "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 }
+
+
+ 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 }
+
+
+ frCircuitType OBJECT-TYPE
+ SYNTAX INTEGER {
+ static (1),
+ dynamic (2)
+ }
+
+
+
+Brown & Baker Standards Track [Page 20]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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
+
+
+
+Brown & Baker Standards Track [Page 21]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ "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
+
+
+
+Brown & Baker Standards Track [Page 22]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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)
+ }
+
+
+
+
+Brown & Baker Standards Track [Page 23]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+
+
+Brown & Baker Standards Track [Page 24]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+
+
+ 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 }
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 25]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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
+
+
+
+
+Brown & Baker Standards Track [Page 26]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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."
+
+
+
+
+Brown & Baker Standards Track [Page 27]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ GROUP frTrapGroup0
+ 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."
+
+ ::= { 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 }
+
+
+
+
+Brown & Baker Standards Track [Page 28]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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,
+
+
+
+Brown & Baker Standards Track [Page 29]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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 }
+
+ END
+
+
+7. Security Issues
+
+ Security issues for this MIB are entirely covered by the SNMP
+ Security Architecture, and have not been expanded within the contents
+ of this MIB.
+
+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.
+
+
+
+Brown & Baker Standards Track [Page 30]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+9. Authors' Addresses
+
+ 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.com
+
+10. References
+
+ [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
+
+
+
+Brown & Baker Standards Track [Page 31]
+
+RFC 2115 Frame Relay DTE MIB September 1997
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Baker Standards Track [Page 32]
+