RFC 3201: Definitions of Managed Objects for Circuit to Interface Translation

This RFC was updated

Network Working Group R. Steinberger
Request for Comments: 3201 Paradyne Networks
Category: Standards Track O. Nicklass
 RAD Data Communications Ltd.
 January 2002


 Definitions of Managed Objects
 for Circuit to Interface Translation

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.

Copyright Notice

 Copyright (C) The Internet Society (2002). All Rights Reserved.

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
 insertion of interesting Circuit Interfaces into the ifTable. This
 is important for circuits that must be used within other MIB modules
 which require an ifEntry. It allows for integrated monitoring of
 circuits as well as routing to circuits using unaltered, pre-existing
 MIB modules.

Table of Contents

 1. The SNMP Management Framework ............................... 2
 2. Conventions ................................................. 3
 3. Overview .................................................... 3
 3.1. Circuit Concepts .......................................... 4
 3.2. Theory of Operation ....................................... 4
 3.2.1. Creation Process ........................................ 4
 3.2.2. Destruction Process ..................................... 5
 3.2.2.1. Manual Row Destruction ................................ 5
 3.2.2.2. Automatic Row Destruction ............................. 5
 3.2.3. Modification Process .................................... 5
 3.2.4. Persistence of Data ..................................... 5
 4. Relation to Other MIB Modules ............................... 6
 4.1. Frame Relay DTE MIB ....................................... 6



Steinberger & Nicklass Standards Track [Page 1]

RFC 3201 Circuit to Interface MIB January 2002


 4.2. Frame Relay Service MIB ................................... 6
 4.3. ATM MIB ................................................... 6
 4.4. Interfaces Group MIB ...................................... 6
 4.4.1. Interfaces Table (ifTable, ifXtable) .................... 6
 4.4.2. Stack Table (ifStackTable) .............................. 9
 4.5. Other MIB Modules ......................................... 11
 5. Structure of the MIB Module ................................. 11
 5.1. ciCircuitTable ............................................ 11
 5.2. ciIfMapTable .............................................. 11
 6. Object Definitions .......................................... 11
 7. Acknowledgments ............................................. 19
 8. References .................................................. 19
 9. Security Considerations ..................................... 21
 10. IANA Considerations ........................................ 21
 11. Authors' Addresses ......................................... 22
 12. Full Copyright Statement ................................... 23

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 STD
 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
 second version, called SMIv2, is described in STD 58, 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 STD 15, 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 STD 15, RFC 1157 [8]. A second set of protocol
 operations and associated PDU formats is described in RFC 1905
 [13].






Steinberger & Nicklass Standards Track [Page 2]

RFC 3201 Circuit to Interface MIB January 2002


 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.

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 [21].

3. Overview

 This MIB module addresses the concept of inserting circuits, which
 are potentially virtual, 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 as
 defined in RFC 2819 [23] and RFC 2021 [19]) require the use of an
 ifIndex a DataSource.

 There is a further need to potentially monitor or manage a circuit
 based on the directional flow of traffic going through it. For
 instance, monitoring of protocols passed on a circuit using RMON-II
 (RFC 2021 [19]) does not currently capture the direction of the flow.
 This MIB module provides the capability to define an interface based
 on the specific direction of the flow.

 This section provides an overview and background of how to use this
 MIB module.



Steinberger & Nicklass Standards Track [Page 3]

RFC 3201 Circuit to Interface MIB January 2002


3.1. Circuit Concepts

 There are multiple MIB modules that define circuits. Three commonly
 used MIB modules are FRAME-RELAY-DTE-MIB (RFC 2115) [20], FRNETSERV-
 MIB (RFC 2954) [18], and ATM-MIB (RFC 2515) [22]. These define
 management objects for frame relay DTEs, frame relay services, and
 ATM respectively. Each of these MIB modules contain the ability to
 add or delete circuits; however, none create a specific ifEntry for
 a circuit. The reason for this is that there are potentially
 multiple 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 2863) [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 these
 circuits is that there is a need for their use in either management
 of routing or monitoring of data. Both of these functions require
 mapping to an ifIndex.

 This MIB module 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.

 While this document often refers to ATM and frame relay, it is not
 specifically designed for only those types of circuits. Any circuit
 that is defined in a MIB module but does not have its own ifIndex MAY
 be added with this MIB module.

3.2. Theory of Operation

3.2.1. Creation Process

 In some cases, devices will automatically populate the rows of
 ciCircuitTable 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 ciCircuitTable 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



Steinberger & Nicklass Standards Track [Page 4]

RFC 3201 Circuit to Interface MIB January 2002


 ifTable. If, for example, 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, as another
 example, 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]. If, as a final example, the ifType
 for the logical port is aal5(49), the circuits can be located in the
 aal5VccTable of the ATM MIB (ATM-MIB) [22]. An entry describing the
 circuit MUST exist in some table prior to creating a row in
 ciCircuitTable. The object identifier that MUST be used in the
 circuit definition is the lexicographically smallest accessible OID
 that fully describes the the circuit.

3.2.2. Destruction Process

3.2.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 (ciCircuitStatus) to destroy(6). It should be
 noted that when ciCircuitStatus is set to destroy(6) all associated
 rows in the ifTable and in ciIfMapTable will also be destroyed. This
 process MAY trigger further row destruction in other tables as well.

3.2.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.2.3. Modification Process

 Since no objects in the MIB module can be changed once rows are
 active, there are no modification caveats.

3.2.4. Persistence of Data

 Each row in the tables of this MIB module relies on information from
 other MIB modules. The rules for persistence of the data SHOULD
 follow the same rules as those of the underlying MIB module. For
 example, if the circuit defined by ciCircuitObject would normally be
 stored in non-volatile memory, then the ciCircuitEntry SHOULD also be
 non-volatile.




Steinberger & Nicklass Standards Track [Page 5]

RFC 3201 Circuit to Interface MIB January 2002


4. Relation to Other MIB Modules

4.1. Frame Relay DTE MIB

 There is no required relation to the Frame Relay DTE MIB beyond the
 fact that rows in the frCircuitTable MAY be referenced. However, if
 frCircuitLogicalIfIndex is being used to represent the same
 information as a ciCircuitEntry with a value of ciCircuitFlow equal
 to both(3), the implementation MAY use the same ifIndex.

4.2. Frame Relay Service MIB

 There is no explicit relation to the Frame Relay Service MIB beyond
 the fact that a rows in the frPVCEndptTable MAY be referenced.

4.3. ATM MIB

 There is no explicit relation to the ATM MIB beyond the fact that
 rows in multiple tables may be referenced.

4.4. Interfaces Group MIB

4.4.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
 module.

 Values of specific ifTable objects for circuit interfaces are as
 follows:

 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 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
 DESCRIPTION
 "Initial version, published as RFC 3201"
 ::= { mib-2 94 }

 -- Textual Conventions

 CiFlowDirection ::= 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)
 }

 ciObjects OBJECT IDENTIFIER ::= { circuitIfMIB 1 }
 ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 }
 ciConformance OBJECT IDENTIFIER ::= { circuitIfMIB 3 }




Steinberger & Nicklass Standards Track [Page 12]

RFC 3201 Circuit to Interface MIB January 2002


 -- The Circuit Interface Circuit Table
 --
 -- This table is used to define and display the circuits that
 -- are added to the ifTable. It maps circuits to their respective
 -- ifIndex values.

 ciCircuitTable OBJECT-TYPE
 SYNTAX SEQUENCE OF CiCircuitEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "The Circuit Interface Circuit Table."
 ::= { ciObjects 1 }

 ciCircuitEntry OBJECT-TYPE
 SYNTAX CiCircuitEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "An entry in the Circuit Interface Circuit Table."
 INDEX { ciCircuitObject, ciCircuitFlow }
 ::= { ciCircuitTable 1 }

 CiCircuitEntry ::=
 SEQUENCE {
 --
 -- Index Control Variables
 --
 ciCircuitObject RowPointer,
 ciCircuitFlow CiFlowDirection,
 ciCircuitStatus RowStatus,
 --
 -- Data variables
 --
 ciCircuitIfIndex InterfaceIndex,
 ciCircuitCreateTime TimeStamp,
 --
 -- Data Persistence
 --
 ciCircuitStorageType StorageType
 }

 ciCircuitObject OBJECT-TYPE
 SYNTAX RowPointer
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "This value contains the RowPointer that uniquely



Steinberger & Nicklass Standards Track [Page 13]

RFC 3201 Circuit to Interface MIB January 2002


 describes the circuit that is to be added to this table.
 Any RowPointer that will force the size of OBJECT
 IDENTIFIER of the row to grow beyond the legal limit
 MUST be rejected.

 The purpose of this object 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 include the frCircuitTable
 from the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB), the
 frPVCEndptTable from the Frame Relay Service MIB
 (FRNETSERV-MIB), and the aal5VccTable from the ATM MIB
 (ATM MIB). However, including circuits from other MIB
 tables IS NOT prohibited."
 ::= { ciCircuitEntry 1 }

 ciCircuitFlow OBJECT-TYPE
 SYNTAX CiFlowDirection
 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.

 It is recommended that the ifDescr of the circuit
 interfaces that are not both(3) SHOULD have text warning
 the operators that the particular interface represents
 only half the traffic on the circuit."
 ::= { ciCircuitEntry 2 }

 ciCircuitStatus 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



Steinberger & Nicklass Standards Track [Page 14]

RFC 3201 Circuit to Interface MIB January 2002


 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 frDlciEndPt(193)
 for a frame relay circuit, atmVciEndPt(194) for an
 ATM circuit, or another ifType defining the circuit
 type for any other circuit.

 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 ciCircuitObject. This means that the
 referenced object must exist and it must be in a table
 that supports circuits.

 The object referenced by ciCircuitObject MUST exist
 prior to transitioning a row to active(1). If at any
 point the object referenced by ciCircuitObject does not
 exist or the row containing it is not in the active(1)
 state, the status SHOULD either age out the row or
 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).

 Each row in this table relies on information from other
 MIB modules. The rules persistence of data SHOULD follow
 the same rules as those of the underlying MIB module.
 For example, if the circuit defined by ciCircuitObject
 would normally be stored in non-volatile memory, then
 the row SHOULD also be non-volatile."
 ::= { ciCircuitEntry 3 }

 ciCircuitIfIndex OBJECT-TYPE
 SYNTAX InterfaceIndex
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
 "The ifIndex that the agent assigns to this row."
 ::= { ciCircuitEntry 4 }

 ciCircuitCreateTime OBJECT-TYPE
 SYNTAX TimeStamp
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION



Steinberger & Nicklass Standards Track [Page 15]

RFC 3201 Circuit to Interface MIB January 2002


 "This object returns the value of sysUpTime at the time
 the value of ciCircuitStatus last transitioned to
 active(1). If ciCircuitStatus has never been active(1),
 this object SHOULD return 0."
 ::= { ciCircuitEntry 5 }

 ciCircuitStorageType OBJECT-TYPE
 SYNTAX StorageType
 MAX-ACCESS read-create
 STATUS current
 DESCRIPTION
 "The storage type used for this row."
 ::= { ciCircuitEntry 6 }

 -- The 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.

 ciIfMapTable OBJECT-TYPE
 SYNTAX SEQUENCE OF CiIfMapEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "The Circuit Interface Map Table."
 ::= { ciObjects 2 }

 ciIfMapEntry OBJECT-TYPE
 SYNTAX CiIfMapEntry
 MAX-ACCESS not-accessible
 STATUS current
 DESCRIPTION
 "An entry in the Circuit Interface Map Table."
 INDEX { ifIndex }
 ::= { ciIfMapTable 1 }

 CiIfMapEntry ::=
 SEQUENCE {
 --
 -- Mapped Object Variables
 --
 ciIfMapObject RowPointer,
 ciIfMapFlow CiFlowDirection
 }

 ciIfMapObject OBJECT-TYPE
 SYNTAX RowPointer



Steinberger & Nicklass Standards Track [Page 16]

RFC 3201 Circuit to Interface MIB January 2002


 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
 "This value contains the value of RowPointer that
 corresponds to the current ifIndex."
 ::= { ciIfMapEntry 1 }

 ciIfMapFlow OBJECT-TYPE
 SYNTAX CiFlowDirection
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
 "The value contains the value of ciCircuitFlow that
 corresponds to the current ifIndex."
 ::= { ciIfMapEntry 2 }

 -- Change tracking metrics

 ciIfLastChange OBJECT-TYPE
 SYNTAX TimeStamp
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
 "The value of sysUpTime at the most recent change to
 ciCircuitStatus for any row in ciCircuitTable."
 ::= { ciObjects 3 }

 ciIfNumActive OBJECT-TYPE
 SYNTAX Gauge32
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
 "The number of active rows in ciCircuitTable."
 ::= { ciObjects 4 }

 -- Conformance Information

 ciMIBGroups OBJECT IDENTIFIER ::= { ciConformance 1 }
 ciMIBCompliances OBJECT IDENTIFIER ::= { ciConformance 2 }

 --
 -- Compliance Statements
 --

 ciCompliance MODULE-COMPLIANCE
 STATUS current
 DESCRIPTION
 "The compliance statement for SNMP entities



Steinberger & Nicklass Standards Track [Page 17]

RFC 3201 Circuit to Interface MIB January 2002


 which support of the Circuit Interfaces MIB module.
 This group defines the minimum level of support
 required for compliance."
 MODULE -- this module
 MANDATORY-GROUPS { ciCircuitGroup,
 ciIfMapGroup,
 ciStatsGroup }

 OBJECT ciCircuitStatus
 SYNTAX INTEGER { active(1) } -- subset of RowStatus
 MIN-ACCESS read-only
 DESCRIPTION
 "Row creation can be done outside of the scope of
 the SNMP protocol. If this object is implemented with
 max-access of read-only, then the only value that MUST
 be returned is active(1)."

 OBJECT ciCircuitStorageType
 MIN-ACCESS read-only
 DESCRIPTION
 "It is legal to support ciCircuitStorageType as read-
 only as long as the value reported in consistent
 with the actual storage mechanism employed within the
 agent."

 ::= { ciMIBCompliances 1 }

 --
 -- Units of Conformance
 --
 ciCircuitGroup OBJECT-GROUP
 OBJECTS {
 ciCircuitStatus,
 ciCircuitIfIndex,
 ciCircuitCreateTime,
 ciCircuitStorageType
 }
 STATUS current
 DESCRIPTION
 "A collection of required objects providing
 information from the circuit table."
 ::= { ciMIBGroups 1 }

 ciIfMapGroup OBJECT-GROUP
 OBJECTS {
 ciIfMapObject,
 ciIfMapFlow
 }



Steinberger & Nicklass Standards Track [Page 18]

RFC 3201 Circuit to Interface MIB January 2002


 STATUS current
 DESCRIPTION
 "A collection of required objects providing
 information from the interface map table."
 ::= { ciMIBGroups 2 }

 ciStatsGroup OBJECT-GROUP
 OBJECTS {
 ciIfLastChange,
 ciIfNumActive
 }
 STATUS current
 DESCRIPTION
 "A collection of statistical metrics used to help manage
 the ciCircuitTable."
 ::= { ciMIBGroups 3 }
END

7. Acknowledgments

 This document was produced by the Frame Relay Service MIB Working
 Group.

8. References

 [] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
 Describing SNMP Management Frameworks", RFC 2571, April 1999.

 [] Rose, M. and K. McCloghrie, "Structure and Identification of
 Management Information for TCP/IP-based Internets", STD 16, RFC
 1155, May 1990.

 [] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
 RFC 1212, March 1991.

 [] Rose, M., "A Convention for Defining Traps for use with the
 SNMP", RFC 1215, March 1991.

 [] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
 M. and S. Waldbusser, "Structure of Management Information
 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

 [] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
 RFC 2579, April 1999.






Steinberger & Nicklass Standards Track [Page 19]

RFC 3201 Circuit to Interface MIB January 2002


 [] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
 58, RFC 2580, April 1999.

 [] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
 Network Management Protocol", STD 15, RFC 1157, May 1990.

 [] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
 "Introduction to Community-based SNMPv2", RFC 1901, January
 1996.

 [] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
 Mappings for Version 2 of the Simple Network Management Protocol
 (SNMPv2)", RFC 1906, January 1996.

 [] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
 Processing and Dispatching for the Simple Network Management
 Protocol (SNMP)", RFC 2572, April 1999.

 [] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
 for version 3 of the Simple Network Management Protocol
 (SNMPv3)", RFC 2574, April 1999.

 [] 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.

 [] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
 2573, April 1999.

 [] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
 Control Model (VACM) for the Simple Network Management Protocol
 (SNMP)", RFC 2575, April 1999.

 [] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
 to Version 3 of the Internet-standard Network Management
 Framework", RFC 2570, April 1999.

 [] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
 RFC 2863, June 2000.

 [] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for
 Frame Relay Service", RFC 2954, October 2000.

 [] Waldbusser, S., "Remote Network Monitoring Management
 Information Base Version 2 using SMIv2", RFC 2021, January 1997.





Steinberger & Nicklass Standards Track [Page 20]

RFC 3201 Circuit to Interface MIB January 2002


 [] Brown, C. and F. Baker, "Management Information Base for Frame
 Relay DTEs Using SMIv2", RFC 2115, September 1997.

 [] Bradner, S., "Key words for use in RFCs to Indicate Requirement
 Levels", BCP 14, RFC 2119, March 1997.

 [] Tesink, K., "Definitions of Managed Objects for ATM Management",
 RFC 2515, February 1999.

 [] Waldbusser, S., "Remote Network Monitoring Management
 Information Base", RFC 2819, May 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. IANA Considerations

 New ifTypes defined specifically for use in this MIB module SHOULD be
 in the form of ***EndPt. This is similar to frDlciEndPt(193) and
 atmVciEndPt(194) which are already defined.









Steinberger & Nicklass Standards Track [Page 21]

RFC 3201 Circuit to Interface MIB January 2002


11. Authors' Addresses

 Robert Steinberger
 Fujitsu Network Communications
 2801 Telecom Parkway
 Richardson, TX 75082

 Phone: 1-972-479-4739
 EMail: robert.steinberger@fnc.fujitsu.com


 Orly Nicklass, Ph.D
 RAD Data Communications Ltd.
 12 Hanechoshet Street
 Tel Aviv, Israel 69710

 Phone: 972 3 7659969
 EMail: Orly_n@rad.co.il

































Steinberger & Nicklass Standards Track [Page 22]

RFC 3201 Circuit to Interface MIB January 2002


12. Full Copyright Statement

 Copyright (C) The Internet Society (2002). 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.



















Steinberger & Nicklass Standards Track [Page 23]