RFC 3970
A Traffic Engineering (TE) MIB
A Traffic Engineering (TE) MIB 🦋
okay bestie, let's get into it 💖 This is RFC 3970, a Standards Track doc from January 2005, written by K. Kompella of Juniper Networks (the contact info later spells it out as Kireeti Kompella 🫶). It's part of the Network Working Group crew. The title block doesn't list anything it obsoletes or updates, so no drama there 💅
Status of This Memo 📜
ok so this is an Internet standards track protocol for the Internet community, and it's literally asking everyone for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) ✨ Also, distribution of this memo is unlimited, so share away 🌸
Copyright Notice 🎀
Copyright (C) The Internet Society (2005).
Abstract 💜
this memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The main point is that it describes managed objects for Traffic Engineered (TE) Tunnels, like Multi-Protocol Label Switched Paths 🧚
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . . 2
3. Overview of the MIB Module . . . . . . . . . . . . . . . . . . 2
3.1. Traffic Engineering Information. . . . . . . . . . . . . 3
3.2. Traffic Tunnel Information . . . . . . . . . . . . . . . 3
3.3. Path Information . . . . . . . . . . . . . . . . . . . . 3
3.4. Hop Information. . . . . . . . . . . . . . . . . . . . . 4
3.5. Relationship with Other MIB Modules. . . . . . . . . . . 4
4. Creating, Modifying, and Deleting a TE Tunnel. . . . . . . . . 4
5. MIB Specification. . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Normative References . . . . . . . . . . . . . . . . . . 40
6.2. Informative References . . . . . . . . . . . . . . . . . 40
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 441. Introduction ✨
this memo is basically the same vibe as the abstract 🌷 It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It describes managed objects for Traffic Engineered (TE) Tunnels, for example Multi-Protocol Label Switched Paths ([7], [8]). The MIB module lets you configure TE Tunnels, assign one or more paths to a Tunnel, and monitor how the Tunnel is doing, like how many octets and packets have passed through it 📊
Here's the catch 👀 As it stands, this MIB module can only be used to configure or monitor a TE Tunnel at its ingress. The ingress is then expected to use some protocol (such as RSVP-TE) to signal the other routers in the path the info they need to set up the tunnel. Extending this module for use at other points of a Tunnel is for further study 🔮
1.1. Specification of Requirements 📐
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. so yes, those caps words have real meaning, read RFC 2119 before you go wild 🙈
2. The Internet-Standard Management Framework 🗂️
if you want a detailed overview of the documents that describe the current Internet-Standard Management Framework, go check Section 7 of RFC 3410 [8] 🫶
Managed objects are accessed via a virtual information store, called the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4] 📚
3. Overview of the MIB Module 🗺️
the Traffic Engineering MIB module has four parts, bestie:
- Traffic Engineering information,
- a table of Traffic Engineering Tunnels,
- a table of Paths that tunnels take, and
- a table of Hops that make up a tunnel path.
The MIB module also has statements for minimal and full compliance. this part is important, so pay attention ✨
The following subsections give an overview of each part. All objects are mandatory. 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 💅
3.1. Traffic Engineering Information 🌈
This part has info about the Link State Protocols used to carry TE information, and the signaling protocols used to set up Traffic Tunnels. It also covers how many Traffic Tunnels have been configured and how many are operational. Plus, it has a mapping of Administrative Group numbers to names. The Administrative Group is called Resource Classes in [7] 🧠
3.2. Traffic Tunnel Information 🚇
This part is a table of Traffic Tunnels plus info about each one. That includes the Tunnel name, its configuration info, its operational info, and the active path(s) the Tunnel takes 🛤️
The configuration info covers the end points of the Traffic Tunnel and the number of configured paths for it.
The operational info covers the current state (up/down), the count of octets and packets sent on the Traffic Tunnel, how long it has been up, and how many state transitions it has had.
The operational path info covers the number of operational paths, the number of path changes, and when the last path change happened 🕰️
3.3. Path Information 🛣️
okay so a Tunnel is a logical entity. An instantiation of a Tunnel is one or more Paths, and each Path has a route (also called an Explicit Route) or a sequence of hops. A Path uses a dual index. The primary index is the Tunnel the Path belongs to, and the secondary index is the Path itself 🔢
The configured info for a Path is the constraints for the Path and a configured route. The operational info is the Path status, the computed route (the route that was computed to satisfy the constraints), and the actual path as recorded by the signaling protocol 📡
3.4. Hop Information 🦶
a Path is a sequence of hops. A hop can be loose, which means the path eventually traverses the specified node, or strict, which means the specified node and possibly the link must be the next node in the path. strict is giving very no-nonsense 😤 A hop can be specified as an IPv4 address, an IPv6 address, an Autonomous System number, or an unnumbered interface index [5].
The Hop Table has all hops for all paths on a given router. It's organized like this: there's a primary index that identifies a list of hops, and a secondary index that identifies individual hops. So to get the sequence of recorded hops for a path, you look up the path's tePathRecordedRoute, which is a primary index into the Hop Table. Then, to get the actual hops in order for the recorded path, you use a secondary index of 1, 2, ... 🧩
3.5. Relationship with Other MIB Modules 🤝
A TE Tunnel can extend objects from two other MIB modules. One is the Interfaces MIB [10], and the other is the IP Tunnel MIB [11]. The way you do this is by assigning the TE Tunnel index (teTunnelIndex) a valid ifIndex value in ifTable 💫
If a TE Tunnel is deemed an interface, a new interface object gets created and assigned an ifIndex value in ifTable. Then a TE Tunnel object is created, with teTunnelIndex set to the same value as the interface index.
If (and only if) a TE Tunnel is considered an interface, it may also be considered an IP tunnel, if the encapsulation of the TE Tunnel is IP. In that case, the interface associated with the TE Tunnel should have its ifType set to tunnel(131) 🌊
If a TE Tunnel is not considered an interface, then the TE Tunnel index (teTunnelIndex) SHOULD be set to a value at least 2^24, so that it's distinct from normal interfaces 🧱
4. Creating, Modifying, and Deleting a TE Tunnel 🛠️
ok, here's the flow ✨ To create a TE Tunnel, you first grab a free Tunnel index using the object teNextTunnelIndex. Then you create the Tunnel, including all parameters, either as createAndGo or createAndWait. After that, TE Paths for this Tunnel can be created using the teTunnelNextPathIndex object, again as createAndGo or createAndWait. A particular Path gets computed and signaled when both the Path and the enclosing Tunnel have RowStatus 'active' 🚀
To build a Path's configured route, first get a free PathHop index using teNextPathHopIndex. Then build the route hop by hop using the secondary index, setting the AddrType, Address, and HopType for each Hop. Finally, set the tePathConfiguredRoute in the Path to the PathHop index you got 🧵
Modifying certain properties of a TE Tunnel or a TE Path may require setting the RowStatus of the Tunnel (or Path) to 'notInService' before making the changes. Then you set the RowStatus of the Tunnel (or Path) back to 'active' to re-signal all Paths of the Tunnel (or the modified Path) 🔁
A TE Tunnel and all its Paths can be deleted by setting the Tunnel's RowStatus to 'destroy'. A specific Path within a Tunnel can be destroyed by setting that Path's RowStatus to 'destroy' 🗑️
5. MIB Specification 💎
this MIB module IMPORTs objects from RFCs 2578 [2], 2579 [3], 2580 [3], 3411 [6], and 3811 [5]. It also has REFERENCE clauses to RFCs 3209 [8] and 3212 [12]. Here's the module header, copied exactly because the bits matter 💅
TE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, mib-2,
Integer32, Gauge32, Counter32,
Counter64, Unsigned32, TimeTicks FROM SNMPv2-SMI
RowStatus, StorageType, TimeStamp,
TruthValue FROM SNMPv2-TC
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF
TeHopAddress, TeHopAddressType,
MplsBitRate FROM MPLS-TC-STD-MIB;
teMIB MODULE-IDENTITY
LAST-UPDATED "200501040000Z" -- 01 January 2005
ORGANIZATION "IETF Traffic Engineering Working Group"
CONTACT-INFO "
Editor: Kireeti Kompella
Postal: Juniper Networks, Inc.
1194 Mathilda Ave
Sunnyvale, CA 94089
Tel: +1 408 745 2000
E-mail: kireeti@juniper.net
The IETF Traffic Engineering Working Group is
chaired by Jim Boyle and Ed Kern.
WG Mailing List information:
General Discussion: te-wg@ops.ietf.org
To Subscribe: te-wg-request@ops.ietf.org
In Body: subscribe
Archive: ftp://ops.ietf.org/pub/lists
Comments on the MIB module should be sent to the
mailing list. The archives for this mailing list
should be consulted for previous discussion on
this MIB.
"
DESCRIPTION "The Traffic Engineering MIB module.that's the end of part 1 of 8 🌈💖 more MIB goodness is coming, stay tuned bestie 🦋
okay so the MIB keeps going and it's giving main character energy 🎀✨
Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 3970;
see the RFC itself for full legal notices.
"
-- revision history
REVISION "200501040000Z" -- 01 January 2005
DESCRIPTION "Initial version, published as RFC 3970."
::= { mib-2 122 }
-- Top level objects
teMIBNotifications OBJECT IDENTIFIER ::= { teMIB 0 }
teMIBObjects OBJECT IDENTIFIER ::= { teMIB 1 }
teMIBConformance OBJECT IDENTIFIER ::= { teMIB 2 }
-- ****************************************************************
--
-- TE MIB Objects
--
-- TE Info
teInfo OBJECT IDENTIFIER ::= { teMIBObjects 1 }
teDistProtocol OBJECT-TYPE
SYNTAX BITS {
other(0),
isis(1),
ospf(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "IGP used to distribute Traffic Engineering
information and topology to each device for the
purpose of automatic path computation. More than
one IGP may be used to distribute TE information.
"
::= { teInfo 1 }
teSignalingProto OBJECT-TYPE
SYNTAX BITS {
other(0),
rsvpte(1),
crldp(2),
static(3) -- static configuration
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Traffic Engineering signaling protocols supported
by this device. More than one protocol may be
supported.
"
REFERENCE "For a description of RSVP-TE, see RFC 3209;
for CR-LDP, see RFC 3212.
"
::= { teInfo 2 }
teNotificationEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION "If this object is true, then it enables the
generation of notifications from this MIB module.
Otherwise notifications are not generated.
"
DEFVAL { false }
::= { teInfo 3 }
teNextTunnelIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An integer that may be used as a new Index in the
teTunnelTable.
The special value of 0 indicates that no more new
entries can be created in that table.
When this MIB module is used for configuration, this
object always contains a legal value (if non-zero)
for an index that is not currently used in that
table. The Command Generator (Network Management
Application) reads this variable and uses the
(non-zero) value read when creating a new row with
an SNMP SET. When the SET is performed, the Command
Responder (agent) must determine whether the value
is indeed still unused; Two Network Management
Applications may attempt to create a row
(configuration entry) simultaneously and use the
same value. If it is currently unused, the SET
succeeds, and the Command Responder (agent) changes
the value of this object according to an
implementation-specific algorithm. If the value is
in use, however, the SET fails. The Network
Management Application must then re-read this
variable to obtain a new usable value.
"
::= { teInfo 4 }
teNextPathHopIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An integer that may be used as a new Index in the
tePathHopTable.
The special value of 0 indicates that no more new
entries can be created in that table.
When this MIB module is used for configuration, this
object always contains a legal value (if non-zero)
for an index that is not currently used in that
table. The Command Generator (Network Management
Application) reads this variable and uses the
(non-zero) value read when creating a new row with
an SNMP SET. When the SET is performed, the Command
Responder (agent) must determine whether the value
is indeed still unused; Two Network Management
Applications may attempt to create a row
(configuration entry) simultaneously and use the
same value. If it is currently unused, the SET
succeeds, and the Command Responder (agent) changes
the value of this object according to an
implementation-specific algorithm. If the value is
in use, however, the SET fails. The Network
Management Application must then re-read this
variable to obtain a new usable value.
"
::= { teInfo 5 }
teConfiguredTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Number of currently configured Tunnels."
::= { teInfo 6 }
teActiveTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Number of currently active Tunnels."
::= { teInfo 7 }
tePrimaryTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Number of currently active Tunnels running on
their primary paths.
"
::= { teInfo 8 }
teAdminGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF TeAdminGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A mapping of configured administrative groups. Each
entry represents an Administrative Group and
provides a name and index for the group.
Administrative groups are used to label links in the
Traffic Engineering topology in order to place
constraints (include and exclude) on Tunnel paths.
A groupName can only be linked to one group number.
The groupNumber is the number assigned to the
administrative group used in constraints,
such as tePathIncludeAny or tePathIncludeAll.
"
::= { teInfo 9 }
teAdminGroupEntry OBJECT-TYPE
SYNTAX TeAdminGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A mapping between a configured group number and
its human-readable name. The group number should
be between 1 and 32, inclusive. Group number n
represents bit number (n-1) in the bit vector for
Include/Exclude constraints.
All entries in this table MUST be kept in stable
storage so that they will re-appear in case of a
restart/reboot.
"
INDEX { teAdminGroupNumber }
::= { teAdminGroupTable 1 }
TeAdminGroupEntry ::=
SEQUENCE {
teAdminGroupNumber Integer32,
teAdminGroupName SnmpAdminString,
teAdminGroupRowStatus RowStatus
}
teAdminGroupNumber OBJECT-TYPE
SYNTAX Integer32 (1..32)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Index of the administrative group."
::= { teAdminGroupEntry 1 }
teAdminGroupName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Name of the administrative group."
::= { teAdminGroupEntry 2 }
teAdminGroupRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The value of this object has no effect on whether
other objects in this conceptual row can be
modified.
"
::= { teAdminGroupEntry 3 }
-- Tunnel Table
teTunnelTable OBJECT-TYPE
SYNTAX SEQUENCE OF TeTunnelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Table of Configured Traffic Tunnels."
::= { teMIBObjects 2 }
teTunnelEntry OBJECT-TYPE
SYNTAX TeTunnelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Entry containing information about a particular
Traffic Tunnel.
"
INDEX { teTunnelIndex }
::= { teTunnelTable 1 }
TeTunnelEntry ::=
SEQUENCE {
teTunnelIndex Unsigned32,
teTunnelName SnmpAdminString,
teTunnelNextPathIndex Unsigned32,
-- Conceptual row information:
teTunnelRowStatus RowStatus,
teTunnelStorageType StorageType,
-- Address information:
teTunnelSourceAddressType TeHopAddressType,
teTunnelSourceAddress TeHopAddress,
teTunnelDestinationAddressType TeHopAddressType,
teTunnelDestinationAddress TeHopAddress,
-- State/performance information:
teTunnelState INTEGER,
teTunnelDiscontinuityTimer TimeStamp,
teTunnelOctets Counter64,
teTunnelPackets Counter64,
teTunnelLPOctets Counter32,
teTunnelLPPackets Counter32,
teTunnelAge TimeTicks,
teTunnelTimeUp TimeTicks,
teTunnelPrimaryTimeUp TimeTicks,
teTunnelTransitions Counter32,
teTunnelLastTransition TimeTicks,
teTunnelPathChanges Counter32,
teTunnelLastPathChange TimeTicks,
teTunnelConfiguredPaths Gauge32,
teTunnelStandbyPaths Gauge32,
teTunnelOperationalPaths Gauge32
}
teTunnelIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A unique index that identifies a Tunnel. If the TE
Tunnel is considered an interface, then this index
must match the interface index of the corresponding
interface. Otherwise, this index must be at least
2^24, so that it does not overlap with any existing
interface index.
"
::= { teTunnelEntry 1 }
teTunnelName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Name of the Traffic Tunnel.Okay so we're still in the MIB module, and this bit is all about the tunnel's name, address, state, and counters 🎀 Some of these are read-only and some are read-create, so pay attention to the MAX-ACCESS lines 👀
Note that the name of a Tunnel MUST be unique.
When a SET request contains a name that is already
in use for another entry, then the implementation
must return an inconsistentValue error.
The value of this object cannot be changed if the
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { teTunnelEntry 2 }
teTunnelNextPathIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An integer that may be used as a new Index for the
next Path in this Tunnel.
The special value of 0 indicates that no more Paths
can be created for this Tunnel, or that no more new
entries can be created in tePathTable.
When this MIB module is used for configuration, this
object always contains a legal value (if non-zero)
for an index that is not currently used in that
table. The Command Generator (Network Management
Application) reads this variable and uses the
(non-zero) value read when creating a new row with
an SNMP SET. When the SET is performed, the Command
Responder (agent) must determine whether the value
is indeed still unused; Two Network Management
Applications may attempt to create a row
(configuration entry) simultaneously and use the
same value. If it is currently unused, the SET
succeeds, and the Command Responder (agent) changes
the value of this object according to an
implementation-specific algorithm. If the value is
in use, however, the SET fails. The Network
Management Application must then re-read this
variable to obtain a new usable value.
"
::= { teTunnelEntry 3 }
teTunnelRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
When the value of this object is 'active', then
the values for the corresponding objects
teTunnelName, teTunnelSourceAddressType,
teTunnelSourceAddress,
teTunnelDestinationAddressType, and
teTunnelDestinationAddress cannot be changed.
"
::= { teTunnelEntry 4 }
teTunnelStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need
not allow write-access to any columnar objects
in the row.
"
::= { teTunnelEntry 5 }
teTunnelSourceAddressType OBJECT-TYPE
SYNTAX TeHopAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The type of Traffic Engineered Tunnel hop address
for the source of this Tunnel. Typically, this
address type is IPv4 or IPv6, with a prefix length
of 32 or 128, respectively. If the TE Tunnel path
is being computed by a path computation server,
however, it is possible to use more flexible source
address types, such as AS numbers or prefix lengths
less than host address lengths.
The value of this object cannot be changed
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { teTunnelEntry 6 }
teTunnelSourceAddress OBJECT-TYPE
SYNTAX TeHopAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The Source Traffic Engineered Tunnel hop address of
this Tunnel.
The type of this address is determined by the value
of the corresponding teTunnelSourceAddressType.
Note that the source and destination addresses of a
Tunnel can be different address types.
The value of this object cannot be changed
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { teTunnelEntry 7 }
teTunnelDestinationAddressType OBJECT-TYPE
SYNTAX TeHopAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The type of Traffic Engineered Tunnel hop address
for the destination of this Tunnel.
The value of this object cannot be changed
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { teTunnelEntry 8 }
teTunnelDestinationAddress OBJECT-TYPE
SYNTAX TeHopAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The Destination Traffic Engineered Tunnel hop
address of this Tunnel.
The type of this address is determined by the value
of the corresponding teTunnelDestinationAddressType.
Note that source and destination addresses of a
Tunnel can be different address types.
The value of this object cannot be changed
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { teTunnelEntry 9 }
teTunnelState OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
up(2),
down(3),
testing(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The operational state of the Tunnel."
::= { teTunnelEntry 10 }
teTunnelDiscontinuityTimer OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of sysUpTime on the most recent occasion
at which any one or more of this tunnel's counters
suffered a discontinuity. The relevant counters
are teTunnelOctets, teTunnelPackets,
teTunnelLPOctets, and teTunnelLPPackets. If no such
discontinuities have occurred since the last
re-initialization of the local management subsystem
then this object contains a zero value.
"
::= { teTunnelEntry 11 }
teTunnelOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of octets that have been forwarded over
the Tunnel.
Discontinuities in the value of this counter can
occur at re-initialization of the management system,
and at other times, as indicated by the value of
teTunnelDiscontinuityTimer.
"
::= { teTunnelEntry 12 }
teTunnelPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of packets that have been forwarded over
the Tunnel.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times, as indicated by the value of
teTunnelDiscontinuityTimer.
"
::= { teTunnelEntry 13 }
teTunnelLPOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of octets that have been forwarded over
the Tunnel.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times, as indicated by the value of
teTunnelDiscontinuityTimer.
"
::= { teTunnelEntry 14 }
teTunnelLPPackets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of packets that have been forwarded over
the Tunnel.
Discontinuities in the value of this counter can
occur at re-initialization of the management system
and at other times, as indicated by the value of
teTunnelDiscontinuityTimer.
"
::= { teTunnelEntry 15 }
teTunnelAge OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The age (i.e., time from creation of this conceptual
row till now) of this Tunnel in hundredths of a
second. Note that because TimeTicks wrap in about
16 months, this value is best used in interval
measurements.
"
::= { teTunnelEntry 16 }
teTunnelTimeUp OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total time in hundredths of a second that this
Tunnel has been operational. Note that because
TimeTicks wrap in about 16 months, this value is
best used in interval measurements.
An example of usage of this object would be to
compute the percentage up time over a period of time
by obtaining values of teTunnelAge and
teTunnelTimeUp at two points in time and computing
the following ratio:
((teTunnelTimeUp2 - teTunnelTimeUp1)/
(teTunnelAge2 - teTunnelAge1)) * 100 %. In doing
so, the management station must account for
wrapping of the values of teTunnelAge and
teTunnelTimeUp between the two measurements.
"
::= { teTunnelEntry 17 }
teTunnelPrimaryTimeUp OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total time in hundredths of a second that this
Tunnel's primary path has been operational. Note
that because TimeTicks wrap in about 16 months, this
value is best used in interval measurements.
An example of usage of this field would be to
compute what percentage of time that a TE Tunnel was
on the primary path over a period of time by
computing
((teTunnelPrimaryTimeUp2 - teTunnelPrimaryTimeUp1)/
(teTunnelTimeUp2 - teTunnelTimeUp1))*100 %. In
doing so, the management station must account for
wrapping of the values of teTunnelPrimaryTimeUp and
teTunnelTimeUp between the two measurements.
"
::= { teTunnelEntry 18 }The counters are where the tunnel's history lives, bestie 📊✨ Transitions, path changes, and how many paths are configured, standby, or operational 💜
teTunnelTransitions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of operational state transitions
(up -> down and down -> up) this Tunnel has
undergone.
"
::= { teTunnelEntry 19 }
teTunnelLastTransition OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The time in hundredths of a second since the last
operational state transition occurred on this
Tunnel.
Note that if the last transition was over 16
months ago, this value will be inaccurate.
"
::= { teTunnelEntry 20 }
teTunnelPathChanges OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of path changes this Tunnel has had."
::= { teTunnelEntry 21 }
teTunnelLastPathChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The time in hundredths of a second since the last
path change occurred on this Tunnel.
Note that if the last transition was over 16
months ago, this value will be inaccurate.
Path changes may be caused by network events or by
reconfiguration that affects the path.
"
::= { teTunnelEntry 22 }
teTunnelConfiguredPaths OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of paths configured for this Tunnel."
::= { teTunnelEntry 23 }
teTunnelStandbyPaths OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of standby paths configured for this
Tunnel.
"
::= { teTunnelEntry 24 }
teTunnelOperationalPaths OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of operational paths for this Tunnel.
This includes the path currently active, as
well as operational standby paths.
"
::= { teTunnelEntry 25 }
-- ****************************************************************
--
-- Tunnel Path Table
--Okay, now we're in the Tunnel Path Table 🛤️ This is where each tunnel's paths get their own rows, and the table is indexed by both the tunnel and the path, so every path is uniquely identifiable on the router 🎀
tePathTable OBJECT-TYPE
SYNTAX SEQUENCE OF TePathEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Table of Configured Traffic Tunnels."
::= { teMIBObjects 3 }
tePathEntry OBJECT-TYPE
SYNTAX TePathEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Entry containing information about a particular
Traffic Tunnel. Each Traffic Tunnel can have zero
or more Traffic Paths.
As a Traffic Path can only exist over an existing
Traffic Tunnel, all tePathEntries with
a value of n for teTunnelIndex MUST be removed by
the implementation when the corresponding
teTunnelEntry with a value of n for teTunnelIndex
is removed.
"
INDEX { teTunnelIndex, tePathIndex }
::= { tePathTable 1 }
TePathEntry ::=
SEQUENCE {
tePathIndex Unsigned32,
tePathName SnmpAdminString,
-- Conceptual row information
tePathRowStatus RowStatus,
tePathStorageType StorageType,
-- Path properties
tePathType INTEGER,
tePathConfiguredRoute Unsigned32,
tePathBandwidth MplsBitRate,
tePathIncludeAny Unsigned32,
tePathIncludeAll Unsigned32,
tePathExclude Unsigned32,
tePathSetupPriority Integer32,
tePathHoldPriority Integer32,
tePathProperties BITS,
-- Path status
tePathOperStatus INTEGER,
tePathAdminStatus INTEGER,
tePathComputedRoute Unsigned32,
tePathRecordedRoute Unsigned32
}
tePathIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An index that uniquely identifies a path within
a Tunnel.
The combination of <teTunnelIndex, tePathIndex> thus
uniquely identifies a path among all paths on this
router.
"
::= { tePathEntry 1 }
tePathName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The name of this path.
A pathName must be unique within the set of paths
over a single tunnel. If a SET request is received
with a duplicate name, then the implementation MUST
return an inconsistentValue error.
The value of this object cannot be changed
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { tePathEntry 2 }
tePathRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
When the value of this object is 'active', then
the value of tePathName cannot be changed. All
other writable objects may be changed; however,
these changes may affect traffic going over the TE
tunnel or require the path to be computed and/or
re-signaled.
"
::= { tePathEntry 3 }
tePathStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need
not allow write-access to any columnar objects
in the row.
"
::= { tePathEntry 4 }
tePathType OBJECT-TYPE
SYNTAX INTEGER {
other(1),
primary(2),
standby(3),
secondary(4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The type for this PathEntry; i.e., whether this path
is a primary path, a standby path, or a secondary
path.
"
::= { tePathEntry 5 }
tePathConfiguredRoute OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The route that this TE path is configured to follow;
i.e., an ordered list of hops. The value of this
object gives the primary index into the Hop Table.
The secondary index is the hop count in the path, so
to get the route, one could get the first hop with
index <tePathConfiguredRoute, 1> in the Hop Table
and do a getnext to get subsequent hops.
"
::= { tePathEntry 6 }
tePathBandwidth OBJECT-TYPE
SYNTAX MplsBitRate
UNITS "Kilobits per second"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The configured bandwidth for this Tunnel,
in units of thousands of bits per second (Kbps).
"
DEFVAL { 0 }
::= { tePathEntry 7 }
tePathIncludeAny OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION "This is a configured set of administrative groups
specified as a bit vector (i.e., bit n is 1 if group
n is in the set, where n = 0 is the LSB). For each
link that this path goes through, the link must have
at least one of the groups specified in IncludeAny
to be acceptable. If IncludeAny is zero, all links
are acceptable.
"
DEFVAL { 0 }
::= { tePathEntry 8 }
tePathIncludeAll OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION "This is a configured set of administrative groups
specified as a bit vector (i.e., bit n is 1 if group
n is in the set, where n = 0 is the LSB). For each
link that this path goes through, the link must have
all of the groups specified in IncludeAll to be
acceptable. If IncludeAll is zero, all links are
acceptable.
"
DEFVAL { 0 }
::= { tePathEntry 9 }
tePathExclude OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION "This is a configured set of administrative groups
specified as a bit vector (i.e., bit n is 1 if group
n is in the set, where n = 0 is the LSB). For each
link that this path goes through, the link MUST have
groups associated with it, and the intersection of
the link's groups and the 'exclude' set MUST be
null.
"
DEFVAL { 0 }
::= { tePathEntry 10 }
tePathSetupPriority OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The setup priority configured for this path, with 0
as the highest priority and 7 as the lowest.
"
DEFVAL { 7 }
::= { tePathEntry 11 }
tePathHoldPriority OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The hold priority configured for this path, with 0
as the highest priority and 7 as the lowest.
"
DEFVAL { 0 }
::= { tePathEntry 12 }
tePathProperties OBJECT-TYPE
SYNTAX BITS {
recordRoute(0),
cspf(1),
makeBeforeBreak(2),
mergeable(3),
fastReroute(4),
protected(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The set of configured properties for this path,
expressed as a bit map. For example, if the path
supports 'make before break', then bit 2 is set.
"
::= { tePathEntry 13 }Okay, bestie, we're deep in the MIB now and it is giving hop-by-hop realness 🦋 Path status, admin status, and the routes themselves all live right here. Let's go 💅
tePathOperStatus OBJECT-TYPE
SYNTAX INTEGER {
unknown(0),
down(1),
testing(2),
dormant(3),
ready(4),
operational(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The operational status of the path:
unknown:
down: Signaling failed.
testing: Administratively set aside for testing.
dormant: Not signaled (for a backup tunnel).
ready: Signaled but not yet carrying traffic.
operational: Signaled and carrying traffic.
"
::= { tePathEntry 14 }
tePathAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
normal(1),
testing(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The operational status of the path:
normal: Used normally for forwarding.
testing: Administratively set aside for testing.
"
::= { tePathEntry 15 }
tePathComputedRoute OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The route computed for this path, perhaps using
some form of Constraint-based Routing. The
algorithm is implementation dependent.
This object returns the computed route as an ordered
list of hops. The value of this object gives the
primary index into the Hop Table. The secondary
index is the hop count in the path, so to get the
route, one could get the first hop with index
<tePathComputedRoute, 1> in the Hop Table and do a
getnext to get subsequent hops.
A value of zero (0) means there is no computedRoute.
"
::= { tePathEntry 16 }
tePathRecordedRoute OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The route actually used for this path, as recorded
by the signaling protocol. This is again an ordered
list of hops; each hop is expected to be strict.
The value of this object gives the primary index
into the Hop Table. The secondary index is the hop
count in the path, so to get the route, one can get
the first hop with index <tePathRecordedRoute, 1>
in the Hop Table and do a getnext to get subsequent
hops.
A value of zero (0) means there is no recordedRoute.
"
::= { tePathEntry 17 }
-- ****************************************************************
--
-- Tunnel Path Hop Table
--So the path status is basically a little mood ring for the tunnel: down means signaling failed 💀, dormant is a backup tunnel chilling until it's needed 🌙, and operational means it's signaled AND carrying traffic, the full glow-up 🌟. The admin status is separate, with normal for everyday forwarding and testing for when someone has set the path aside on purpose 🧪.
The routes are where it gets iconic. The computed route is what the path planned to do, the recorded route is what actually got used, and both are handed out as a primary index into the Hop Table with a secondary hop count, so you grab hop 1 and then getnext your way down the list 🦋 A value of zero just means there's no route to show you, which is very on-brand for "not me… not having a route" 🙈
tePathHopTable OBJECT-TYPE
SYNTAX SEQUENCE OF TePathHopEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Table of Tunnel Path Hops."
::= { teMIBObjects 4 }
tePathHopEntry OBJECT-TYPE
SYNTAX TePathHopEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Entry containing information about a particular
hop.
"
INDEX { teHopListIndex, tePathHopIndex }
::= { tePathHopTable 1 }
TePathHopEntry ::=
SEQUENCE {
teHopListIndex Unsigned32,
tePathHopIndex Unsigned32,
-- Conceptual row information
tePathHopRowStatus RowStatus,
tePathHopStorageType StorageType,
tePathHopAddrType TeHopAddressType,
tePathHopAddress TeHopAddress,
tePathHopType INTEGER
}
teHopListIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An index that identifies a list of hops. This is
the primary index to access hops.
"
::= { tePathHopEntry 1 }
tePathHopIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An index that identifies a particular hop among the
list of hops for a path. An index of i identifies
the ith hop. This is the secondary index for a hop
entry.
"
::= { tePathHopEntry 2 }
tePathHopRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
Any field in this table can be changed, even if the
value of this object is 'active'. However, such a
change may cause traffic to be rerouted or even
disrupted.
"
::= { tePathHopEntry 3 }
tePathHopStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need
not allow write-access to any columnar objects
in the row.
"
::= { tePathHopEntry 4 }
tePathHopAddrType OBJECT-TYPE
SYNTAX TeHopAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The type of Traffic Engineered Tunnel hop Address
of this hop.
The value of this object cannot be changed
if the value of the corresponding tePathRowStatus
object is 'active'.
"
::= { tePathHopEntry 5 }
tePathHopAddress OBJECT-TYPE
SYNTAX TeHopAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The Traffic Engineered Tunnel hop Address of this
hop.
The type of this address is determined by the value
of the corresponding tePathHopAddressType.
The value of this object cannot be changed
if the value of the corresponding teTunnelRowStatus
object is 'active'.
"
::= { tePathHopEntry 6 }
tePathHopType OBJECT-TYPE
SYNTAX INTEGER {
unknown(0),
loose(1),
strict(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The type of hop:
unknown:
loose: This hop is a LOOSE hop.
strict: This hop is a STRICT hop.
"
::= { tePathHopEntry 7 }
-- ****************************************************************
--
-- TE Notifications
--Now the hop table, which is basically the guest list for every path 🎀 Each hop gets its own row, keyed by a hop list index and a hop index, and each row carries its own row status, storage type, address type, and address. Heads up: changing any field can reroute or even disrupt traffic, even when the row is 'active', so treat it like a fragile friendship 😭 The address type is locked while the row is 'active', and the address itself is locked if the corresponding teTunnelRowStatus is 'active' too.
And the hop type is literally the vibe check of the route: loose means a LOOSE hop, strict means a STRICT hop, and unknown is the mystery era 🔮
teTunnelUp NOTIFICATION-TYPE
OBJECTS { teTunnelName,
tePathName } -- TunnelPath
STATUS current
DESCRIPTION "A teTunnelUp notification is generated when the
Tunnel indexed by teTunnelName transitions to the
'up' state.
A tunnel is up when at least one of its paths is up.
The tePathName is the name of the path whose
transition to up made the tunnel go up.
This notification MUST be limited to at most one
every minute, in case the tunnel flaps up and down.
"
::= { teMIBNotifications 1 }
teTunnelDown NOTIFICATION-TYPE
OBJECTS { teTunnelName,
tePathName } -- TunnelPath
STATUS current
DESCRIPTION "A teTunnelDown notification is generated when the
Tunnel indexed by teTunnelName transitions to the
'down' state.
A tunnel is up when at least one of its paths is up.
The tePathName is the name of the path whose
transition to down made the tunnel go down.
This notification MUST be limited to at most one
every minute, in case the tunnel flaps up and down.
"
::= { teMIBNotifications 2 }
teTunnelChanged NOTIFICATION-TYPE
OBJECTS { teTunnelName,
tePathName } -- toTunnelPath
STATUS current
DESCRIPTION "A teTunnelChanged notification is generated when an
active path on the Tunnel indexed by teTunnelName
changes or a new path becomes active. The value
of tePathName is the new active path.
This notification MUST be limited to at most one
every minute, in case the tunnel changes quickly.
"
::= { teMIBNotifications 3 }
teTunnelRerouted NOTIFICATION-TYPE
OBJECTS { teTunnelName,
tePathName } -- toTunnelPath
STATUS current
DESCRIPTION "A teTunnelRerouted notification is generated when
an active path for the Tunnel indexed by
teTunnelName stays the same, but its route changes.
This notification MUST be limited to at most one
every minute, in case the tunnel reroutes quickly.
"
::= { teMIBNotifications 4 }
-- End of TE-MIB objects
-- ****************************************************************
--
-- TE Compliance Statements
--
teGroups
OBJECT IDENTIFIER ::= { teMIBConformance 1 }
teModuleCompliance
OBJECT IDENTIFIER ::= { teMIBConformance 2 }
-- ****************************************************************
--
-- TE object groups
--The notifications are the group chat pings of the whole MIB 📱 teTunnelUp fires when the tunnel goes up (it's up as long as at least one path is), teTunnelDown fires when it goes down, teTunnelChanged fires when the active path swaps out, and teTunnelRerouted fires when the active path stays the same but its route shifts 🦋
Real talk, bestie: all four of these have the same one-a-minute cap, so a flapping tunnel can't spam your inbox 🙏 That's the kind of protective energy I love to see 💜
The compliance section is basically the setup for the object groups, and the groups are coming up next 🌈
okay so bestie, this is where we bundle up all the objects into neat little groups 🎀 first up is the big traffic engineering group, which holds basically every TE object in the module ✨
teTrafficEngineeringGroup OBJECT-GROUP
OBJECTS {
teTunnelName,
teTunnelNextPathIndex,
teTunnelRowStatus,
teTunnelStorageType,
teTunnelSourceAddressType,
teTunnelSourceAddress,
teTunnelDestinationAddressType,
teTunnelDestinationAddress,
teTunnelState,
teTunnelDiscontinuityTimer,
teTunnelOctets,
teTunnelPackets,
teTunnelLPOctets,
teTunnelLPPackets,
teTunnelAge,
teTunnelTimeUp,
teTunnelPrimaryTimeUp,
teTunnelTransitions,
teTunnelLastTransition,
teTunnelPathChanges,
teTunnelLastPathChange,
teTunnelConfiguredPaths,
teTunnelStandbyPaths,
teTunnelOperationalPaths,
tePathBandwidth,
tePathIncludeAny,
tePathIncludeAll,
tePathExclude,
tePathSetupPriority,
tePathHoldPriority,
tePathProperties,
tePathOperStatus,
tePathAdminStatus,
tePathComputedRoute,
tePathRecordedRoute,
teDistProtocol,
teSignalingProto,
teNotificationEnable,
teNextTunnelIndex,
teNextPathHopIndex,
teAdminGroupName,
teAdminGroupRowStatus,
teConfiguredTunnels,
teActiveTunnels,
tePrimaryTunnels,
tePathName,
tePathType,
tePathRowStatus,
tePathStorageType,
tePathConfiguredRoute,
tePathHopRowStatus,
tePathHopStorageType,
tePathHopAddrType,
tePathHopAddress,
tePathHopType
}
STATUS current
DESCRIPTION "Objects for Traffic Engineering in this MIB module."
::= { teGroups 1 }next up is the notification group, which is the squad of notifications for this module 🔔💅
teNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
teTunnelUp,
teTunnelDown,
teTunnelChanged,
teTunnelRerouted
}
STATUS current
DESCRIPTION "Notifications specified in this MIB module."
::= { teGroups 2 }now the compliance statements 🌸 this part is so iconic because it's basically the rulebook for who can claim what. there are four of them: read-only and full for regular TE devices, and read-only and full for path computation servers. let's start with the regular TE device read-only one 🦋
-- ****************************************************************
--
-- TE compliance statements
--
-- There are four compliance statements: read-only and full
-- compliance for regular TE devices, and read-only and full
-- compliance for path computation servers.
--
teModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "When this MIB module is implemented without support
for read-create (i.e., in read-only mode), then such
an implementation can claim read-only compliance.
Such a device can be monitored but cannot be
configured with this MIB module.
"
MODULE -- enclosing module, i.e., TE-MIB
MANDATORY-GROUPS {
teTrafficEngineeringGroup
}
GROUP teNotificationGroup
DESCRIPTION "Implementation of this group is optional."
OBJECT teNotificationEnable
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teAdminGroupName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teAdminGroupRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelSourceAddressType
SYNTAX TeHopAddressType { ipv4(1), ipv6(2) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required. An
implementation is only required to support
IPv4 and IPv6 host addresses."
OBJECT teTunnelSourceAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelDestinationAddressType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelDestinationAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathConfiguredRoute
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathBandwidth
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathIncludeAny
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathIncludeAll
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathExclude
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathSetupPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHoldPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathProperties
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathAdminStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopAddrType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { teModuleCompliance 1 }the read-only one is basically the "look but don't touch" version 👀 a device like this can be monitored, but it can't be configured with this MIB module. no writing allowed, bestie 🙈
now the full version for regular TE devices, the one that supports read-create and gets to do all the configuring 💜✨
teModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "When this MIB module is implemented with support for
read-create, then the implementation can claim
full compliance. Such devices can be both
monitored and configured with this MIB module.
"
MODULE -- enclosing module, i.e., TE-MIB
MANDATORY-GROUPS {
teTrafficEngineeringGroup
}
GROUP teNotificationGroup
DESCRIPTION "Implementation of this group is optional."
OBJECT teAdminGroupRowStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION "Support for notInService, createAndWait and
notReady is not required.
"
OBJECT teTunnelRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
OBJECT teTunnelSourceAddressType
SYNTAX TeHopAddressType { ipv4(1), ipv6(2) }
DESCRIPTION "Write access is required. An implementation is
only required to support IPv4 and IPv6 host
addresses.
"
OBJECT tePathRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
OBJECT tePathHopRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
::= { teModuleCompliance 2 }last but not least, the path computation server read-only compliance 🧚 this one is for servers that run path computation without read-create support, so they can be monitored but not configured with this module 🫶
teModuleServerReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "When this MIB module is implemented by a path
computation server without support for read-create
(i.e., in read-only mode), then the implementation
can claim read-only compliance. Such
a device can be monitored but cannot be
configured with this MIB module.
"
MODULE -- enclosing module, i.e., TE-MIB
MANDATORY-GROUPS {
teTrafficEngineeringGroup
}
GROUP teNotificationGroup
DESCRIPTION "Implementation of this group is optional."
OBJECT teNotificationEnable
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teAdminGroupName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teAdminGroupRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelSourceAddressType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required. A path
computation server SHOULD implement all types
of tunnel source address types.
"
OBJECT teTunnelSourceAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelDestinationAddressType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT teTunnelDestinationAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."okay so the compliance statements keep going, and this part is where the MIB module wraps up 💅
OBJECT tePathName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathConfiguredRoute
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathBandwidth
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathIncludeAny
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathIncludeAll
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathExclude
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathSetupPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHoldPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathProperties
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathAdminStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopAddrType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT tePathHopAddress
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { teModuleCompliance 3 }
teModuleServerFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "When this MIB module is implemented by a path
computation server with support for read-create,
then the implementation can claim full
compliance.
"
MODULE -- enclosing module, i.e., TE-MIB
MANDATORY-GROUPS {
teTrafficEngineeringGroup
}
GROUP teNotificationGroup
DESCRIPTION "Implementation of this group is optional."
OBJECT teAdminGroupRowStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION "Support for notInService, createAndWait, and
notReady is not required.
"
OBJECT teTunnelRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
OBJECT teTunnelSourceAddressType
DESCRIPTION "Write access is required. An implementation
of a path computation server SHOULD support all
types of tunnel source address types.
"
OBJECT tePathRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
OBJECT tePathHopRowStatus
SYNTAX RowStatus { active(1), notInService(2) }
WRITE-SYNTAX RowStatus { active(1), notInService(2),
createAndGo(4), destroy(6)
}
DESCRIPTION "Support for createAndWait and notReady is not
required.
"
::= { teModuleCompliance 4 }
END6. References 📚
6.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [5] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
- [6] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
6.2. Informative References
- [8] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
- [9] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [11] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
- [12] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
7. Security Considerations 🔐
okay this part is SERIOUS bestie, read it like it matters 😭 this MIB is all about setting up and managing Traffic Engineering tunnels, so if somebody messes with the fields in the tables teAdminGroupTable, teTunnelTable, tePathTable, and tePathHopTable, they can make tunnels flap, get tunnel paths changed, or straight up disrupt traffic. and if unauthorized people can READ these tables, they can trace traffic patterns, traffic volumes, and tunnel paths. some providers treat that as proprietary and confidential info, so yeah, guard it 🫶
there are a bunch of management objects in here with a MAX-ACCESS of read-write and/or read-create. those can be sensitive or vulnerable in some networks. doing SET operations in an insecure environment without proper protection can seriously mess with network operations. here's the rundown of which tables and objects are risky and why:
teAdminGroupTable: Changing this will affect the semantics of include
and exclude constraints, and thus traffic takes unintended routes.
teTunnelTable: Changing this affects many properties of traffic
tunnels.
tePathTable: Changing this affects the constraints (including
bandwidth) of tunnel paths, as well as the status of the path.
tePathHopTable: Changing this affects the route followed by a traffic
tunnel path.some of the readable objects here (the ones with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable depending on the network. so it's really important to control even GET and/or NOTIFY access to these, and maybe even encrypt their values when they get sent over SNMP. the tables and objects that need this care are:
teTunnelTable: Describes tunnel endpoints and traffic volumes.
tePathTable: Describes path properties.
tePathHopTable: Describes path routes.SNMP versions before SNMPv3 didn't have adequate security. even if the network itself is secure (say, by using IPSec), there's still no control over who on that secure network gets to GET or SET (read, change, create, or delete) the objects in this MIB module. it's giving unlocked door energy 🚪
it is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [9], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
and then, deploying SNMP versions before SNMPv3 is NOT RECOMMENDED. instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security. after that, it's a customer or operator responsibility to make sure the SNMP entity giving access to this MIB module is configured so only the principals (users) with legitimate rights can GET or SET (change, create, or delete) the objects. main character energy for the people in charge of locking things down 🔒✨
Acknowledgments 🫶
It was Tony Li's suggestion that the author embark on this MIB. Huge thanks to him and to Der-Hwa Gan for their input and help 🌸
Many thanks, too, to Bert Wijnen for his incredible help, both with improving the correctness, structure, and readability of the MIB module, and with the text of the RFC. Thanks also to Adrian Farrel for his detailed review 💜
Author's Address 🖊️
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.netFull Copyright Statement ©️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property ✨
okay so this section is the legal-ish bit 💅 The IETF is basically saying it takes no position on whether any Intellectual Property Rights or other rights might be claimed over the tech in this document. It also doesn't say whether any license under those rights is available, and it isn't claiming it went looking for them either 🫶
If you want the details on how the IETF handles rights in its documents, check out BCP 78 and BCP 79 📚
Any IPR disclosures that were sent to the IETF Secretariat are posted in the IETF online IPR repository at http://www.ietf.org/ipr. That's also where you'll find any assurances of licenses that have been offered. If someone tried to get a general license or permission to use those proprietary rights, implementers and users can find the result there too 🔍
The IETF also wants to hear from anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🌸
Last but not least, a big thank you to the folks keeping the RFC Editor function running! 🫶 Right now, that work is funded by the Internet Society 🌈
📦 where this page comes from
- ietf: rfc3970 2005-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms