- mplsXCDown reports when a cross-connect becomes
inactive.
5.5. Dependencies between MIB Module Tables
The tables in MPLS-LSR-STD-MIB are related as shown on the diagram
below. The arrows indicate a reference from one table to another.
Note that the various MIB tables contain two instances of pointers to
external tables that are not currently defined. Entries in an
external Traffic Parameters Table (external_Traffic_Table) are
pointed to using RowPointers from the mplsInSegmentTable
(mplsInSegmentTrafficParamPtr) and from the mplsOutSegmentTable
(mplsOutSegmentTrafficParamPtr) to allow representation of the
traffic parameters for the MPLS segment. Alternatively, the pointers
may indicate an entry in the Tunnel Resource Table
(mplsTunnelResourceTable) in MPLS-TE-STD-MIB. Similarly, an external
label table may be used to store label values if, for some reason,
they are not stored in place within the LSR MIB tables. This might
occur if extra per-label space information needs to be stored, and it
paves the way for GMPLS where labels cannot always be stored in a
32-bit value. RowPointers are used from the mplsInSegmentTable
(mplsInSegmentLabelPtr), the mplsOutSegmentTable
(mplsOutSegmentTopLabelPtr), and from the mplsLabelStackTable
(mplsLabelStackLabelPtr).
mplsInterfacePerfTable
^
|
V
mplsInterfaceTable
^ ^
mplsInSegmentMapTable | | mplsLabelStackTable
| | | ^ |
| +----+ +----+ | |
| | | | |
| | external_Traffic_Table | | |
| | ^ ^ | | |
V | | | | | |
mplsInSegmentTable mplsOutSegmentTable |
| ^ ^ ^ ^ | |
| | | | | | V
+------+ | +----> mplsXCTable <----+ | +--+
| V V |
| mplsInSegmentPerfTable mplsOutSegmentPerfTable |
| |
+--------------> external_Label_Table <-------------+
6. Tables, Scalars, and Notifications in the LDP MIB
6.1. MIB Modules
The MIB document for LDP contains four MIB modules. This structure
makes it easier for an implementation to select only those modules
that are relevant to it. The MIB Modules are MPLS-LDP-STD-MIB,
MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP-ATM-STD-MIB, and MPLS-LDP-FRAME-
RELAY-STD-MIB.
MPLS-LDP-STD-MIB defines objects that are specific to LDP without any
Layer 2 objects. MPLS-LDP-GENERIC-STD-MIB defines Layer 2 Per
Platform Label Space objects for use with MPLS-LDP-STD-MIB and for
use on Ethernet. MPLS-LDP-ATM-STD-MIB defines Layer 2 Asynchronous
Transfer Mode (ATM) objects for use with MPLS-LDP-STD-MIB. MPLS-
LDP-FRAME-RELAY-STD-MIB defines Layer 2 FRAME-RELAY objects for use
with MPLS-LDP-STD-MIB.
The MPLS-LDP-STD-MIB module provides the core support and is
typically supported along with at least one of the Layer 2 MIB
modules.
6.2. Tables
The tables in the LDP MIB for configuring the LDP behavior of an LSR
are as follows.
- The LDP Entity Table (mplsLdpEntityTable) provides a way to
configure the LSR for using LDP. There must be at least one LDP
Entity for the LSR to support LDP. Each entry/row in this table
represents a single LDP Entity.
- Several tables exist to help configure LDP’s use of labels. These
are spread through the MIB modules described in the previous
section. They are: mplsLdpEntityGenLRTable,
mplsLdpEntityAtmParmsTable and mplsLdpEntityAtmLRTable,
mplsLdpEntityFrameRelayParmsTable and mplsLdpEntityFrLRTable.
They are used to configure generic, ATM, and Frame Relay labels as
their names suggest.
- The LDP Peer Table (mplsLdpPeerTable) is a read-only table that
contains information about LDP Peers known to LDP Entities.
- The LDP Hello Adjacencies Table (mplsLdpHelloAdjacencyTable) is a
table of all adjacencies between all LDP Entities and all LDP
Peers.
- Several tables exist to monitor and control LDP sessions. The LDP
Session Table (mplsLdpSessionTable) represents sessions between an
LDP Entity and a Peer. mplsLdpAtmSesTable and
mplsLdpFrameRelaySesTable contain session information specific to
ATM.
- The MPLS LDP Session Peer Address Table (mplsLdpSesPeerAddrTable)
stores addresses learned after session initialization via Address
Message advertisement.
- The LDP FEC Table (mplsFecTable) represents FEC (Forwarding
Equivalence Class) information that may be in use on one or more
LSPs. The LDP LSP FEC Table (mplsLdpLspFecTable) shows the FECs
associated with each LSP.
- MPLS-LDP-STD-MIB has a mapping table (mplsLdpLspTable) that maps
the LDP MIB’s representation of LDP sessions to the underlying LSR
MIB’s representation of the LSPs created by these sessions, by
pointing to mplsInSegmentTable, mplsOutSegmentTable, and
mplsXCTable, respectively.
- Statistics may be gathered through the LDP Entity Statistics Table
(mplsLdpEntityStatsTable) and the LDP Session Statistics Table
(mplsLdpSesStatsTable).
6.3. Scalars
Where tables in the MIB modules have arbitrary indexes, scalars are
provided to supply the next available index. This applies to
mplsLdpEntityTable and mplsFecTable.
Two scalars exist to configure the LSR. The LSR ID is set in
mplsLdpLsrId, and the loop detection capabilities are reported in
mplsLdpLsrLoopDetectionCapable.
6.4. Notifications
MPLS-LDP-STD-MIB defines four notifications that a device can issue.
- mplsLdpInitSesThresholdExceeded is reported when the number of
Session Initialization messages exceeds a configured threshold.
- mplsLdpPVLMismatch is issued if the Path Vector Limit for a
configured Entity and Peer do not match.
- mplsLdpSessionUp and mplsLdpSessionDown report the transition of
Session state.
No scalar object is provided to enable and disable notifications from
MPLS-LDP-STD-MIB. Instead, the implementer is referred to [RFC3413].
6.5. Dependencies between MIB Module Tables
The many tables in the four LDP MIB modules are related as shown on
the diagram below. The arrows indicate a reference from one table to
another. Note that in many cases the reference is through an
augmentation of the referenced table.
mplsLdpEntityGenLRTable ------------->+
mplsLdpEntityAtmParmsTable ---------->+
mplsLdpEntityAtmLRTable ------------->+
mplsLdpEntityFrameRelayParmsTable --->+
mplsLdpEntityFrLRTable -------------->+
mplsLdpEntityStatsTable ------------->+
|
mplsLdpHelloAdjacencyTable |
| |
| mplsLdpEntityTable <--+
| ^ ^
V | |
mplsLdpPeerTable <-+- mplsLdpSesPeerAddrTable
^ |
| V
mplsLdpSessionTable
^ ^
| |
mplsLdpSesStatsTable ------+ +-- mplsLdpLspFecTable
mplsLdpAtmSesTable --------+ | | |
mplsLdpFrameRelaySesTable--+ | | V
| | mplsFecTable
| V
+-- mplsLdpLspTable
7. Tables, Scalars, and Notifications in MPLS-TE-STD-MIB
7.1. Tables
MPLS-TE-STD-MIB contains the following tables.
- The Tunnel Table (mplsTunnelTable) is used to configure and report
MPLS tunnels. Note that reporting of tunnels in this table at
transit LSRs is optional.
Entries in mplsTunnelTable are indexed by four objects. The
source and destination LSR IDs give context to the entry, and an
index (mplsTunnelIndex) identifies the tunnel itself. However,
the fourth index (mplsTunnelInstance) may give rise to some
confusion since its usage is not clearly explained.
The description says: "Uniquely identifies an instance of a
tunnel. It is useful to identify multiple instances of tunnels
for the purposes of backup and parallel tunnels." In the case of
backup tunnels, multiple instances of the same tunnel may be
defined, but only one is active at any time. Different instances
may have different properties (such as explicit routes), and one
instance may be set up to protect against failure of another.
Parallel tunnels may be used to provide load sharing or
protection.
The mplsTunnelInstancePriority object is used to indicate the
precedence of tunnels with the same LSR IDs and mplsTunnelIndex
value. The mplsTunnelPrimaryInstance object gives a quick
reference back to the preferred instance of the tunnel.
The mplsTunnelIndex value is typically signaled as the Tunnel ID,
and the mplsTunnelInstance as the LSP ID, in protocols where both
fields exist. In protocols where there is only one identifying
index (usually known as the LSP ID), only the mplsTunnelIndex is
signaled.
- The Resource Table (mplsTunnelResourceTable) is used to configure
resources to be requested on this tunnel. The CRLDP resource
table (mplsTunnelCRLDPResTable) is used to request additional
resource details that are specific to tunnels signaled using CR-
LDP.
- The routes requested, computed, and actually used for a tunnel are
found in the Tunnel Hop Table (mplsTunnelHopTable), Tunnel
Computed Hop Table (mplsTunnelCHopTable), and Tunnel Actual Hop
Table (mplsTunnelARHopTable).
- Statistics about the performance of tunnels may be gathered
through the Tunnel Performance Table (mplsTunnelPerfTable).
7.2. Scalars
Where tables in the MIB module have arbitrary indexes, scalars are
provided to supply the next available index. This applies to
mplsTunnelTable, mplsTunnelResourceTable, and mplsTunnelHopTable.
Two scalars exist to configure the support for MPLS tunnels on the
LSR. mplsTunnelTEDistProto lists the signaling methods and protocols
supported. mplsTunnelMaxHops defines the size of route that may be
configured on the LSR.
Two further scalars enhance the statistics on the LSR by counting the
number of configured (mplsTunnelConfigured) and active
(mplsTunnelActive) tunnels.
The scalar mplsTunnelNotificationMaxRate is used to control the rate
at which notifications are issued from MPLS-TE-STD-MIB. A rate of
zero means that notifications must not be issued. If notifications
would be generated faster than the configured rate, an implementation
may choose to discard notifications or to queue them for distribution
at a quieter time.
7.3. Notifications
MPLS-TE-STD-MIB defines four notifications that a device can issue.
The rate of dispatch of notifications is controlled as described in
the previous section.
- mplsTunnelUp and mplsTunnelDown report the transition of Tunnel
state.
- Rerouting and re-optimization of Tunnels paths are reported by
mplsTunnelRerouted and mplsTunnelReoptimized.
7.4. Dependencies between MIB Module Tables
The tables in MPLS-TE-STD-MIB are related as shown on the diagram
below. The arrows indicate a reference from one table to another.
mplsTunnelPerfTable
^
|
V
mplsTunnelTable
| |
V |
mplsTunnelResourceTable +--> mplsTunnelHopTable
^ |
| +--> mplsTunnelCHopTable
V |
mplsTunnelCRLDPResTable +--> mplsTunnelARHopTable
8. Tables, Scalars, and Notifications in MPLS-FTN-STD-MIB
8.1. Tables
MPLS-FTN-STD-MIB contains the following tables.
- The FEC-to-NHLFE Table (mplsFTNTable) defines the FEC to NHLFE
rules to be applied to incoming packets, and the actions to be
taken on matching packets.
- The FEC-to-NHLFE Mapping Table (mplsFTNMapTable) provides the
capability to activate FTN rules defined in the mplsFTNTable on
specific interfaces in the system.
- Performance statistics for FTN rules are found in the
mplsFTNPerfTable.
8.2. Scalars
This MIB module contains the scalars mplsFTNTableLastChanged and
mplsFTNMapTableLastChanged to indicate the last time an object
changed in mplsFTNTable and mplsFTNMapTable, respectively. Another
scalar, mplsFTNIndexNext, is used to supply the next valid index for
creating new conceptual rows in mplsFTNTable.
8.3. Notifications
There are no notifications in this MIB module.
8.4. Dependencies between MIB Module Tables
The tables in MPLS-FTN-STD-MIB are related as shown on the diagram
below. The arrows indicate a reference from one table to another.
mplsFTNTable
^
|
mplsFTNMapTable
^
|
mplsFTNPerfTable
9. Tables and Objects in TE-LINK-STD-MIB
9.1. Tables
TE-LINK-STD-MIB contains the following tables.
- The TE link table (teLinkTable) is used to specify TE links,
including bundled links, and their generic traffic-engineering
parameters.
- The TE link descriptor table (teLinkDescriptorTable) is used to
list the TE link descriptors.
- The shared risk link group (SRLG) table (teLinkSrlgTable) is used
to specify the SRLGs associated with TE links.
- The TE link bandwidth table (teLinkBandwidthTable) is used to
report priority-based bandwidth values associated with TE links.
- The component link table (componentLinkTable) is used to identify
the data-bearing component links that are associated with the TE
links and specify the data-bearing link generic traffic
engineering parameters.
- The component link descriptor table (componentLinkDescriptorTable)
is used to list the data-bearing component link descriptors.
- The component link bandwidth table (componentLinkBandwidthTable)
is used to report priority-based bandwidth values associated with
data-bearing component links.
9.2. Scalars
There are no scalars in this MIB module.
9.3. Notifications
There are no notifications in this MIB module.
9.4. Dependencies between MIB Module Tables
The tables in TE-LINK-STD-MIB are related as shown on the diagram
below. The arrows indicate a reference from one table to another.
Note that many of the associations between tables are through a
common index that is the ifIndex of the related interface.
teLinkTable
^
|
teLinkDescriptorTable ---+
|
teLinkSrlgTable ---------+
|
teLinkBandwidthTable ----+
componentLinkTable
^
|
componentLinkDescriptorTable ---+
|
componentLinkBandwidthTable ----+
10. Table Dependencies between MPLS MIB Modules
Section 4.11 gave an overview of how the MPLS MIB modules are
related. Now that the tables in the MIB modules have been
introduced, it is possible to give a more detailed diagram of these
relationships.
MPLS-TC-STD-MIB is left off the diagram because many of the MIB
module tables use textual conventions from that MIB module.
mplsLsrXCTable mplsLsrInSegmentTable
^ ^
| |
+---- mplsLdpLspTable
| |
mplsTunnelTable ------+ V
^ | mplsLsrOutSegmentTable
| |
mplsFTNTable ---------+
11. A Note on Interfaces
The Interfaces Group of IF-MIB [RFC2863] defines generic managed
objects for managing interfaces. The MPLS MIB modules make
references to interfaces so that it can be clearly determined where
the procedures managed by the MIB modules should be performed.
Additionally, the MPLS MIB modules (notably MPLS-TE-STD-MIB and TE-
LINK-STD-MIB) utilize interface stacking within the Interface Group.
11.1. MPLS Tunnels as Interfaces
MPLS-TE-STD-MIB builds on the concept of managing MPLS Tunnels as
logical interfaces. [RFC2863] states that the interfaces table
(ifTable) contains information on the managed resource’s interfaces,
and that each sub-layer below the internetwork layer of a network
interface is considered an interface. Thus, an MPLS Tunnel managed
as an interface is represented as an entry in the ifTable. The
interrelation of entries in the ifTable is defined by the Interfaces
Stack Group defined in [RFC2863].
When using MPLS Tunnels as interfaces, the interface stack table
might appear as follows:
+------------------------------------------------+
| MPLS tunnel interface ifType = mplsTunnel(150) |
+------------------------------------------------+
| MPLS interface ifType = mpls(166) |
+------------------------------------------------+
| Underlying layer |
+------------------------------------------------+
In the diagram above, "Underlying layer" refers to the ifIndex of any
interface type for which MPLS internetworking has been defined.
Examples include ATM, Frame Relay, and Ethernet.
A detailed listing of the mapping between ifTable objects and their
use for MPLS Tunnels is given in [TEMIB]. A few key objects are
listed here to provide an overview of the concepts.
Each MPLS tunnel is represented by an entry in the ifTable. Each
tunnel is therefore assigned a unique ifIndex.
The type of an interface represented by an entry in the ifTable is
indicated by the ifType object. The value that is allocated to
identify an MPLS tunnel is 150.
The ifOperStatus object reflects the actual operational status of the
MPLS tunnel and may be mapped from the mplsTunnelOperStatus object.
It may be considered convenient and good management to set the ifName
object to reflect the name of the MPLS tunnel as contained in the
mplsTunnelName object.
11.2. Application of the Interfaces Group to TE Links
TE-LINK-STD-MIB also uses interface stacking to manage TE Link
interfaces as logical interfaces. The TE Link interface is
represented as an entry in the ifTable. The interrelation of entries
in the ifTable is defined by Interfaces Stack Group defined in
[RFC2863]. When using TE Link interfaces, the interface stack table
might appear as follows:
+-------------------------------------------------------------------+
| MPLS interface ifType = mpls(166) |
| ifIndex = 1 |
+-------------------------------------------------------------------+
| TE link (bundled link) ifType = teLink(200) |
| ifIndex = 2 |
+--------------------------------+-+--------------------------------+
| TE link ifType = teLink(200) | | TE link ifType = teLink(200) |
| ifIndex = 3 | | ifIndex = 4 |
+--------------------------------+ +--------------------------------+
| Component link | | Component link |
| ifType = opticalTransport(196) | | ifType = opticalTransport(196) |
| ifIndex = 5 | | ifIndex = 6 |
+--------------------------------+ +--------------------------------+
In the above diagram, "opticalTransport" is an example of an
underlying physical interface: in this case an optical transport