Link Management Protocol (LMP) Management Information Base (MIB)
obsoleted by
- rfc-4631 — Link Management Protocol (LMP) Management Information Base (MIB)
Extracted elements (27)
Control channels are not required to be modeled as interfaces. The lmpCcIsIf flag explicitly allows implementations where control channels exist only as logical connections between LMP-capable nodes without a corresponding ifTable entry, avoiding mandatory coupling to IF-MIB.
Retransmission parameters (lmpNbrRetransmitInterval, lmpNbrRetryLimit, lmpNbrRetransmitDelta) are modeled after RFC 2914 congestion control principles; lmpNbrRetransmitDelta encodes the exponential backoff exponent so successive retransmission intervals grow as (1 + Delta)^n.
TE link information is intentionally split across three tables: ifTable (interface-specific), lmpTeLinkTable (LMP-specific), and teLinkTable in TE-LINK-STD-MIB (generic TE link data). ifIndex is the common index. This separation allows LMP-independent TE link management while avoiding duplication.
The lmpGlobalLinkVerificationInterval value should be large enough to allow the verification procedure to complete before the start of the next interval; a value of 0 disables periodic verification entirely.
The association between data-bearing links and TE links is stored in the ifStackTable of IF-MIB (RFC 2863), not in the LMP-MIB itself. The TE link protection role (primary/secondary) for component links is stored in the componentLinkTable of TE-LINK-STD-MIB (RFC 4220).
The LMP-MIB module imports from IF-MIB (RFC 2863), INET-ADDRESS-MIB (RFC 4001), and TE-LINK-STD-MIB (RFC 4220), and has REFERENCE clauses to LMP (RFC 4204), SONET/SDH encoding (RFC 4207), DWDM LMP (RFC 4209), GMPLS (RFC 3471), and congestion control (RFC 2914).
If lmpCcUnderlyingIfIndex is zero but lmpCcIsIf is true, the control channel is not associated with any underlying interface and its operational status must not be up(1), nor should it forward or receive traffic.
Implementations should save the values of persistent scalar objects (lmpAdminStatus, Hello interval defaults, lmpGlobalLinkVerificationInterval) in persistent memory so that they survive restarts or reboots.
Setting the TE link's ifAdminStatus to testing triggers LMP to start link verification on that TE link, per the lmpTeLinkEntry description.
The HelloDeadInterval parameter should be at least three times the value of HelloInterval to ensure reliable dead-channel detection.
When lmpCcIsIf is set to true(2), the control channel SHOULD be modeled as an ifEntry and provide appropriate interface stacking with ifType lmp(227) over the underlying layer.
Hello interval parameters are negotiated per control channel. lmpCcHelloInterval, lmpCcHelloIntervalMin, and lmpCcHelloIntervalMax configure the desired and acceptable range; lmpCcHelloIntervalNegotiated (read-only) reflects the result once the channel is active. The same pattern applies to HelloDeadInterval.
lmpCcSetupRole specifies whether a node takes the active(1) or passive(2) role during control channel establishment. An active node initiates establishment; a passive node waits. Two passive nodes will never establish communications.
lmpControlChannelPerfTable provides per-control-channel Counter32 objects for every LMP message type (Config, Hello, BeginVerify, EndVerify, TestStatusSuccess/Failure, LinkSummary, ChannelStatus, ChannelStatusRequest/Response) in both sent and received directions, plus retransmit counts and lmpCcCounterDiscontinuityTime.
lmpControlChannelTable configures LMP control channels. Key fields include lmpCcId (non-zero 32-bit local CC identifier), lmpCcIsIf (whether the CC is modeled as an ifEntry), lmpCcSetupRole (active or passive), lmpCcAuthentication, and negotiated/configured HelloInterval and HelloDeadInterval values.
lmpDataLinkTable associates data-bearing links (indexed by ifIndex) with their TE links. Each entry records address type and IP address for both local and remote ends, plus a remote interface identifier (lmpDataLinkRemoteIfId). The data-bearing link type is auto-populated by the node.
lmpLinkVerificationTable holds per-TE-link link verification parameters: lmpLinkVerifyInterval (Test message send rate), lmpLinkVerifyDeadInterval (observation period), lmpLinkVerifyAllLinks (verify all unallocated vs. only new links), lmpLinkVerifyTransmissionRate (bytes/sec), and lmpLinkVerifyWavelength (nanometers, 0 = per-link wavelength).
lmpLinkVerifyTransportMechanism is a BITS object that enumerates Test message transport options: payload(0), dccSectionOverheadBytes(1), dccLineOverheadBytes(2), j0Trace(3), j1Trace(4), j2Trace(5). The local node sets supported bits; the remote node selects a mechanism in the BeginVerifyAck message.
lmpNbrTable identifies remote neighbor nodes with which control channels may be established. Each entry is indexed by lmpNbrNodeId (4-octet IPv4 LmpNodeId) and carries retransmission parameters and administrative/operational status.
LmpNodeId is a 4-octet OCTET STRING textual convention representing an IPv4 Node ID in network byte order. It is used as the index for lmpNbrTable and as a foreign key in lmpTeLinkEntry and lmpControlChannelEntry.
lmpTeLinkPerfTable provides per-TE-link Counter32 performance counters mirroring the control-channel performance table for all LMP message types relevant to TE links, with lmpTeCounterDiscontinuityTime for discontinuity detection.
Retransmission behavior per neighbor is governed by three objects in lmpNbrTable: lmpNbrRetransmitInterval (initial interval, default 500 ms), lmpNbrRetryLimit (max retries, default 3; 0 = infinite), and lmpNbrRetransmitDelta (exponential backoff power, default 1), implementing RFC 2914 congestion control.
IANA assigned ifType value 227 for the LMP interface type. This value is used in ifTable entries when LMP control channels are modeled as interfaces.
The LMP-MIB module OID is registered under transmission.227, i.e., { transmission 227 }, establishing the root of the LMP managed object tree.
The LMP-MIB contains read-write and read-create objects that can affect LMP operation (e.g., enabling/disabling control channels, modifying Hello intervals, triggering link verification). Unauthorized access to these objects could disrupt traffic-engineering link management. SNMPv3 with authentication and privacy is recommended for managing this MIB.
The lmpCcOperStatus object defines six control channel states: up(1), down(2), configSnd(3) — Config sent awaiting reply, configRcv(4) — Config received, active(5), goingDown(6). Transitions follow LMP control channel establishment and teardown per RFC 4204.
The lmpTeLinkOperStatus object defines five TE link states: up(1), down(2), testing(3) — link verification in progress, init(4), degraded(5). The degraded state indicates no active control channel exists between the TE link endpoints but at least one data-bearing link remains allocated.