📄 rfc3201.txt
字号:
scheme.
ifType The value of ifType is specific to the type of circuit
desired. For example, the value for frame relay
virtual circuits is frDlciEndPt(193) and the value for
ATM virtual circuits is atmVciEndPt(194). If the
circuit is to be used in RMON, propVirtual(53) SHOULD
NOT be used.
Steinberger & Nicklass Standards Track [Page 6]
RFC 3201 Circuit to Interface MIB January 2002
ifMtu Set to the size in octets of the largest packet, frame
or PDU supported on the circuit. If this is not known
to the ifMtu object shall be set to zero. If the
circuit is not modeled as a packet-oriented interface,
this object SHOULD NOT be supported and result in
noSuchInstance.
ifSpeed The peak bandwidth in bits per second available for
use. This will equal either the ifSpeed of the
logical link if policing is not enforced or the
maximum information rate otherwise. If neither is
known, the ifSpeed object shall be set to zero.
ifPhysAddress This will always be an octet string of zero length.
ifInOctets The number of octets received by the network (ingress)
for this circuit. This counter should count only
octets included the header information and user data.
If the device does not support statistics on the
circuit, this object MUST NOT be supported and result
in noSuchInstance.
ifInUcastPkts The unerrored number of frames, packets or PDUs
received by the network (ingress) for this circuit.
If the device does not support statistics on the
circuit, this object MUST NOT be supported and result
in noSuchInstance.
ifInDiscards The number of received frames, packets or PDUs for
this circuit discarded due to ingress buffer
congestion and traffic policing. If the device does
not support statistics on the circuit, this object
MUST NOT be supported and result in noSuchInstance.
ifInErrors The number of received frames, packets or PDUs for
this circuit that are discarded because of an error.
If the device does not support statistics on the
circuit, this object MUST NOT be supported and result
in noSuchInstance.
ifOutOctets The number of octets sent by the network (egress) for
this circuit. This counter should count only octets
included the header information and user data. If the
device does not support statistics on the circuit,
this object MUST NOT be supported and result in
noSuchInstance.
Steinberger & Nicklass Standards Track [Page 7]
RFC 3201 Circuit to Interface MIB January 2002
ifOutUcastpkts The number of unerrored frames, packets or PDUs sent
by the network (egress) for this circuit. If the
device does not support statistics on the circuit,
this object MUST NOT be supported and result in
noSuchInstance.
ifOutDiscards The number of frames, packets or PDUs discarded in the
egress direction for this circuit. Possible reasons
are as follows: policing, congestion. If the device
does not support statistics on the circuit, this
object MUST NOT be supported and result in
noSuchInstance.
ifOutErrors The number of frames, packets or PDUs discarded for
this circuit in the egress direction because of an
error. If the device does not support statistics on
the circuit, this object MUST NOT be supported and
result in noSuchInstance.
ifInBroadcastPkts
If the device does not support statistics on the
circuit, this object MUST NOT be supported and result
in noSuchInstance.
ifOutBroadcastPkts
If the device does not support Broadcast packets on
the circuit, this object should not be supported and
result in noSuchInstance.
ifLinkUpDownTrapEnable
Set to false(2). Circuits often have a predefined
notification mechanism. In such instances, the number
of notification sent would be doubled if this were
enabled.
ifPromiscuousMode
Set to false(2). If the circuit is not modeled as a
packet-oriented interface, this object SHOULD NOT be
supported and result in noSuchInstance.
ifConnectorPresent
Set to false(2).
All other values are supported as stated in the IF-MIB documentation.
Steinberger & Nicklass Standards Track [Page 8]
RFC 3201 Circuit to Interface MIB January 2002
4.4.2. Stack Table (ifStackTable)
This section describes by example how to use ifStackTable to
represent the relationship between circuit and logical link
interfaces.
Example 1: Circuits (C) on a frame relay logical link.
+---+ +---+ +---+
| C | | C | | C |
+-+-+ +-+-+ +-+-+
| | |
+---+------+------+---+
| Frame Relay Service |
+----------+----------+
|
+----------+----------+
| Physical Layer |
+---------------------+
The assignment of the index values could for example be (for a V35
physical interface):
ifIndex Description
======= ===========
1 frDlciEndPt (type 193)
2 frDlciEndPt (type 193)
3 frDlciEndPt (type 193)
4 frameRelayService (type 44)
5 v35 (type 33)
The ifStackTable is then used to show the relationships between each
interface.
HigherLayer LowerLayer
=========== ==========
0 1
0 2
0 3
1 4
2 4
3 4
4 5
5 0
In the above example the frame relay logical link could just as
easily be of type frameRelay(32) instead.
Steinberger & Nicklass Standards Track [Page 9]
RFC 3201 Circuit to Interface MIB January 2002
Example 2: Circuits (C) on a AAL5 logical link.
+---+ +---+ +---+
| C | | C | | C |
+-+-+ +-+-+ +-+-+
| | |
+---+------+------+---+
| AAL5 Layer |
+----------+----------+
|
+----------+----------+
| ATM Layer |
+---------------------+
|
+----------+----------+
| Physical Layer |
+---------------------+
The assignment of the index values could for example be (for a DS3
physical interface):
ifIndex Description
======= ===========
1 atmVciEndPt (type 194)
2 atmVciEndPt (type 194)
3 atmVciEndPt (type 194)
4 aal5 (type 49)
5 atm (type 37)
6 ds3 (type 30)
The ifStackTable is then used to show the relationships between each
interface.
HigherLayer LowerLayer
=========== ==========
0 1
0 2
0 3
1 4
2 4
3 4
4 5
5 6
6 0
Steinberger & Nicklass Standards Track [Page 10]
RFC 3201 Circuit to Interface MIB January 2002
4.5. Other MIB Modules
There is no explicit relation to any other media specific MIB module
beyond the fact that rows in multiple tables may be referenced.
5. Structure of the MIB Module
The CIRCUIT-IF-MIB consists of the following components:
o ciCircuitTable
o ciIfMapTable
Refer to the compliance statement defined within for a definition of
what objects MUST be implemented.
5.1. ciCircuitTable
The ciCircuitTable is the central control table for operations of the
Circuit Interfaces MIB. It provides a means of mapping a circuit to
its ifIndex as well as forcing the insertion of an ifIndex into the
ifTable. The agent is responsible for managing the ifIndex itself
such that no device dependent indexing scheme is violated.
A row in this table MUST exist in order for a row to exist in any
other table in this MIB module.
5.2. ciIfMapTable
This table maps the ifIndex back to the circuit that it is associated
with.
6. Object Definitions
CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
mib-2, Gauge32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus,
TimeStamp, RowPointer, StorageType FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
ifIndex, InterfaceIndex FROM IF-MIB;
circuitIfMIB MODULE-IDENTITY
LAST-UPDATED "200201030000Z" -- January 3, 2002
ORGANIZATION "IETF Frame Relay Service MIB Working Group"
CONTACT-INFO
Steinberger & Nicklass Standards Track [Page 11]
RFC 3201 Circuit to Interface MIB January 2002
"IETF Frame Relay Service MIB (frnetmib) Working Group
WG Charter: http://www.ietf.org/html.charters/
frnetmib-charter.html
WG-email: frnetmib@sunroof.eng.sun.com
Subscribe: frnetmib-request@sunroof.eng.sun.com
Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib
Chair: Andy Malis
Vivace Networks
Email: Andy.Malis@vivacenetworks.com
WG editor: Robert Steinberger
Paradyne Networks and
Fujitsu Network Communications
Email: robert.steinberger@fnc.fujitsu.com
Co-author: Orly Nicklass
RAD Data Communications Ltd.
EMail: Orly_n@rad.co.il"
DESCRIPTION
"The MIB module to allow insertion of selected circuit into
the ifTable."
REVISION "200201030000Z" -- January 3, 2002
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -