Definitions of Managed Objects for Circuit to Interface Translation May 1, 2001 draft-ietf-frnetmib-frsi-02.txt Robert A. Steinberger Paradyne Networks robert.steinberger@fnc.fujitsu.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 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. Copyright Notice Expires November 2001 Steinberger & Nicklass [Page 1] Internet Draft Circuit to Interface MIB May 1, 2001 Copyright (C) The Internet Society (2001). All Rights Reserved. Expires November 2001 Steinberger & Nicklass [Page 2] Internet Draft Circuit to Interface MIB May 1, 2001 Table of Contents 1. The SNMP Management Framework ............................... 4 2. Conventions ................................................. 5 3. Overview .................................................... 5 3.1. Circuit Concepts .......................................... 5 3.2. Theory of Operation ....................................... 6 3.2.1. Creation Process ........................................ 6 3.2.2. Destruction Process ..................................... 7 3.2.2.1. Manual Row Destruction ................................ 7 3.2.2.2. Automatic Row Destruction ............................. 7 3.2.3. Modification Process .................................... 7 3.2.4. Persistence of Data ..................................... 7 4. Relation to Other MIB Modules ............................... 7 4.1. Frame Relay DTE MIB ....................................... 7 4.2. Frame Relay Service MIB ................................... 8 4.3. ATM MIB ................................................... 8 4.4. Interfaces Group MIB ...................................... 8 4.4.1. Interfaces Table (ifTable, ifXtable) .................... 8 4.4.2. Stack Table (ifStackTable) .............................. 10 4.5. Other MIB Modules ......................................... 13 5. Structure of the MIB Module ................................. 13 5.1. ciCircuitTable ............................................ 13 5.2. ciIfMapTable .............................................. 13 6. Object Definitions .......................................... 13 7. Acknowledgments ............................................. 21 8. References .................................................. 22 9. Security Considerations ..................................... 25 10. Authors' Addresses ......................................... 25 11. Copyright Section .......................................... 26 Expires November 2001 Steinberger & Nicklass [Page 3] Internet Draft Circuit to Interface MIB May 1, 2001 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 November 2001 Steinberger & Nicklass [Page 4] Internet Draft Circuit to Interface MIB May 1, 2001 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 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 [24] 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. 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 1604) [18], and ATM-MIB (RFC 2515) [23]. 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 Expires November 2001 Steinberger & Nicklass [Page 5] Internet Draft Circuit to Interface MIB May 1, 2001 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 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) [23]. 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. Expires November 2001 Steinberger & Nicklass [Page 6] Internet Draft Circuit to Interface MIB May 1, 2001 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. 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 Expires November 2001 Steinberger & Nicklass [Page 7] Internet Draft Circuit to Interface MIB May 1, 2001 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. 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. 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 Expires November 2001 Steinberger & Nicklass [Page 8] Internet Draft Circuit to Interface MIB May 1, 2001 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 should not be supported and result in noSuchName. 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 should not be supported and result in noSuchName. 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 should not be supported and result in noSuchName. 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 should not be supported and result in noSuchName. 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 should not be supported and result in noSuchName. 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 should not be supported and result in noSuchName. 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 should not be supported and result in Expires November 2001 Steinberger & Nicklass [Page 9] Internet Draft Circuit to Interface MIB May 1, 2001 noSuchName. 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 should not be supported and result in noSuchName. ifInBroadcastPkts If the device does not support Broadcast packets on the circuit, this object should not be supported and result in noSuchName. ifOutBroadcastPkts If the device does not support Broadcast packets on the circuit, this object should not be supported and result in noSuchName. 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.4.2. Stack Table (ifStackTable) This section describes by example how to use ifStackTable to represent the relationship between circuit and logical link interfaces. Expires November 2001 Steinberger & Nicklass [Page 10] Internet Draft Circuit to Interface MIB May 1, 2001 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. Expires November 2001 Steinberger & Nicklass [Page 11] Internet Draft Circuit to Interface MIB May 1, 2001 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 Expires November 2001 Steinberger & Nicklass [Page 12] Internet Draft Circuit to Interface MIB May 1, 2001 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 FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB; circuitIfMIB MODULE-IDENTITY LAST-UPDATED "200105011500Z" -- May 1, 2001 Expires November 2001 Steinberger & Nicklass [Page 13] Internet Draft Circuit to Interface MIB May 1, 2001 ORGANIZATION "IETF Frame Relay Service MIB Working Group" CONTACT-INFO "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 "200005011500Z" DESCRIPTION "o Added CiCircuitSource TC and used for ciCircuitObject and ciIfMapObject. o Added recommendation to ciCircuitFlow to decribe half flow in ifDescr. o Added aging out and persistence to ciCircuitStatus. o Added ciIfLastChange and ciIfLastActive objects and the ciStatsGroup to hold these objects." REVISION "200012211500Z" DESCRIPTION "o Changed description of ciCircuitStatus to include ifTypes." REVISION "200008221500Z" DESCRIPTION "o Changed name of module to reflect that it is not to be used for frame relay only. o Changed name of all objects and edited text to remove frame relay references." REVISION "200006121500Z" DESCRIPTION "o Original Draft" ::= { mib-2 xxx } -- RFC editor - IANA assigns xxx Expires November 2001 Steinberger & Nicklass [Page 14] Internet Draft Circuit to Interface MIB May 1, 2001 -- Textual Conventions CiFlowDir ::= 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) } CiCircuitSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object identifier that uniquely describes a circuit. The object identifier should be that of the lexicograph- ically smallest accessible object in 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 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." SYNTAX OBJECT IDENTIFIER ciObjects OBJECT IDENTIFIER ::= { circuitIfMIB 1 } ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 } ciConformance OBJECT IDENTIFIER ::= { circuitIfMIB 3 } -- 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. Expires November 2001 Steinberger & Nicklass [Page 15] Internet Draft Circuit to Interface MIB May 1, 2001 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 CiCircuitSource, ciCircuitFlow CiFlowDir, ciCircuitStatus RowStatus, -- -- Data variables -- ciCircuitIfIndex InterfaceIndex, ciCircuitCreateTime TimeStamp } ciCircuitObject OBJECT-TYPE SYNTAX CiCircuitSource MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value contains the CiCircuitSource that uniquely describes the circuit that is to be added to this table." ::= { ciCircuitEntry 1 } ciCircuitFlow OBJECT-TYPE SYNTAX CiFlowDir 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 Expires November 2001 Steinberger & Nicklass [Page 16] Internet Draft Circuit to Interface MIB May 1, 2001 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 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. 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 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. Expires November 2001 Steinberger & Nicklass [Page 17] Internet Draft Circuit to Interface MIB May 1, 2001 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 "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 } -- 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." Expires November 2001 Steinberger & Nicklass [Page 18] Internet Draft Circuit to Interface MIB May 1, 2001 ::= { 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 CiCircuitSource, ciIfMapFlow CiFlowDir } ciIfMapObject OBJECT-TYPE SYNTAX CiCircuitSource MAX-ACCESS read-only STATUS current DESCRIPTION "This value contains the value of CiCircuitSource that corresponds to the current ifIndex." ::= { ciIfMapEntry 1 } ciIfMapFlow OBJECT-TYPE SYNTAX CiFlowDir 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 } Expires November 2001 Steinberger & Nicklass [Page 19] Internet Draft Circuit to Interface MIB May 1, 2001 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 SNMPv2 entities 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)." ::= { ciMIBCompliances 1 } -- -- Units of Conformance -- ciCircuitGroup OBJECT-GROUP OBJECTS { ciCircuitStatus, ciCircuitIfIndex, ciCircuitCreateTime } Expires November 2001 Steinberger & Nicklass [Page 20] Internet Draft Circuit to Interface MIB May 1, 2001 STATUS current DESCRIPTION "A collection of required objects providing information from the circuit table." ::= { ciMIBGroups 1 } ciIfMapGroup OBJECT-GROUP OBJECTS { ciIfMapObject, ciIfMapFlow } 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. Expires November 2001 Steinberger & Nicklass [Page 21] Internet Draft Circuit to Interface MIB May 1, 2001 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 November 2001 Steinberger & Nicklass [Page 22] Internet Draft Circuit to Interface MIB May 1, 2001 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", RFC 2863, Cisco Systems, Argon Networks, June 2000. [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 November 2001 Steinberger & Nicklass [Page 23] Internet Draft Circuit to Interface MIB May 1, 2001 [22]Baker, F., "IP Forwarding Table MIB", RFC 2096, Cisco Systems, January 1997. [23]Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, Bell Communications Research, February 1999. [24]Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, Lucent Technologies, May 2000. Expires November 2001 Steinberger & Nicklass [Page 24] Internet Draft Circuit to Interface MIB May 1, 2001 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. 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@rrad.co.il Expires November 2001 Steinberger & Nicklass [Page 25] Internet Draft Circuit to Interface MIB May 1, 2001 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 November 2001 Steinberger & Nicklass [Page 26]