Definitions of Managed Objects
for Frame Relay Circuit Interfaces
June 16, 2000
draft-steinberger-frsi-00.txt
Robert A. Steinberger
Paradyne Networks
rsteinberger@paradyne.com
Orly Nicklass, Ph.D
RAD Data Communications Ltd.
Orly_n@rad.co.il
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo defines an extension of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the
addition of Frame Relay Circuit Interfaces into the ifTable. This
memo does not specify a standard for the Internet community.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Expires December 2000 Steinberger & Nicklass [Page 1]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
Table of Contents
1. The SNMP Management Framework ............................... 3
2. Conventions ................................................. 4
3. Overview .................................................... 4
3.1. Frame Relay Circuits ...................................... 4
3.2. Terminology ............................................... 5
3.3. Theory of Operation ....................................... 5
3.3.1. Creation Process ........................................ 5
3.3.2. Destruction Process ..................................... 5
3.3.2.1. Manual Row Destruction ................................ 5
3.3.2.2. Automatic Row Destruction ............................. 6
3.3.3. Modification Process .................................... 6
4. Relation to Other MIBs ...................................... 6
4.1. Frame Relay DTE MIB ....................................... 6
4.2. Frame Relay Service MIB ................................... 6
4.2.1. Interfaces Group MIB .................................... 6
4.2.1.1. Interfaces Table (ifTable, ifXtable) .................. 6
4.2.1.2. Stack Table (ifStackTable ) ........................... 8
5. Structure of the MIB ........................................ 9
5.1. frciCircuitTable .......................................... 9
5.2. frciIfMapTable ............................................ 10
6. Object Definitions .......................................... 10
7. Acknowledgments ............................................. 16
8. References .................................................. 17
9. Security Considerations ..................................... 20
10. Author's Address ........................................... 20
11. Copyright Section .......................................... 21
Expires December 2000 Steinberger & Nicklass [Page 2]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in RFC
1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version,
called SMIv2, is described in RFC 2578 [5], RFC 2579 [6] and RFC
2580 [7].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [8]. A second version of the SNMP message
protocol, which is not an Internet standards track protocol, is
called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10].
The third version of the message protocol is called SNMPv3 and
described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [8]. A second set of protocol operations and
associated PDU formats is described in RFC 1905 [13].
o A set of fundamental applications described in RFC 2573 [14] and
the view-based access control mechanism described in RFC 2575
[15].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [16].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
Expires December 2000 Steinberger & Nicklass [Page 3]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
RFC 2119 [23].
3. Overview
This MIB addresses the concept of inserting frame relay circuits into
the ifTable. There are multiple reasons to allow circuits to be
added to the ifTable. The most prevalent of which are the standard
routing MIB tables such as the ipCidrRouteTable (IP-FORWARD-MIB) and
the ipNetToMediaTable (IP-MIB) act on the ifIndex and the RMON MIBs
(RMON-MIB and RMON2-MIB) require the use of an ifIndex a DataSource.
This section provides an overview and background of how to use this
MIB.
3.1. Frame Relay Circuits
The frame relay circuits are currently managed with one of two
standards track MIBs: FRAME-RELAY-DTE-MIB (RFC 2115) [20] and the
FRNETSERV-MIB (RFC 1604) [18]. These MIBs contain the ability to add
or delete frame relay circuits as well as the statistics and other
management objects. However, they do not create ifIndex rows for the
circuits. The reason for this is that there are potentially multiple
frame relay circuits and not every circuit needs to be managed as an
individual interface. For example, not every circuit on a device
needs to be monitored with RMON and not every circuit needs to be
included as an individual circuit for routing. Further, the
Interfaces Group MIB (RFC 2233) [17] strongly recommends that
conceptual rows not be added to the ifTable for virtual circuits.
The rationale for creating conceptual rows in the ifTable for frame
relay circuits is that there is a need to both manage routing and
monitor data on frame relay circuits. Both of these functions
require a mapping to an ifIndex.
This MIB is designed such that only those circuits that require an
ifIndex need be added to the ifTable. This prevents over-populating
the ifTable with useless or otherwise unused indices.
Expires December 2000 Steinberger & Nicklass [Page 4]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
3.2. Terminology
o DLCI - Data Link Connection Identifier. [18]
o Logical Port - This term is used to model the Frame Relay
"interface" on a device. [18]
3.3. Theory of Operation
3.3.1. Creation Process
In some cases, devices will automatically populate the rows of
Circuit Table as circuits are created or discovered. However, in
many cases, it may be necessary for a network manager to manually
create rows.
Manual creation of rows requires the following steps:
1) Locate or create the circuit that is to be added on the device.
2) Create a row in the circuit table for each flow type that is
required.
The first step above requires some knowledge of the circuits that
exist on a device. Typically, logical ports have entries in the
ifTable. If the ifType for the logical port is frameRelay(32), the
circuits can be located in the frCircuitTable of the Frame Relay DTE
MIB (FRAME-RELAY-DTE-MIB) [18]. If the ifType for the logical port
is frameRelayService(44), the circuits can be located in the
frPVCEndptTable of the Frame Relay Service MIB (FRNETSERV-MIB) [20].
An entry describing the circuit MUST exist in some table prior to
creating a row in the circuit table.
3.3.2. Destruction Process
3.3.2.1. Manual Row Destruction
Manual row destruction is straight forward. Any row can be destroyed
and the resources allocated to it are freed by setting the value of
its status object (frciCircuitStatus) to destroy(6). It should be
noted that when frciCircuitStatus is set to destroy(6) all associated
rows in the ifTable and in the interface map table will also be
destroyed. This process can trigger further row destruction in other
Expires December 2000 Steinberger & Nicklass [Page 5]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
tables as well.
3.3.2.2. Automatic Row Destruction
Rows in the tables may be destroyed automatically based on the
existence of the circuit on which they rely. When a circuit no
longer exists in the device, the data in the tables has no relation
to anything known on the network. For this reason, rows MUST be
removed from this table as soon as it is discovered that the
associated circuits no longer exist. The effects of automatic row
destruction are the same as manual row destruction.
3.3.3. Modification Process
There are no objects that can be modified in this MIB.
4. Relation to Other MIBs
4.1. Frame Relay DTE MIB
There is no explicit relation to the Frame Relay DTE MIB beyond the
fact that a row in the frCircuitTable MAY be reference.
4.2. Frame Relay Service MIB
There is no explicit relation to the Frame Relay Service MIB beyond
the fact that a row in the frPVCEndptTable MAY be referenced.
4.2.1. Interfaces Group MIB
4.2.1.1. Interfaces Table (ifTable, ifXtable)
The following specifies how the Interfaces Group defined in the IF-
MIB will be used for the management of interfaces created by this
MIB.
Values of specific ifTable objects for frame relay circuits are as
follows:
Expires December 2000 Steinberger & Nicklass [Page 6]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
Object Name Value of Object
=========== =====================================================
ifIndex Each entry in the circuit table is represented by an
ifEntry. The value of ifIndex is defined by the agent
such that it complies with any internal numbering
scheme.
ifType The value for frame relay virtual circuits (??).
ifMtu Set to the maximum frame size in octets supported on
the circuit.
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 (Be / Tc) otherwise.
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 only count
octets from the beginning of the frame relay header
field to the end of user data. If the network
supporting Frame Relay can not count octets, then this
count should be a close approximation.
ifInUcastPkts The unerrored number of frames received by the network
(ingress) for this circuit.
ifInDiscards The number of received frames for this circuit
discarded due to ingress buffer congestion and traffic
policing.
ifInErrors The number of received frames for this circuit that
are discarded because of an error.
ifOutOctets The number of octets sent by the network (egress) for
this circuit. This counter should only count octets
from the beginning of the frame relay header field to
the end of user data. If the network supporting Frame
Relay can not count octets, then this count should be
an approximation.
ifOutUcastpkts The number of unerrored frames sent by the network
(egress) for this circuit.
ifOutDiscards The number of frames discarded in the egress direction
Expires December 2000 Steinberger & Nicklass [Page 7]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
for this circuit. Possible reasons are as follows:
policing, congestion.
ifOutErrors The number of frames discarded for this circuit in the
egress direction because of an error.
ifInBroadcastPkts
This variable is not applicable; therefore, this
counter is always zero.
ifOutBroadcastPkts
This variable is not applicable; therefore, this
counter is always zero.
ifLinkUpDownTrapEnable
Set to false(2).
ifPromiscuousMode
Set to false(2).
ifConnectorPresent
Set to false(2).
All other values are supported as stated in the IF-MIB documentation.
4.2.1.2. Stack Table (ifStackTable )
This section describes by example how to use ifStackTable to represent
the relationship between circuit and logical link interfaces.
Example: 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):
Expires December 2000 Steinberger & Nicklass [Page 8]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
ifIndex Description
======= ===========
1 frameRelayCircuit (type ???)
2 frameRelayCircuit (type ???)
3 frameRelayCircuit (type ???)
4 frameRelayService (type 44)
5 v34 (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.
5. Structure of the MIB
The FRCI-MIB consists of the following components:
o frciCircuitTable
o frciIfMapTable
Refer to the compliance statement defined within for a definition of
what objects MUST be implemented.
5.1. frciCircuitTable
The frciCircuitTable is the central control table for operations of
the Frame Relay 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
Expires December 2000 Steinberger & Nicklass [Page 9]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
other table in this MIB.
5.2. frciIfMapTable
This table maps the ifIndex back to the circuit that it is associated
with.
6. Object Definitions
FRCI-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus,
TimeStamp FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
ifIndex, InterfaceIndex FROM IF-MIB;
frciMIB MODULE-IDENTITY
LAST-UPDATED "200006161500Z" -- June 16, 2000
ORGANIZATION "IETF TBD Working Group"
CONTACT-INFO
"IETF TBD Working Group
WG Charter:
WG-email:
Subscribe:
Email Archive:
Chair:
Email:
WG editor: Robert Steinberger
Paradyne Networks
Email: rsteinberger@paradyne.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 "200006161500Z"
DESCRIPTION
"o Original Draft"
::= { mib-2 xxx } -- RFC editor - IANA assigns xxx
Expires December 2000 Steinberger & Nicklass [Page 10]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
-- Textual Conventions
FrciFlowDir ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The direction of data flow thru a circuit.
transmit(1) - Only transmitted data
receive(2) - Only received data
both(3) - Both transmitted and received data."
SYNTAX INTEGER {
transmit(1),
receive(2),
both(3)
}
frciObjects OBJECT IDENTIFIER ::= { frciMIB 1 }
frciCapabilities OBJECT IDENTIFIER ::= { frciMIB 2 }
frciConformance OBJECT IDENTIFIER ::= { frciMIB 3 }
-- The Frame Relay Circuit Interface Circuit Table
--
-- This table is used to define and display the frame relay
-- circuits that are added to the ifTable. It maps circuits
-- to their respective ifIndex values.
frciCircuitTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrciCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Circuit Interface Circuit Table."
::= { frciObjects 1 }
frciCircuitEntry OBJECT-TYPE
SYNTAX FrciCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Circuit Interface
Circuit Table."
INDEX { frciCircuitObject, frciCircuitFlow }
::= { frciCircuitTable 1 }
FrciCircuitEntry ::=
SEQUENCE {
--
-- Index Control Variables
Expires December 2000 Steinberger & Nicklass [Page 11]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
--
frciCircuitObject OBJECT IDENTIFIER,
frciCircuitFlow FrciFlowDir,
frciCircuitStatus RowStatus,
--
-- Data variables
--
frciCircuitIfIndex InterfaceIndex,
frciCircuitCreateTime TimeStamp
}
frciCircuitObject OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This value contains the object identifier that uniquely
describes the circuit that is to be added to this table.
The object identifier should be that of the first field
on the table that contains the circuit. The index sub
identifiers should uniquely define the circuit.
The purpose of this object identifier is to point a
network manager to the table in which the circuit was
created as well as define the circuit on which the
interface is defined.
Valid tables for this object are the frCircuitTable from
the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB) or the
frPVCEndptTable from the Frame Relay Service MIB
(FRNETSERV-MIB). However, it does not exclude enterprise
MIBs used for the same purpose."
::= { frciCircuitEntry 1 }
frciCircuitFlow OBJECT-TYPE
SYNTAX FrciFlowDir
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The direction of data flow through the circuit for which
the virtual interface is defined. The following define
the information that the virtual interface will report.
transmit(1) - Only transmitted frames
receive(2) - Only received frames
both(3) - Both transmitted and received frames.
The need to monitor directional flow depends on the
Expires December 2000 Steinberger & Nicklass [Page 12]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
application for which the circuit is created. For example,
Monitoring of protocols passed on a circuit using
RMON-II (RFC 2021) does not capture the direction the flow.
This is left to the circuit."
::= { frciCircuitEntry 2 }
frciCircuitStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of the current row. This object is
used to add, delete, and disable rows in this
table. When the status changes to active(1), a row
will also be added to the interface map table below
and a row will be added to the ifTable. These rows
SHOULD not be removed until the status is changed
from active(1). The value of ifIndex for the row that
is added to the ifTable is determined by the agent
and MUST follow the rules of the ifTable. The value
of ifType for that interface will be <?need ifType?>.
When this object is set to destroy(6), the associated
row in the interface map table will be removed and the
ifIndex will be removed from the ifTable. Removing
the ifIndex MAY initiate a chain of events that causes
changes to other tables as well.
The rows added to this table MUST have a valid object
identifier for frciCircuitObject. This means that the
referenced object must exist and it must be in a table
that supports circuits.
The object referenced by frciCircuitObject MUST exist
prior to transitioning a row to active(1). If at any
point the object referenced by frciCircuitObject does not
exist or the row containing it is not in the active(1)
state, the status SHOULD report notReady(3). The effects
transitioning from active(1) to notReady(3) are the same
as those caused by setting the status to destroy(6)."
::= { frciCircuitEntry 3 }
frciCircuitIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex that the agent assigns to this row."
Expires December 2000 Steinberger & Nicklass [Page 13]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
::= { frciCircuitEntry 4 }
frciCircuitCreateTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the value of sysUpTime at the time
the value of frciCircuitStatus last transitioned to
active(1). If frciCircuitStatus has never been active(1),
this object SHOULD return 0."
::= { frciCircuitEntry 5 }
-- The Frame Relay Circuit Interface Map Table
--
-- This table maps the ifIndex values that are assigned to
-- rows in the circuit table back to the objects that define
-- the circuits.
frciIfMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrciIfMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Frame Relay Circuit Interface Map Table."
::= { frciObjects 2 }
frciIfMapEntry OBJECT-TYPE
SYNTAX FrciIfMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Frame Relay Circuit Interface
Map Table."
INDEX { ifIndex }
::= { frciIfMapTable 1 }
FrciIfMapEntry ::=
SEQUENCE {
--
-- Mapped Object Variables
--
frciIfMapObject OBJECT IDENTIFIER,
frciIfMapFlow FrciFlowDir
}
frciIfMapObject OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
Expires December 2000 Steinberger & Nicklass [Page 14]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value contains the value of frciCircuitObject that
corresponds to the current ifIndex."
::= { frciIfMapEntry 1 }
frciIfMapFlow OBJECT-TYPE
SYNTAX FrciFlowDir
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value contains the value of frciCircuitFlow that
corresponds to the current ifIndex."
::= { frciIfMapEntry 2 }
-- Conformance Information
frciMIBGroups OBJECT IDENTIFIER ::= { frciConformance 1 }
frciMIBCompliances OBJECT IDENTIFIER ::= { frciConformance 2 }
--
-- Compliance Statements
--
frciCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities
which support with Frame Relay Circuit Interfaces.
This group defines the minimum level of support
required for compliance."
MODULE -- this module
MANDATORY-GROUPS { frciCircuitGroup,
frciIfMapGroup }
OBJECT frciCircuitStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention
need be supported, specifically: active(1)."
::= { frciMIBCompliances 1 }
--
-- Units of Conformance
Expires December 2000 Steinberger & Nicklass [Page 15]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
--
frciCircuitGroup OBJECT-GROUP
OBJECTS {
frciCircuitStatus,
frciCircuitIfIndex,
frciCircuitCreateTime
}
STATUS current
DESCRIPTION
"A collection of required objects providing
information from the circuit table."
::= { frciMIBGroups 1 }
frciIfMapGroup OBJECT-GROUP
OBJECTS {
frciIfMapObject,
frciIfMapFlow
}
STATUS current
DESCRIPTION
"A collection of required objects providing
information from the interface map table."
::= { frciMIBGroups 2 }
END
7. Acknowledgments
This document was produced by the ??? Working Group.
Expires December 2000 Steinberger & Nicklass [Page 16]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
8. References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, Cabletron Systems,
Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999
[2] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155, STD
16, Performance Systems International, Hughes LAN Systems, May 1990
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212,
STD 16, Performance Systems International, Hughes LAN Systems, March
1991
[4] M. Rose, "A Convention for Defining Traps for use with the SNMP",
RFC 1215, Performance Systems International, March 1991
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU
Braunschweig, SNMP Research, First Virtual Holdings, International
Network Services, April 1999
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD
58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Virtual Holdings, International Network Services, April 1999
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD
58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Virtual Holdings, International Network Services, April 1999
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", RFC 1157, STD 15, SNMP Research, Performance
Systems International, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction
to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[10]Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover
Beach Consulting, Inc., International Network Services, January
Expires December 2000 Steinberger & Nicklass [Page 17]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
1996.
[11]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems,
Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999
[12]Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2574, IBM T. J. Watson Research, April 1999
[13]Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover
Beach Consulting, Inc., International Network Services, January
1996.
[14]Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2573, SNMP Research, Inc., Secure Computing Corporation, Cisco
Systems, April 1999
[15]Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc.,
Cisco Systems, Inc., April 1999
[16]Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to
Version 3 of the Internet-standard Network Management Framework",
RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, Inc.,
Ericsson, Cisco Systems, April 1999
[17]McCloghrie, K. and Kastenholz, F., "The Interfaces Group MIB using
SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997.
[18]Brown, T., "Definitions of Managed Objects for Frame Relay Service",
RFC 1604, Bell Communications Research, March 1994.
[19]Waldbusser, S., "Remote Network Monitoring Management Information
Base Version 2 using SMIv2", RFC 2021, International Network
Service, January 1997.
[20]Brown, C., Baker, F., "Management Information Base for Frame Relay
DTEs Using SMIv2", RFC 2115, Cadia Networks, Inc., Cisco Systems,
September 1997.
[21]McCloghrie, K., "SNMPv2 Management Information Base for the Internet
Protocol using SMIv2", RFC 2011, Cisco Systems, November 1996.
Expires December 2000 Steinberger & Nicklass [Page 18]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
[22]Bake, F., "IP Forwarding Table MIB", RFC 2096, Cisco Systems,
January 1997.
Expires December 2000 Steinberger & Nicklass [Page 19]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
9. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2274 [12] and the View-based
Access Control Model RFC 2275 [15] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
10. Author's Address
Robert Steinberger
Paradyne Networks
Mailstop: LG-132
8545 126th Avenue North
Largo, FL USA 33773
Phone: 1(727)530-2395
Email: rsteinberger@paradyne.com
Orly Nicklass, Ph.D
RAD Data Communications Ltd.
12 Hanechoshet Street
Tel Aviv, Israel 69710
Phone: 972 3 7659969
Email: Orly_n@rrad.co.il
Expires December 2000 Steinberger & Nicklass [Page 20]
Internet Draft Frame Relay Circuit Interface MIB June 16, 2000
11. Copyright Section
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires December 2000 Steinberger & Nicklass [Page 21]