Definitions of Managed Objects for Circuit to Interface Translation
updated by
- rfc-9141 — Updating References to the IETF FTP Service
Extracted elements (28)
ciCircuitObject uses RowPointer (the lexicographically smallest accessible OID) rather than a media-specific index so that the same MIB module can represent circuits from any underlying protocol MIB without requiring per-protocol extensions.
ifLinkUpDownTrapEnable is set to false(2) for circuit interfaces because circuits typically have their own predefined notification mechanisms; enabling it would double the number of notifications sent for circuit state changes.
Only those circuits that actually require an ifIndex are added to the ifTable. This prevents over-populating the ifTable with unused indices, since the Interfaces Group MIB strongly recommends against adding conceptual rows for virtual circuits that do not need individual management.
The CiFlowDirection index allows a single physical circuit to have separate virtual interfaces for transmit-only and receive-only traffic, enabling directional monitoring via RMON-II without protocol modifications. Unidirectional interfaces SHOULD include a warning in ifDescr.
If frCircuitLogicalIfIndex in the Frame Relay DTE MIB is being used to represent the same circuit as a ciCircuitEntry with ciCircuitFlow=both(3), the implementation MAY use the same ifIndex for both.
The ifStackTable from IF-MIB must be populated to express layering relationships: circuit interfaces (frDlciEndPt or atmVciEndPt) sit above the frame relay service or AAL5 logical interface, which in turn sits above the physical layer interface.
Valid source tables for ciCircuitObject include frCircuitTable (FRAME-RELAY-DTE-MIB), frPVCEndptTable (FRNETSERV-MIB), and aal5VccTable (ATM-MIB), but circuits from other MIB tables are not prohibited.
A row in ciCircuitTable MUST exist in order for a row to exist in any other table in the CIRCUIT-IF-MIB module.
An entry describing the circuit MUST exist in some table prior to creating a row in ciCircuitTable. The OID used for ciCircuitObject MUST be the lexicographically smallest accessible OID that fully describes the circuit.
Any RowPointer for ciCircuitObject that would force the OBJECT IDENTIFIER of the row to exceed the legal OID size limit MUST be rejected.
For circuits used in RMON, ifType propVirtual(53) SHOULD NOT be used; a circuit-specific type such as frDlciEndPt(193) or atmVciEndPt(194) should be chosen instead.
If a device does not support per-circuit statistics, the counter objects (ifInOctets, ifInUcastPkts, ifInDiscards, ifInErrors, ifOutOctets, ifOutUcastPkts, ifOutDiscards, ifOutErrors, ifInBroadcastPkts) MUST NOT be supported and MUST return noSuchInstance.
New ifTypes defined specifically for use with this MIB module SHOULD follow the naming convention ***EndPt, consistent with existing types frDlciEndPt(193) and atmVciEndPt(194).
Rows MUST be removed from ciCircuitTable as soon as it is discovered that the associated circuits no longer exist on the device.
The ifIndex assigned to a circuit interface MUST follow the rules of the ifTable. The ifType MUST be frDlciEndPt(193) for frame relay circuits, atmVciEndPt(194) for ATM circuits, or an appropriate circuit-specific type otherwise.
The object referenced by ciCircuitObject MUST exist prior to transitioning a ciCircuitStatus row to active(1). If it subsequently ceases to exist or becomes inactive, the row SHOULD either age out or report notReady(3), with effects identical to destroy(6).
The persistence rules for ciCircuitEntry rows SHOULD follow those of the underlying circuit MIB module; for example, if the circuit is normally stored in non-volatile memory, the ciCircuitEntry SHOULD also be non-volatile.
ciCircuitObject is a RowPointer index that identifies the circuit in its native MIB table (e.g., frCircuitTable, frPVCEndptTable, aal5VccTable). It MUST be the lexicographically smallest accessible OID that fully describes the circuit.
ciCircuitStatus uses RowStatus to manage row lifecycle. When set to active(1), it triggers creation of an ifEntry and a ciIfMapEntry; when set to destroy(6), it removes those rows and may trigger cascading deletions in other tables.
ciCircuitTable is the central control table indexed by ciCircuitObject (RowPointer) and ciCircuitFlow (CiFlowDirection). It maps circuits to their assigned ifIndex values and controls insertion into the ifTable.
CiFlowDirection is a textual convention with values transmit(1), receive(2), and both(3), representing the direction of data flow through a circuit for which a virtual interface is defined.
ciIfLastChange records the sysUpTime value at the most recent change to ciCircuitStatus for any row in ciCircuitTable; ciIfNumActive (Gauge32) reports the count of currently active rows.
ciIfMapTable is indexed by ifIndex and provides a reverse mapping from ifIndex back to the circuit (ciIfMapObject as RowPointer) and its flow direction (ciIfMapFlow).
The CIRCUIT-IF-MIB module (OID mib-2 94) defines two tables—ciCircuitTable and ciIfMapTable—plus scalar objects ciIfLastChange and ciIfNumActive, enabling selective insertion of circuit interfaces into the ifTable for use by routing and monitoring MIBs.
This document uses IANA-assigned ifTypes frDlciEndPt(193) and atmVciEndPt(194) and requests that future circuit endpoint ifTypes follow the ***EndPt naming convention. No new registry is created, but the IANA ifType registry is updated by convention.
Several MIB objects have read-write or read-create access and could be exploited in a non-secure environment to disrupt network operations by creating, modifying, or deleting circuit-to-interface mappings. The use of SNMPv3 with USM (RFC 2574) and VACM (RFC 2575) is recommended to restrict access to authorized principals.
SNMPv1 provides no access control beyond community strings and should not be used in environments where circuit interface management data requires protection. Even on a network secured with IPsec, SNMPv1 offers no per-user access restrictions to MIB objects.
ciCircuitStatus follows RowStatus transitions. Creation moves a row to notInService or notReady; setting active(1) triggers ifEntry and ciIfMapEntry creation. Setting destroy(6) or loss of the referenced circuit object triggers row deletion and cascading ifTable/ciIfMapTable removal.