A Traffic Engineering (TE) MIB
updated by
- rfc-9141 — Updating References to the IETF FTP Service
Extracted elements (26)
Four compliance levels are defined: read-only and full compliance for regular TE devices, and read-only and full compliance for path computation servers. Path computation servers SHOULD support all tunnel source address types, whereas regular devices are only required to support IPv4 and IPv6 host addresses.
teNextTunnelIndex and teNextPathHopIndex provide a hint for free index values to avoid collisions when two management applications attempt to create rows simultaneously. If a SET using the hint finds the value already in use, it fails and the application must re-read the hint object.
The Hop Table uses a dual-index structure (teHopListIndex, tePathHopIndex) so that a single shared table holds hops for configured routes, computed routes, and recorded routes across all paths. A path stores a primary index (e.g., tePathRecordedRoute) and hops are fetched by walking secondary indices 1, 2, ….
The MIB module is intentionally restricted to configuring and monitoring a TE Tunnel only at its ingress. The ingress uses a signaling protocol such as RSVP-TE to propagate setup information to other routers. Extension for use at transit or egress points is left for further study.
A TE Tunnel may be integrated with the Interfaces MIB (RFC 2863) and the IP Tunnel MIB (RFC 2667) by assigning teTunnelIndex the same value as the tunnel's ifIndex. If the encapsulation is IP, ifType should be set to tunnel(131).
A tePathName must be unique within the set of paths over a single tunnel. If a SET request is received with a duplicate name, the implementation MUST return an inconsistentValue error.
All entries in teAdminGroupTable MUST be kept in stable storage so that they will re-appear in case of a restart or reboot.
All tePathEntries with a value of n for teTunnelIndex MUST be removed by the implementation when the corresponding teTunnelEntry with teTunnelIndex n is removed.
Each of the four notifications (teTunnelUp, teTunnelDown, teTunnelChanged, teTunnelRerouted) MUST be limited to at most one per minute in case the tunnel flaps or changes rapidly.
For minimal compliance, all objects MAY be implemented read-only. For full compliance, all objects must be implemented to their stated MAX-ACCESS capabilities. Notifications are optional under both compliance levels.
For tePathExclude, each link that the path traverses MUST have groups associated with it, and the intersection of the link's groups and the exclude set MUST be null.
If a TE Tunnel is not considered an interface, teTunnelIndex SHOULD be set to a value at least 2^24 so that it does not overlap with any existing ifIndex value.
It is RECOMMENDED that implementers support the SNMPv3 framework with full cryptographic mechanisms. Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED; SNMPv3 with cryptographic security SHOULD be deployed instead.
The name of a Tunnel MUST be unique. When a SET request contains a name already in use for another entry, the implementation must return an inconsistentValue error.
Four SNMP notifications are defined: teTunnelUp, teTunnelDown, teTunnelChanged (active path changes), and teTunnelRerouted (same path, route changes). All carry teTunnelName and tePathName as varbinds.
teAdminGroupTable maps administrative group numbers (1–32) to human-readable names. Group number n corresponds to bit (n-1) in the bit vector used for Include/Exclude path constraints.
tePathHopTable is indexed by <teHopListIndex, tePathHopIndex>. Each entry carries tePathHopAddrType (TeHopAddressType), tePathHopAddress (TeHopAddress), and tePathHopType (unknown/loose/strict). A path's route is retrieved by looking up the path's route index then walking secondary indices 1, 2, ….
tePathProperties is a BITS object encoding six path flags: recordRoute(0), cspf(1), makeBeforeBreak(2), mergeable(3), fastReroute(4), and protected(5).
tePathTable is indexed by <teTunnelIndex, tePathIndex> and holds path constraints (tePathBandwidth in Kbps, tePathIncludeAny, tePathIncludeAll, tePathExclude as 32-bit bit vectors, setup/hold priorities 0–7), path type (primary/standby/secondary), and references to configured, computed, and recorded routes as primary indices into tePathHopTable.
teTunnelTable contains per-tunnel configuration (source/destination address, RowStatus, StorageType) and operational counters (teTunnelOctets, teTunnelPackets as Counter64; teTunnelLPOctets, teTunnelLPPackets as Counter32) plus timing fields (teTunnelAge, teTunnelTimeUp, teTunnelPrimaryTimeUp as TimeTicks) and transition/path-change counters.
The TE-MIB module (teMIB) is structured into four parts: a teInfo subtree with global TE information, teTunnelTable for configured tunnels, tePathTable for paths within tunnels, and tePathHopTable for individual hops. The module is assigned OID mib-2 122.
The TE-MIB module (teMIB) is assigned the OID mib-2 122 under the IANA-managed mib-2 subtree, as established by this RFC.
Read access to teTunnelTable, tePathTable, and tePathHopTable reveals tunnel endpoints, traffic volumes, and path routes, which providers may consider proprietary. It is important to control GET and NOTIFY access and to encrypt object values when transmitting via SNMP.
Unauthorized modification of teAdminGroupTable, teTunnelTable, tePathTable, or tePathHopTable can cause tunnel flapping, rerouting, or traffic disruption. Changing teAdminGroupTable specifically alters the semantics of include/exclude constraints, causing traffic to follow unintended routes.
tePathOperStatus models path operational state with six values: unknown(0), down(1) — signaling failed; testing(2) — set aside; dormant(3) — not signaled (backup); ready(4) — signaled but not carrying traffic; operational(5) — signaled and carrying traffic.
teTunnelState models tunnel operational state with values: unknown(1), up(2), down(3), testing(4). A tunnel is up when at least one of its paths is up.