Request for Comments: 4221 Cisco Systems, Inc.
Category: Informational C. Srinivasan
Bloomberg L.P.
A. Farrel
Old Dog Consulting
November 2005
Multiprotocol Label Switching (MPLS) Management Overview
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
A range of Management Information Base (MIB) modules has been
developed to help model and manage the various aspects of
Multiprotocol Label Switching (MPLS) networks. These MIB modules are
defined in separate documents that focus on the specific areas of
responsibility of the modules that they describe.
This document describes the management architecture for MPLS and
indicates the interrelationships between the different MIB modules
used for MPLS network management.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. The SNMP Management Framework ...................................3
4. An Introduction to the MPLS Working Group MIB Modules ...........4
4.1. Structure of the MPLS MIB OID Tree .........................5
4.2. MPLS-TC-STD-MIB ............................................5
4.3. MPLS-LSR-STD-MIB ...........................................5
4.4. MPLS-LDP-STD-MIB ...........................................6
4.5. MPLS-LDP-GENERIC-STD-MIB ...................................6
4.6. MPLS-LDP-ATM-STD-MIB .......................................6
4.7. MPLS-LDP-FRAME-RELAY-STD-MIB ...............................7
4.8. MPLS-TE-STD-MIB ............................................7
4.9. MPLS-FTN-STD-MIB ...........................................7
4.10. TE-LINK-STD-MIB ...........................................7
4.11. MIB Module Interdependencies ..............................8
4.12. Dependencies on External MIB Modules ......................9
5. Tables, Scalars, and Notifications in MPLS-LSR-STD-MIB .........10
5.1. Tables ....................................................10
5.2. Scalars ...................................................10
5.3. Indexing ..................................................11
5.4. Notifications .............................................12
5.5. Dependencies between MIB Module Tables ....................12
6. Tables, Scalars, and Notifications in the LDP MIB ..............13
6.1. MIB Modules ...............................................13
6.2. Tables ....................................................14
6.3. Scalars ...................................................15
6.4. Notifications .............................................15
6.5. Dependencies between MIB Module Tables ....................15
7. Tables, Scalars, and Notifications in MPLS-TE-STD-MIB ..........16
7.1. Tables ....................................................16
7.2. Scalars ...................................................17
7.3. Notifications .............................................18
7.4. Dependencies between MIB Module Tables ....................18
8. Tables, Scalars, and Notifications in MPLS-FTN-STD-MIB .........18
8.1. Tables ....................................................18
8.2. Scalars ...................................................19
8.3. Notifications .............................................19
8.4. Dependencies between MIB Module Tables ....................19
9. Tables and Objects in TE-LINK-STD-MIB ..........................19
9.1. Tables ....................................................19
9.2. Scalars ...................................................20
9.3. Notifications .............................................20
9.4. Dependencies between MIB Module Tables ....................20
10. Table Dependencies between MPLS MIB Modules ...................21
11. A Note on Interfaces ..........................................21
11.1. MPLS Tunnels as Interfaces ...............................21
11.2. Application of the Interfaces Group to TE Links ..........22
11.3. References to Interface MIB Objects from MPLS MIB
Modules ..................................................23
12. Management Options ............................................24
13. Related IETF MIB Modules ......................................25
13.1. PWE3 Working Group MIB Modules ...........................26
13.2. PPVPN Working Group MIB Modules ..........................26
13.2.1. PPVPN-MPLS-VPN-STD-MIB ............................26
13.3. CCAMP Working Group MIB Modules ..........................26
14. Traffic Engineering Working Group TE MIB ......................27
14.1. Choosing between TE MIB Modules ..........................27
15. Security Considerations .......................................28
16. Acknowledgements ..............................................28
17. Normative References ..........................................29
18. Informative References ........................................30
1. Introduction
This document describes the Management Architecture for Multi-
Protocol Label Switching (MPLS) [RFC3031]. In particular, it
describes how the managed objects defined in various MPLS-related
Management Information Base (MIB) documents model different aspects
of MPLS. Furthermore, this document explains the interactions and
dependencies between each of these MIB modules.
For additional information, this document also includes a brief note
on MIB modules produced by the Pseudo Wire Emulation Edge to Edge
(PWE3), Provider Provisioned Virtual Private Network (PPVPN), Common
Control and Measurement Plane (CCAMP), and Internet Traffic
Engineering (TEWG) working groups.
The document begins with a brief outline of the SNMP framework. This
is not intended to be a complete reference on SNMP, but is provided
to give context to the rest of the document and to indicate reference
material for readers that need to know more about SNMP.
This document does not propose any additions to the MPLS MIB
framework, nor define any standards for the Internet community. It
is an informational document. In all cases, the reader is advised to
turn to the document that defines the MIB module in question for
further information.
Comments should be made directly to the MPLS mailing list at
mpls@uu.net.
2. Terminology
This document uses terminology from the MPLS architecture document
[RFC3031] and the following MPLS related MIB modules: MPLS TC MIB
[TCMIB], MPLS LSR MIB [LSRMIB], MPLS TE MIB [TEMIB], MPLS LDP MIB
[LDPMIB], MPLS FTN MIB [FTNMIB], TE LINK MIB [TELMIB], and PPVPN MPLS
VPN MIB [VPNMIB].
Throughout this document hyphenated MIB names (such as MPLS-TE-STD-
MIB) should be taken to refer to specific MIB modules. Non-
hyphenated MIB names (such as MPLS LDP MIB) indicate MIB documents.
3. The SNMP 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 document 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 [RFC2580].
4. An Introduction to the MPLS Working Group MIB Modules
This section addresses the MIB documents produced by the MPLS working
group, namely MPLS TC MIB, MPLS LSR MIB, MPLS TE MIB, MPLS LDP MIB,
MPLS FTN MIB, and TE LINK MIB. The rest of this section briefly
describes the following:
- the MPLS Object Identifier (OID) tree structure and the position
of different MPLS related MIB modules on this tree;
- the purpose of each of the MIB modules within the MIB documents,
what it can be used for, and how it relates to the other MIB
modules.
Note that each MIB document contains one or more compliance
statements for the modules and objects that it defines. Therefore,
the support for the different MIB modules and objects is beyond the
scope of this document, although some recommendations are included in
the sections that follow.
4.1. Structure of the MPLS MIB OID Tree
The MPLS MIB OID tree has the following structure.
transmission -- RFC 2578 [RFC2578]
|
+- mplsStdMIB -- MPLS-TC-STD-MIB
| |
| +- mplsTCStdMIB -- MPLS-TC-STD-MIB
| |
| +- mplsLsrStdMIB -- MPLS-LSR-STD-MIB
| |
| +- mplsTeStdMIB -- MPLS-TE-STD-MIB
| |
| +- mplsLdpStdMIB -- MPLS-LDP-STD-MIB
| |
| +- mplsLdpAtmStdMIB -- MPLS-LDP-ATM-STD-MIB
| |
| +- mplsLdpFrameRelayStdMIB -- MPLS-LDP-FRAME-RELAY-STD-MIB
| |
| +- mplsLdpGenericStdMIB -- MPLS-LDP-GENERIC-STD-MIB
| |
| +- mplsFTNStdMIB -- MPLS-FTN-STD-MIB
|
+- teLinkStdMIB -- TE-LINK-STD-MIB
Note: The OIDs for MIB modules are assigned and managed by IANA.
They can be found in the referenced MIB documents.
4.2. MPLS-TC-STD-MIB
MPLS-TC-STD-MIB defines textual conventions [RFC2579] that may be
common to MPLS-related MIB modules. These conventions allow multiple
MIB modules to use the same syntax and format for a concept that is
shared between the MIB modules.
For example, labels are a central part of MPLS and need to be
presented in many of the MIB modules. The textual convention for
representing an MPLS label is defined in MPLS-TC-STD-MIB.
All of the other MPLS MIB modules import textual conventions from
this MIB module.
4.3. MPLS-LSR-STD-MIB
MPLS-LSR-STD-MIB describes managed objects for modeling an MPLS Label
Switching Router (LSR). This puts it at the heart of the management
architecture for MPLS.
This MIB module is used to model and manage the basic label switching
behavior of an MPLS LSR. It represents the label forwarding
information base (LFIB) of the LSR and provides a view of the LSPs
that are being switched by the LSR in question.
Since basic MPLS label switching is common to all MPLS applications,
this MIB module is referenced by many of the other MPLS MIB modules.
In general, MPLS-LSR-STD-MIB provides a model of incoming labels on
MPLS-enabled interfaces being mapped to outgoing labels on MPLS-
enabled interfaces via a conceptual object called an MPLS cross-
connect. MPLS cross-connect entries and their properties are
represented in MPLS-LSR-STD-MIB and are typically referenced by other
MIB modules in order to refer to the underlying MPLS LSP.
For example, MPLS-TE-STD-MIB models traffic-engineered tunnels.
These tunnels map to one or more underlying MPLS LSPs. MPLS-TE-STD-
MIB refers to the underlying LSPs by pointing to cross-connect
entries in MPLS-LSR-STD-MIB.
4.4. MPLS-LDP-STD-MIB
MPLS-LDP-STD-MIB describes managed objects used to model and manage
the MPLS Label Distribution Protocol (LDP) [RFC3036]. LDP is one of
the MPLS protocols used to distribute labels and establish LSPs.
This MIB module contains objects common to all LDP implementations.
For an LDP implementation that provides standard MIB support, this
MIB module provides the core set of objects that are needed, along
with one or more of the other LDP MIB modules from the following
sections.
4.5. MPLS-LDP-GENERIC-STD-MIB
This MIB module provides objects for managing the LDP Per Platform
Label Space and is typically implemented along with the MPLS-LDP-
STD-MIB module. This MIB Module contains tables for configuring MPLS
Generic Label Ranges. Although the LDP Specification does not
provide a way to configure Label Ranges for Generic Labels, the MIB
module does provide a way to reserve a range of generic labels
because the working group thought this was useful.
4.6. MPLS-LDP-ATM-STD-MIB
This MIB module is typically supported along with MPLS-LDP-STD-MIB by
LDP implementations if LDP uses ATM as the Layer 2 medium. Tables in
this MIB module allow for configuring LDP to use ATM.
4.7. MPLS-LDP-FRAME-RELAY-STD-MIB
This MIB module is typically supported along with MPLS-LDP-STD-MIB by
LDP implementations if LDP uses Frame Relay as the Layer 2 medium.
Tables in this MIB module allow for configuration of LDP to use Frame
Relay.
4.8. MPLS-TE-STD-MIB
MPLS-TE-STD-MIB describes managed objects that are used to model and
manage MPLS Traffic Engineered (TE) Tunnels.
This MIB module is based on a table that represents TE tunnels that
either originate from, traverse via, or terminate on the LSR in
question. The MIB module provides configuration and statistics
objects needed for TE tunnels.
4.9. MPLS-FTN-STD-MIB
MPLS-FTN-STD-MIB describes managed objects that are used to model and
manage the MPLS FEC-to-NHLFE (FTN) mappings that take place at an
ingress Label Edge Router (LER).
An LER is an LSR placed at the edge of an MPLS domain, and it passes
traffic into and out of the MPLS domain. An ingress LER is
responsible for classifying data and assigning it to a suitable LSP
or tunnel.
This classification is done using Forwarding Equivalence Classes
(FECs) that define the common attributes of data (usually packets)
that will be treated in the same way. Once data has been classified,
it can be handed off to an LSP or tunnel through the Next Hop Label
Forwarding Entry (NHLFE).
In the case of an IP-to-MPLS mapping, the FEC objects describe IP
6-tuples that represent source and destination address ranges, source
and destination port ranges, the IPv4 Protocol field or IPv6 next-
header field, and the DiffServ Code Point (DSCP).
4.10. TE-LINK-STD-MIB
TE-LINK-STD-MIB describes managed objects that are used to model and
manage TE links, including bundled links, in an MPLS network.
The TE link feature is designed to aggregate one or more similar data
channels or TE links between a pair of LSRs. A TE link is a sub-
interface capable of carrying traffic-engineered MPLS traffic.
A bundled link is a sub-interface that bonds the traffic of a group
of one or more TE links.
4.11. MIB Module Interdependencies
This section provides an overview of the relationship between the
MPLS MIB modules described above. More details of these
relationships are given below after the MIB modules have been
discussed in more detail.
The arrows in the following diagram show a ’depends on’ relationship.
A relationship "MIB module A depends on MIB module B" means that MIB
module A uses an object, object identifier, or textual convention
defined in MIB module B, or that MIB module A contains a pointer
(index or RowPointer) to an object in MIB module B.
+-------> MPLS-TC-STD-MIB
| ^
| |
| MPLS-LSR-STD-MIB <------------------+
| |
+<----------------------- MPLS-LDP-STD-MIB -->+
| ^ |
| | |
+<-- MPLS-LDP-GENERIC-STD-MIB ------>+ |
| | |
+<-- MPLS-LDP-ATM-STD-MIB ---------->+ |
| | |
+<-- MPLS-LDP-FRAME-RELAY-STD-MIB -->+ |
| |
+<------- MPLS-TE-STD-MIB ------------------->+
| ^ |
| | |
+<------- MPLS-FTN-STD-MIB ------------------>+
Thus:
- All the MPLS MIB modules depend on MPLS-TC-STD-MIB.
- MPLS-LDP-STD-MIB, MPLS-TE-STD-MIB, and MPLS-FTN-STD-MIB contain
references to objects in MPLS-LSR-STD-MIB.
- MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP-ATM-STD-MIB, and MPLS-LDP-
FRAME-RELAY-STD-MIB contain references to objects in MPLS-LDP-
STD-MIB.
- MPLS-FTN-STD-MIB contains references to objects in MPLS-TE-STD-
MIB.
Note that there is a textual convention (MplsIndexType) defined in
MPLS-LSR-STD-MIB that is imported by MPLS-LDP-STD-MIB.
4.12. Dependencies on External MIB Modules
With the exception of MPLS-TC-STD-MIB, all the MPLS MIB modules have
dependencies on the Interfaces MIB [RFC2863]. MPLS-FTN-STD-MIB
references IP-capable interfaces on which received traffic is to be
classified using indexes in the Interface Table (ifTable) of IF-MIB
[RFC2863]. The other MPLS MIB modules reference MPLS-capable
interfaces in ifTable.
The Interfaces Group of IF-MIB [RFC2863] defines generic managed
objects for managing interfaces. The MPLS MIB modules contain
media-specific extensions to the Interfaces Group for managing MPLS
interfaces.
The MPLS MIB modules assume the interpretation of the Interfaces
Group to be in accordance with [RFC2863], which states that 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, the MPLS interface is represented as
an entry in ifTable.
The interrelation of entries in ifTable is defined by the Interfaces
Stack Group defined in [RFC2863].
Additionally, MPLS-LDP-ATM-STD-MIB imports the textual convention
AtmVpIdentifier from ATM-TC-MIB to represent an ATM virtual path
identifier, whereas MPLS-LDP-FRAME-RELAY-STD-MIB imports the textual
convention DLCI from FRAME-RELAY-DTE-MIB to represent a Data Link
Channel identifier.
MPLS-LDP-STD-MIB imports the textual conventions IndexInteger and
IndexIntegerNextFree from [RFC3289], and MPLS-TE-STD-MIB imports
IndexIntegerNextFree. IndexInteger provides a standard arbitrary
index, whereas IndexIntegerNextFree is used by a management agent
that needs to select an appropriate value for an arbitrary index.
Finally, all of the MIB modules import standard textual conventions
such as integers, strings, timestamps, etc., from the MIB modules in
which they are defined. This is business as usual for a MIB module
and is not discussed further in this document.
5. Tables, Scalars, and Notifications in MPLS-LSR-STD-MIB
5.1. Tables
MPLS-LSR-STD-MIB contains the following tables.
- The interface configuration table (mplsInterfaceTable) is used for
enabling MPLS on MPLS-capable interfaces.
- The in-segment (mplsInSegmentTable) and out-segment
(mplsOutSegmentTable) tables are used to configure and monitor LSP
segments carrying data into and out of the LSR, respectively.
- The in-segment mapping table (mplsInSegmentMapTable) provides a
look-up table that enables the discovery of an in-segment in
mplsInSegmentTable from the known incoming interface and incoming
label.
- The cross-connect table (mplsXCTable) is used to associate in and
out segments in order to form a cross-connect (i.e., to represent
an LSP transiting the LSR).
- The label stack table (mplsLabelStackTable) allows the
specification of multi-label stacks to be imposed on a given LSP
at this LSR.
- The MPLS in-segment (mplsInSegmentPerfTable) and out-segment
(mplsOutSegmentPerfTable) performance tables contain objects to
measure the performance of LSPs.
- The MPLS interface performance table (mplsInterfacePerfTable) has
objects to measure MPLS performance on a per-interface basis.
5.2. Scalars
Where tables in the MIB module have arbitrary indexes, scalars are
provided to supply the next available index. This applies to
mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable, and
mplsLabelStackTable, but see the section on indexing, below.
mplsMaxLabelStackDepth defines the maximum size of a imposed label
stack supported at this LSR (and not, as the description in MPLS-
LSR-STD-MIB states, the maximum label stack depth supported by the
LSR).
mplsXCNotificationsEnable is used to enable and disable notifications
from MPLS-LSR-STD-MIB.
5.3. Indexing
Note that the indexing used by the tables in MPLS-LSR-STD-MIB is
unusual. A specific textual convention, MplsIndexType, is defined in
the MIB module and is used as the type for indexes to
mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable, and
mplsLabelStackTable. The textual convention is defined as an octet
string of between one and twenty-four octets, inclusive.
Although this convention can be used to map simple integers and so
preserve the normal indexing techniques, it may also be used to
encode more complex indexing rules that may be useful to
implementations that subdivide their label spaces according to
physical or implementation constraints (such as placing the
responsibility for a subset of labels with a line card).
Note that it would be unusual, but not impossible, to make
sophisticated use of these indexes in a write-access MIB since the
’next’ index value would be hard to determine. Thus, non-simple
values are likely only to be used in read-only MIBs in which the
indexes are generated as a result of signaling protocol
implementations or other configuration means. The formatting and
interpretation of non-simple indexes is out of the scope of the MIB
module definition and is expected to be part of the manageability
statement for a particular device. When the formatting is not known
by an agent, it should treat the index as a plain octet string
containing an integer of between one and twenty-four octets.
As described in the previous section, scalars are provided to allow
agents to discover a suitable value to use as an index when creating
a new row in one of these tables. These scalars all use a second
textual convention, MplsIndexNextType, also defined within MPLS-LSR-
STD-MIB. This textual convention allows the ’null string’, (that is,
a string of length one octet with value 0x00). The null string is
used to indicate that either write access is not supported or no more
indexes are currently available.
Note that the usage of the nextIndex scalars is such that at any time
a scalar supplies a value that is currently unused as an index to the
specific table. In order to avoid lacunae in the indexing of a table
under normal usage, implementations are recommended to change the
value in an nextIndex scalar only when the index is used (that is,
when a row is created) and not when the nextIndex scalar is read. In
a ’busy’ table, this may result in row creation attempts failing and
agents having to re-read the scalar before making a second row
creation attempt. The desire to avoid this issue is in opposition to
the desire to avoid lacunae.
5.4. Notifications
MPLS-LSR-STD-MIB can issue two notifications (if notifications are
enabled).
- mplsXCUp reports when a cross-connect becomes active.