📄 rfc3020.txt
字号:
be corresponding mfrBundleIndex which may be different than the
ifIndex of the bundle.
The reason is best summarized in RFC 2494 [RFC2494], which describes
frame relay bundle of DS0. It says:
This table is not indexed by ifIndex because the manager has to
choose the index in a createable row and the agent must be allowed
to select ifIndex values.
The rows in the ifEntry table are not createable as they do not have
row status. RFC 2863 [RFC2863] suggests that the ifIndex should be
chosen by the agent. Here is its statement regarding row creation
and deletion:
While some interfaces, for example, most physical interfaces,
cannot be created via network management, other interfaces such as
logical interfaces sometimes can be. The ifTable contains only
generic information about an interface. Almost all 'create-able'
interfaces have other, media-specific, information through which
Pate, et al. Standards Track [Page 7]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
configuration parameters may be supplied prior to creating such an
interface. Thus, the ifTable does not itself support the creation
or deletion of an interface (specifically, it has no RowStatus
column). Rather, if a particular interface type supports the
dynamic creation and/or deletion of an interface of that type,
then that media-specific MIB should include an appropriate
RowStatus object (see the ATM LAN-Emulation Client MIB [ATMLANE]
for an example of a MIB which does this). Typically, when such a
RowStatus object is created/deleted, then the conceptual row in
the ifTable appears/disappears as a by-product, and an ifIndex
value (chosen by the agent) is stored in an appropriate object in
the media-specific MIB.
The ATM LAN-Emulation Client MIB [ATMLANE] uses different indices and
so does the IMA MIB [ATMIMA]. Looking at the examples we have, and
the statements from RFC, it seems better to have two indices. This
gives the SNMP agent implementor the freedom to manage their ifIndex
in the way they like.
2.3.1.3. Mapping Between ifIndex and mfrBundleIndex
The mfrBundleIfIndexMappingTable is indexed by ifIndex and provides
the means to map a given ifIndex into the corresponding
mfrBundleIndex. The mfrBundleIfIndexMapping object in the
mfrBundleTable (indexed by mfrBundleIndex) provides the reverse
mapping of a mfrBundleIndex to the corresponding ifIndex in the
ifTable.
2.3.1.4. ifTable Objects
The bundle configuration and status table. There is a one-to-one
correspondence between a bundle and an interface represented in the
ifTable.
The following objects of the ifTable have specific meaning for an MFR
bundle:
ifAdminStatus - the bundle admin status
ifOperStatus - the bundle operational status
ifSpeed - the current bandwidth of the bundle
ifInUcastPkts - the number of frames received on the bundle
ifOutUcastPkts - the number of frames transmitted on the bundle
ifInErrors - frame (not fragment) errors
ifOutErrors - frame (not fragment) errors
The following objects of the ifTable have specific meaning for an MFR
bundle link:
Pate, et al. Standards Track [Page 8]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
ifAdminStatus - the bundle link admin status
ifOperStatus - the bundle link operational status
ifSpeed - the bandwidth of the bundle link interface
ifInUcastPkts - the number of frames received on the bundle link
ifOutUcastPkts - the number of frames transmitted on the bundle
link
ifInErrors - frame and fragment errors
ifOutErrors - frame and fragment errors
2.3.2. Relationship With Interface Stack Table
The bundles and bundle links will appear in the ifStackTable defined
in RFC 2863 [RFC2863]. Each bundle link will appear a lower layer to
its owner bundle. The bundle will appear as a higher layer to the
bundle links and as a lower layer to a frame relay service or UNI.
2.3.3. Relationship With Frame Relay DTE MIB
The bundle will have a one-to-one correspondence with a DLCMI or UNI
that appear in the DTE MIB tables [RFC2115].
2.3.4. Relationship With Frame Relay Service MIB
There is a one-to-one relationship between the MFR bundle and the
frame relay service logical port defined in RFC1604 [RFC1604].
2.3.5. Example
Figure two shows an example of how the various tables are related.
This example shows two bundles composed of 2 T1s each. The bundles
have a mfrBundleIndex of 10 and 20 respectively.
+-------------------------+
| Frame Relay Service |
+-----+-------------+-----+
| |
+-----+------+------+-----+
| MFR Bundle | MFR Bundle |
| 10 | 20 |
+--+-----+---+---+-----+--+
| | | |
+-+-+ +-+-+ +-+-+ +-+-+
|T1 | |T1 | |T1 | |T1 |
+---+ +---+ +-+-+ +---+
Figure 2: Frame Relay Service Being Carried on 4 T1s
Pate, et al. Standards Track [Page 9]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
The assignment of the ifTable index values could for example be:
ifIndex | Description | ifType
--------+----------------------------+----------------------
1 | FrameRelayService | frameRelayService(44)
2 | MFR Bundle #10 | frf16MfrBundle(163)
3 | MFR Bundle #20 | frf16MfrBundle(163)
4 | ds1 #1/MFR Bundle Link #1 | ds1(18)
5 | ds1 #2/MFR Bundle Link #2 | ds1(18)
6 | ds1 #3/MFR Bundle Link #3 | ds1(18)
7 | ds1 #4/MFR Bundle Link #4 | ds1(18)
The ifStackTable is then used to show the relationships between the
various interfaces.
HigherLayer | LowerLayer
------------+-----------
0 | 1
1 | 2
1 | 3
2 | 4
2 | 5
3 | 6
3 | 7
4 | 0
5 | 0
6 | 0
7 | 0
The mfrBundleIfIndexMappingTable shows the relationship between the
ifTable ifIndex and the mfrBundleIndex:
ifIndex | mfrBundleIfIndexMappingIndex
--------+-----------------------------
2 | 10
3 | 20
The mfrBundleTable shows the relationship between the mfrBundleIndex
and the ifIndex:
mfrBundleIndex | mfrBundleIfIndex
---------------+-----------------
10 | 2
20 | 3
Pate, et al. Standards Track [Page 10]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
The mfrBundleLinkTable shows the relationship between the bundles and
bundle links:
mfrBundleIndex | mfrBundleLinkIfIndex
---------------+---------------------
10 | 4
10 | 5
20 | 6
20 | 7
2.4. Creation Of Bundles and Bundle Links
2.4.1. Creation Of Bundles
A new bundle is created by setting a createAndGo(4) value in the
mfrBundleRowStatus RowStatus object. Optionally, an agent could also
support setting a value of createAndWait(5) followed by a set to the
value active(1).
When a bundle is created, the agent must create a new interface in
the ifTable. The ifIndex for this new interface is used for the
value of mfrBundleIfIndex.
2.4.2. Creation Of Bundle Links
A new bundle link is created by setting a createAndGo(4) value in the
mfrBundleLinkRowStatus RowStatus object.
The bundle link is associated with a specific physical interface and
uses the ifIndex of the physical interface. The mfrBundleLinkEntry
row objects may be created after or during creation of the physical
interface's ifEntry row objects.
The bundle identified in the object mfrBundleIndex must exist at time
of bundle link creation.
2.5. Notifications
The linkUp and linkDown traps are defined in RFC 2223 [RFC2223].
2.5.1. Bundle
The following SNMP traps are defined for MFR bundles.
Pate, et al. Standards Track [Page 11]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
2.5.1.1. linkUp
This trap is sent when the ifOperStatus of a bundle transitions from
down to up. This occurs when a sufficient number of links
(determined by mfrBundleActivationClass and mfrBundleThreshold) are
in the operationally up state.
2.5.1.2. linkDown
This trap is sent when the ifOperStatus of a bundle transitions from
up to down. This occurs when a insufficient number of links
(determined by mfrBundleActivationClass and mfrBundleThreshold) are
in the operationally up state.
2.5.2. Bundle Link
The following SNMP traps are defined for MFR bundle links.
2.5.2.1. linkUp
This trap is sent when a mfrBundleLinkState object transitions to the
value mfrBundleLinkStateUp.
2.5.2.2. linkDown
This trap is sent when a mfrBundleLinkState object transitions from
the value mfrBundleLinkStateUp.
2.5.2.3. mfrMibTrapBundleLinkMismatch
This trap indicates that a bundle link mismatch has been detected.
The following objects are reported:
- mfrBundleNearEndName: configured name of near end bundle
- mfrBundleFarEndName: previously reported name of far
end bundle
- mfrBundleLinkNearEndName: configured name of near end bundle
- mfrBundleLinkFarEndName: reported name of far end bundle
- mfrBundleLinkFarEndBundleName: currently reported name of far
end bundle
Note that the configured items may have been configured
automatically. Note also that the mfrBundleLinkMismatch counter is
incremented when the trap is sent.
Pate, et al. Standards Track [Page 12]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
3. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or 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, 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, we
often use a textual string, termed the descriptor, to refer to the
object type.
FR-MFR-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32,
NOTIFICATION-TYPE, transmission
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr, RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InterfaceIndex, ifIndex
FROM IF-MIB;
mfrMib MODULE-IDENTITY
LAST-UPDATED "200011300000Z"
ORGANIZATION "IETF Frame Relay Service MIB (frnetmib)
Working Group"
CONTACT-INFO
"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: Prayson Pate
Overture Networks
Email: prayson.pate@overturenetworks.com
Co-author: Bob Lynch
Overture Networks
Pate, et al. Standards Track [Page 13]
RFC 3020 MIB for FRF.16 UNI/NNI MFR December 2000
EMail: bob.lynch@overturenetworks.com
Co-author: Kenneth Rehbehn
Megisto Systems, Inc.
EMail: krehbehn@megisto.com"
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -