MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)
Extracted elements (29)
A node-configuration indirection table (mplsTunnelExtNodeConfigTable) is required because the existing mplsTunnelTable indexes LSRs with a 4-byte Unsigned32, while MPLS-TP tunnel endpoints are identified by Global_ID::Node_ID (8 bytes) or ICC_Operator_ID::Node_ID (12 bytes). The indirection maps the wider identifiers to a local 4-byte handle for backward-compatible indexing.
Although SNMP SET is no longer recommended for configuring MPLS networks (as noted in RFC 3812), certain objects in these extension MIBs are defined with MAX-ACCESS read-write or read-create to keep the extension tables consistent with the base tables they augment. Configuration examples in Section 9 illustrate expected MIB values, not a prescribed configuration method.
Rather than defining a new MPLS-TP-specific MIB module, the authors chose to extend existing MPLS TE MIB modules (RFC 3812, RFC 3813) because most attributes of MPLS TE tunnels are also applicable to MPLS-TP tunnels. This reuse avoids duplication and keeps MPLS-TP management aligned with existing MPLS management frameworks.
The local identifier range for mplsTunnelExtNodeConfigLocalId is constrained to 0–16777215 because the first valid IP address is 16777216 (1.0.0.0). This boundary allows implementations to determine whether an mplsTunnelTable Ingress/Egress LSR ID is an IP address or a locally assigned MPLS-TP identifier without an additional flag.
The string 'MPLS-TP' was intentionally omitted from the four new MIB module names (MPLS-TE-EXT-STD-MIB, MPLS-TC-EXT-STD-MIB, MPLS-ID-STD-MIB, MPLS-LSR-EXT-STD-MIB) because the modules extend MPLS MIB objects in a way that supports both MPLS-TP and other MPLS networks, not MPLS-TP exclusively.
An associated bidirectional MPLS-TP tunnel is represented by two separate unidirectional tunnel entries in mplsTunnelTable, linked to each other via mplsTunnelExtOppositeDirTnlPtr in mplsTunnelExtTable. This contrasts with a co-routed bidirectional tunnel, which may be managed by a single mplsTunnelTable entry with mplsTunnelExtOppositeDirTnlPtr set to zeroDotZero.
For signaled co-routed bidirectional tunnels (Section 9.3), intermediate and tail-end node MIB tables are populated automatically by the local management subsystem (agent) upon successful tunnel signaling; the forward and reverse mplsXCExtEntry objects are created once the respective path label information is negotiated.
The existing mplsTunnelTable (RFC 3812) supports statically configured unidirectional tunnels and dynamically configured unidirectional and co-routed bidirectional tunnels only. The extension MIBs defined here add coverage for statically configured associated and co-routed bidirectional tunnels, and dynamically signaled associated bidirectional tunnels.
The gmplsTunnelReversePerfTable (RFC 4802) should be used to supply per-tunnel packet performance information for the reverse direction of a bidirectional tunnel, supplementing the mplsTunnelPerfTable that augments mplsTunnelTable.
A Global_ID of zero is limited to entities within a single operator and MUST NOT be used across a Network-to-Network Interface (NNI). A non-zero Global_ID MUST be derived from an ASN owned by the operator.
If mplsIdGlobalId is used in mplsTunnelExtNodeConfigGlobalId for mapping Global_ID::Node_ID to a local identifier, then this object value MUST NOT be changed.
If mplsIdNodeId is used in an ICC_Operator_ID::Node_ID mapping, it MUST NOT be changed; if used in a Global_ID::Node_ID mapping, it SHOULD NOT be changed. Similarly, mplsIdCc and mplsIdIcc MUST NOT be changed once used in an ICC-based mapping.
mplsXCExtOppositeDirXCPtr cannot be modified if mplsXCRowStatus for the corresponding mplsXCTable entry is active(1). If this pointer is not set or is removed, mplsXCOperStatus should be set to down(2).
The size of the MplsGlobalId OCTET STRING MUST be zero if the Global_ID is invalid; likewise the CC string MUST be zero-length if the CC identifier is invalid, and the ICC string MUST be zero-length if the ICC identifier is invalid.
When a 2-octet ASN is used to derive a Global_ID, the two high-order octets of the 4-octet MplsGlobalId field MUST be set to zero (0x00).
MplsCcId is a 2-character TEXTUAL-CONVENTION for the ITU-T Country Code, encoded in uppercase Basic Latin (A–Z) using ITU-T T.50. A zero-length string (SIZE 0) indicates an invalid CC identifier.
MplsGlobalId is a 4-octet TEXTUAL-CONVENTION encoding the operator's Autonomous System Number (2-octet or 4-octet ASN). When derived from a 2-octet ASN, the two high-order octets MUST be zero. ASN 0 is reserved. A zero-length string indicates an invalid Global_ID.
MplsIccId is a 1–6 character TEXTUAL-CONVENTION for the ITU-T Carrier Code, encoded in uppercase alphanumeric characters (A–Z, 0–9) per ITU-T T.50. A zero-length string indicates an invalid ICC identifier.
mplsIdStdMIB (MPLS-ID-STD-MIB) exposes four scalar read-write objects — mplsIdGlobalId, mplsIdNodeId, mplsIdCc, and mplsIdIcc — that allow an operator to assign the node-level MPLS-TP identifiers (Global_ID, Node_ID, CC, ICC) used when creating entries in mplsTunnelExtNodeConfigTable.
MplsNodeId is an Unsigned32 TEXTUAL-CONVENTION for the MPLS-TP Node_ID, scoped within a Global_ID or ICC_Operator_ID. It may be derived from an IPv4 loopback address or be an arbitrary 32-bit value; the value 0 indicates an invalid Node_ID.
mplsTunnelExtNodeConfigLocalIdNext is a read-only scalar that returns the next available unused value for mplsTunnelExtNodeConfigLocalId in the range 0–16777215, or zero if no values are available, facilitating row creation without collisions.
mplsTunnelExtNodeConfigTable maps each Global_ID::Node_ID or ICC_Operator_ID::Node_ID to a unique local 4-byte identifier (0–16777215) used as the Ingress/Egress LSR ID in the existing mplsTunnelTable. Each entry is indexed by mplsTunnelExtNodeConfigLocalId and must contain a unique [Global_ID, Node_ID] or [CC::ICC, Node_ID] combination.
mplsTunnelExtNodeIccMapTable is a read-only table automatically populated when ICC-based entries are created in mplsTunnelExtNodeConfigTable. It is indexed by CC::ICC::Node_ID and returns the local identifier for use in OAM operations within ICC operator environments.
mplsTunnelExtNodeIpMapTable is a read-only table automatically populated when entries are created in mplsTunnelExtNodeConfigTable. It is indexed by Global_ID::Node_ID and returns the assigned local identifier, enabling OAM operations to look up tunnel entries from IP-compatible endpoint identifiers.
mplsTunnelExtTable sparsely extends mplsTunnelTable with MPLS-TP-specific attributes, including mplsTunnelExtOppositeDirTnlPtr (RowPointer to the reverse-direction tunnel entry), mplsTunnelExtIngressLSRLocalIdValid, and mplsTunnelExtEgressLSRLocalIdValid flags indicating whether the LSR IDs are local identifiers rather than IP addresses.
mplsXCExtTable sparsely extends mplsXCTable with two RowPointer objects: mplsXCExtTunnelPointer (read-only back-pointer to the associated tunnel entry) and mplsXCExtOppositeDirXCPtr (pointer to the cross-connect entry in the opposite direction). A zeroDotZero value for either pointer indicates no associated entry.
Four new MIB modules are registered under the IANA-maintained mplsStdMIB arc: MPLS-TC-EXT-STD-MIB at { mplsStdMIB 17 }, MPLS-ID-STD-MIB at { mplsStdMIB 18 }, MPLS-LSR-EXT-STD-MIB at { mplsStdMIB 19 }, and MPLS-TE-EXT-STD-MIB at { mplsStdMIB 20 }.
Section 14 addresses security for the four MIB modules. Objects with MAX-ACCESS read-write or read-create (e.g., mplsIdGlobalId, mplsIdNodeId, mplsXCExtOppositeDirXCPtr) can alter tunnel configuration; unauthorized writes could disrupt MPLS-TP forwarding. Implementations should enforce appropriate SNMP access control (e.g., SNMPv3 USM/VACM) to restrict write access to these objects.
MplsGlobalId is encoded as a fixed 4-octet OCTET STRING carrying a 2-octet or 4-octet ASN; for a 2-octet ASN the high two octets are zero. MplsCcId is a fixed 2-octet string (or zero-length if invalid). MplsIccId is 1–6 octets (or zero-length if invalid). All alphabetic characters use ITU-T T.50 encoding.