📄 rfc2115.txt
字号:
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,
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -