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 [RFC2119].
For an introduction to the concepts of MPLS, see [RFC3031]. For
further on LDP refer to [RFC3037] and [RFC3215].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
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 defined 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 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
3. Structure of the MIB Modules
This section describes the structure of the LDP MIB Modules.
There are 4 MIB Modules in this document. These MIB Modules are the
MPLS-LDP-STD-MIB, the MPLS-LDP-GENERIC-STD-MIB, the MPLS-LDP-ATM-STD-
MIB and the MPLS-LDP-FRAME-RELAY-STD-MIB. The MPLS-LDP-STD-MIB
defines objects which are common to all LDP implementations. The
MPLS-LDP-GENERIC-STD-MIB defines Layer 2 Per Platform Label Space
objects for use with the MPLS-LDP-STD-MIB. The MPLS-LDP-ATM-STD-MIB
defines Layer 2 Asynchronous Transfer Mode (ATM) objects for use with
the MPLS-LDP-STD-MIB. The MPLS-LDP-FRAME-RELAY-STD-MIB defines Layer
2 FRAME-RELAY objects for use with the MPLS-LDP-STD-MIB.
The MPLS-LDP-STD-MIB Module MUST be implemented and at least one of
the Layer 2 MIB Modules MUST be implemented by an Agent developer on
an Label Switching Router (LSR) or Label Edge Router (LER). As an
example, if a Label Switching Router (LSR) or Label Edge Router (LER)
implementation intends to support LDP utilizing a Layer 2 of
Ethernet, then the MPLS-LDP-STD-MIB and the MPLS-LDP-GENERIC-STD-MIB
Modules MUST implemented. If an LSR/LER implementation intends to
support LDP utilizing a Layer 2 of ATM, then the MPLS-LDP-STD-MIB
Module and the MPLS-LDP-ATM-MIB Module MUST be implemented. If an
LSR/LER implementation intends to support LDP utilizing a Layer 2 of
FRAME-RELAY, then the MPLS-LDP-STD-MIB Module and the MPLS-LDP-FRAME-
RELAY-STD-MIB Module MUST be implemented. An LDP implementation that
utilizes all three Layer 2 media (Ethernet, Frame-Relay, ATM) MUST
support all 4 MIB Modules. Each of the Modules will be discussed in
detail in the following sections.
There are 2 compliance statements for each MIB Module. One
compliance statement is for full compliance which allows both
configuration and monitoring via SNMP. The other compliance
statement is for read-only compliance which allows only monitoring
3.2. Future Considerations
The LDP Specification [RFC3036] does not specify the use of VPNs or
multicast for LDP, and thus, objects related to these areas have not
[RFC2684] does not describe VP merge capability and so this feature
has not been included.
These areas need to be specified in the LDP Specification or other
specifications prior to being added in this or any other MIB
3.3. Interface Indexing
Interface Indexes as specified in [RFC2863] are used in these MIB
Modules. The descriptions of the ifIndexes denote which ifIndex is
being used. The use of ifIndex is for actual existing connections.
3.4. Differences from the LDP Specification
Currently, there are 3 differences between this specification and the
LDP Specification. As described in the Introduction, this document
is almost entirely based on the LDP specification. The differences
are documented here.
The first difference is that the LDP Entity Table contains some
DEFVAL clauses which are not specified explicitly in the LDP
Specification. These values, although not documented in the LDP
Specification, are widely used by existing LDP MIB implementations
and thus, have been adopted within this MPLS-LDP-STD-MIB module.
Please note, they can certainly be changed during row creation or a
subsequent SET request.
A second difference is the mplsLdpEntityGenericLRTable in the MPLS-
LDP-GENERIC-STD-MIB Module. This table, although provided as a way
to reserve a range of generic labels, does not exist in the LDP
Specification. It was added to the MIB due to a request from the
working group and because this table was considered useful for
reserving a range of generic labels.
The third difference is documented by the TEXTUAL-CONVENTION,
MplsAtmVcIdentifier which is in the MPLS-TC-STD-MIB [RFC3811]. This
TC was added to restrict vci values to be greater than 31 as
described in RFC 3035 [RFC3035].
3.5. The MPLS-LDP-STD-MIB Module
This MIB Module contains objects which are common to all LDP
implementations. This MIB Module MUST always be implemented along
with one or more of the Layer 2 MIB Modules. This MIB Module IMPORTS
IndexInteger and IndexIntegerNextFree TEXTUAL-CONVENTIONs from
[RFC3289], and IMPORTS InetAddressPrefixLength, InetAddressType,
InetAddressInetPortNumber TEXTUAL-CONVENTIONs from [RFC3291].
The mplsLdpEntityTable table allows the Label Edge Router (LER) or
the Label Switching Router (LSR) to initiate and/or receive requests
to establish LDP sessions. As the LDP protocol distributes labels
and establishes sessions with Peers most of the tables in this module
are populated by the agent as instructed by the LDP protocol. The
exception is the mplsFecTable and the mplsLdpLspFecTable which can be
configured by the operator to specify Forwarding Equivalence Class
information for an LSP.
Some scalars and each table in the MPLS-LDP-STD-MIB Module are
described in the following subsections.
3.5.1. LDP Scalar Objects
There are several scalar objects in the LDP MIB module. The
mplsLdpLsrId is a read-only scalar object which reports Label
Switching Router's (LSR's) Identifier. This MUST be a globally
unique value, such as the 32-bit router ID assigned to the LSR.
The mplsLdpLsrLoopDetectionCapable scalar object denotes whether the
LSR is capable of supporting loop detection and if so, which form of
There are two LastChange scalar objects, mplsLdpEntityLastChange and
mplsLdpPeerLastChange. These objects give an indication of there was
a change in the number of entries in the table, or if any of the
values in the respective tables changed. Please see the object's
description for more details.
The mplsLdpEntityIndexNext scalar object is described in the next
3.5.2. The LDP Entity Table
The MPLS-LDP-STD-MIB provides objects to configure/set-up potential
LDP sessions on a specific LSR/LER. The mplsLdpEntityTable is used
to configure information which is used by the LDP protocol to setup
potential LDP Sessions.
Each entry/row in this table represents a single LDP Entity. There
is no maximum number of LDP Entities specified. However, there is an
mplsLdpEntityIndexNext object which should be retrieved by the
command generator prior to creating an LDP Entity. If the
mplsLdpEntityIndexNext object is zero, this indicates that the
LSR/LER is not able to create another LDP Entity at that time.
188.8.131.52. Changing Values After Session Establishment
One way to manually modify a session's parameters is by using SNMP to
change the MIB objects related to that session. Please note, special
care should be taken if MIB objects which are used in the MPLS LDP
Session Initialization need to be modified. If the modification of
any of these MIB variables takes place anytime after the start of
session intialization, then the entire session must be halted. Any
information learned by that session must be discarded. The objects
should then be modified, and session initialization started.
Assuming that the configuration was done correctly, then a new
session will be created.
For example, assume that an operator wishes to change the
configuration of a Label Range which is used by a Session that has
already been established. The operator should change the
mplsLdpEntityAdminStatus to "disable(2)". Setting the
mplsLdpEntityAdminStatus to "disable(2)" will cause the session to be
torn down (i.e., this will signal to LDP that it should send out tear
down messages for that session). Also, all information related to
that session should be removed from this MIB by the Agent. This
includes Peer information (i.e., relevant row in the mplsPeerTable)
and Session statistics (i.e., relevant row in the
mplsLdpSessionTable). Also, if the MPLS-LSR-STD-MIB module [RFC3813]
is implemented and the optional Mapping Table objects are
implemented, then all information related to the LSPs in this session
should be removed from these MIB modules. [For more information
please see the section on "The Mapping Tables".] At this point, the
operator could modify the Label Range. Lastly, the operator should
set the mplsLdpEntityAdminStatus to "enable(1)". At this point
session initialization should occur. The LDP Entity goes through the
Session Initialization in order to communicate the new Label Ranges
to the Peer and establish new LSPs.
3.5.3. The LDP Entity Statistics Table
The mplsLpdEntityStatsTable is a read-only table which contains
statistical information related to failed attempts to establish
sessions. Each row in this table AUGMENTS an mplsLdpEntityEntry.
This table could be used to give insight into how to reconfigure
values so that a session could be successfully established. For
example, if the mplsLdpEntityStatsSessionRejectedLRErrors Counter
object was increasing, then this would indicate that the Label Range
(LR) may need to be adjusted.
3.5.4. The LDP Peer Table
The mplsLdpPeerTable is a read-only table which contains information
about LDP Peers known to LDP Entities. In other words, the Peer
information is learned by LDP through initialization or discovery.
This table should be populated by the agent as directed by the LDP
A row in this table is related to one or more rows in the Hello
Adjacency Table and related to a single row in the Session Table.
The values in the Peer table are specific to a Peer and may or may
not be the same values used in the session. The reason is that the
Peer and Entity negotiate certain values. The Entity's values are
configured in the mplsLdpEntityTable and the Peer's values are
learned (and placed into the mplsLdpPeerTable). The
mplsLdpSessionTable shows the values used in establishing the
One example, of when the Peer's values and the Session's values may
differ is with the Peer's Path Limit information. The Peer's Path
Limit information is learned from the session initialization phase.
The actual value for the Path Vector Limit is the Peer's value and
may not be the same value that appears in the session. There could
be a mismatch in this value between the Entity and the Peer. In the
event of a mismatch, then the session will use the Path Limit set by
the Entity (and not the Peer).
The Peer Table information was placed in a separate table from the
Session information to allow for a more comprehensive and coherent
3.5.5. The LDP Session Table
The mplsLdpSessionTable is a read-only table. Each entry in this
table represents a single session between an LDP Entity and a Peer.
The mplsLdpSessionEntry AUGMENTS the mplsLdpPeerEntry.
The information in this table is learned during session
establishment. NOTE: rows in this table will appear during session
3.5.6. The LDP Session Statistics Table
The mplsLdpSessionStatsTable is a read-only table which contains
statistical information on sessions. This table AUGMENTS the
3.5.7. The LDP Hello Adjacency Table
This is a table of all adjacencies between all LDP Entities and all
LDP Peers. A Session may have one or more adjacencies. A session
should not have zero adjacencies, because this indicates that the
session has lost contact with the Peer. A session which has zero
Hello Adjacencies should be removed.
3.5.8. The LDP LSP Tables
The Label Information Base (LIB) contains information about labels
learned by the LSR. The LIB for LDP, CR-LDP and MPLS-RSVP (i.e., all
currently defined MPLS protocols) is represented in the LSR MIB
[RFC3813]. The LIB is represented by the LSR MIB's mplsXCTable (mpls
Cross Connect Table), mplsInSegmentTable (mpls In Segment Table) and
the mplsOutSegmentTable (mpls Out Segment Table). The mplsXCTable
models the cross-connection of the incoming label with a specific
outgoing label. The mplsInSegmentTable stores the incoming label's
information, and the mplsOutSegmentTable stores the outgoing label's
The LDP Session that created the LSP and the LSP's (incoming label,
outgoing label) pair along with other information is contained in the
MPLS-LSR-STD-MIB module's mplsXCTable, the mplsInSegmentTable and the
In order to utilize the MPLS-LSR-STD-MIB module's mplsXCTable,
mplsInSegmentTable and mplsOutSegmentTable for LDP LSPs, there needs
to be a mechanism to associate LDP sessions with LDP LSPs created as
a result of those LDP sessions. The mplsInSegmentLdpLspTable and
mplsOutSegmentLdpLspTable in this MIB contain information to find the
LDP LSP entries in the mplsInSegmentTable, mplsOutSegmentTable and
These two tables, the mplsInSegmentLdpLspTable and
mplsOutSegmentLdpLspTable, have been made optional in the conformance
section of the MIB. They only need to be supported if the LSR MIBs
mplsInSegmentTable, mplsOutSegmentTable and mplsXCTable are
As discussed in the section, "Changing Values after Session
Establishment", if a session is torn down, then all the information
related to this session, must be removed from the both LDP MIB and,
if implemented, from the LSR MIB.
3.5.9. The FEC Tables
The mplsLdpFecTable is a table which contains FEC (Forwarding
Equivalence Class) information. Each entry/row represents a single
FEC Element. There is also an LDP LSP FEC Table, mplsLdpLspFecTable,
which associates FECs with the LSPs.
3.5.10. The LDP Session Peer Address Table
The mplsLdpSessionPeerAddrTable is a table which extends the
mplsLdpSessionTable. This table is a read-only table which stores
Addresses learned after session initialization via Address Message
3.6. LDP Notifications
Currently, there are several notifications which are specific for
LDP. These are described in this section. There are no objects
which enable or disable notifications from being generated. RFC 3413
[RFC3413] contains MIB modules which can be implemented that will
enable or disable these notifications from being generated.
The mplsLdpInitSessionThresholdExceeded notification indicates to the
operator that there may be a misconfigured mplsLdpEntityEntry because
the session associated with this Entity is not being established, and
the Entity keeps trying to establish the session. A side effect of
this situation is that a row in the mplsLdpSessionTable may not be
reaching the operational state as indicated by the
mplsLdpSessionState object. If the value of
mplsLdpEntityInitSessionThreshold is 0 (zero) then this is equal to
specifying the value of infinity for the threshold, and the
mplsLdpInitSessionThresholdExceeded notification will never be sent.
The mplsLdpPathVectorLimitMismatch notification is generated when
there is a mismatch in the Path Vector Limits between the Entity and
Peer during session initialization. The session uses the value which
is configured as the Entity's Path Vector Limit. However, a
notification should be generated to indicate that a mismatch
occurred. For further details, please see Section 3.5.3 of the LDP
The mplsLdpSessionUp and mplsLdpSessionDown notifications are
generated when there is an appropriate change in the
mplsLdpSessionState object, e.g., when sessions change state (Up to
Down for the mplsLdpSessionDown notification, or Down to Up for the
mplsLdpSessionUp notification). There was discussion about combining
these two notifications into a single notification, however, some NMS
applications can utilize two different notifications, rather than
having to parse the varbind list of a single notification. For
example, the SessionDown is matched to a SessionUp notification more
easily by some NMS applications, than having to parse a Varbind list
in a SessionChange type of notification.
3.7. LDP Notification Frequency
LDP Notifications are expected to be few in number when LDP is
ubiquitously deployed in a relatively stable network. A notification
receiver, e.g., an NMS, that receives these notifications should not
be overwhelmed by the frequency of LDP notifications. If this
assertion proves to be inaccurate, then a throttling object to
throttle these notifications may be added to future versions of the