RFC 4221

Multiprotocol Label Switching (MPLS) Management Overview

📅 published November 2005, from ietf

RFC 4221: Multiprotocol Label Switching (MPLS) Management Overview 🎀

Okay bestie, so this one is from November 2005 and it's Informational 🌸, which means it's FYI and not a standard. The authors are T. Nadeau (Cisco Systems, Inc.), C. Srinivasan (Bloomberg L.P.), and A. Farrel (Old Dog Consulting) 💖. The header doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC ✨.

Status of This Memo ✨

This memo gives info to the Internet community. It does not specify an Internet standard of any kind 🙈. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2005) 🌈.

Abstract 🌸

So a bunch of Management Information Base (MIB) modules have been built to help model and manage all the different parts of Multiprotocol Label Switching (MPLS) networks, and they're giving separate-doc energy 💅. Each one lives in its own document and focuses on the specific area it covers 🧚.

This document is the big-picture management architecture for MPLS, and it shows how all those MIB modules are connected to each other 🔥.

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 ✨

Okay so this document walks through the Management Architecture for Multi-Protocol Label Switching (MPLS) [RFC3031] 🫶. The main thing it covers is how the managed objects in the different MPLS-related Management Information Base (MIB) documents model the different parts of MPLS 💖. It also explains how all those MIB modules interact with each other and depend on each other 🧚.

For extra info, it also has a quick note on MIB modules from 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 🌈.

It starts with a short SNMP overview. This isn't meant to be a full SNMP reference 🙈. It's just there to give you context for the rest of the doc, and to point you to where you can learn more about SNMP if you need it 📚.

This document doesn't propose any additions to the MPLS MIB framework, and it doesn't define any standards for the Internet community 💅. It's informational, full stop. In every case, go read the document that defines the MIB module you care about for the real details 🔥.

Comments should be sent straight to the MPLS mailing list at mpls@uu.net 💌.

2. Terminology 💜

This document uses terminology from the MPLS architecture document [RFC3031] and these 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] 🎀.

Here's the vibe check: hyphenated MIB names (like MPLS-TE-STD-MIB) should be taken to mean specific MIB modules 🦋. Non-hyphenated MIB names (like MPLS LDP MIB) mean the MIB documents instead 🌸.

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 through a virtual information store called the Management Information Base, or MIB 💖. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP) 🔥. Objects in the MIB get defined using the mechanisms 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 covers the MIB documents made by the MPLS working group: MPLS TC MIB, MPLS LSR MIB, MPLS TE MIB, MPLS LDP MIB, MPLS FTN MIB, and TE LINK MIB 💅. The rest of the section gives a quick rundown of these:

  • the MPLS Object Identifier (OID) tree structure and where the different MPLS-related MIB modules sit on that tree 🌳;
  • what each MIB module is for inside the MIB documents, what you can use it for, and how it relates to the other MIB modules 🫶.

Real talk: each MIB document has one or more compliance statements for the modules and objects it defines 🙈. So whether a given system supports a given MIB module or object is out of scope for this doc, even though there are a few recommendations in the sections that follow 💜.

4.1. Structure of the MPLS MIB OID Tree 🌳

The MPLS MIB OID tree looks like this 🧚:

   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 🌸. You can find them in the referenced MIB documents 📚.

4.2. MPLS-TC-STD-MIB 💖

MPLS-TC-STD-MIB defines textual conventions [RFC2579] that can be shared across MPLS-related MIB modules 🎀. They let several MIB modules use the same syntax and format for a concept they all share ✨.

For example, labels are a huge part of MPLS and show up in lots 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 their textual conventions from this MIB module 👑.

🌈 To be continued in part 2, bestie! 🌈

4.3. MPLS-LSR-STD-MIB 💜

okay so MPLS-LSR-STD-MIB is the one that describes an MPLS Label Switching Router (LSR) 👑 and honestly it's the main character of the whole MPLS management setup. Everything else kinda orbits around it. 🪐

This MIB module is how you model and manage the basic label switching behaviour of an LSR. It represents the label forwarding information base (LFIB) of the LSR and gives you a view of the LSPs being switched by that LSR. It's giving the full forwarding picture 🦋

Basic MPLS label switching is shared by every MPLS application, so lots of the other MPLS MIB modules reference this one. It's the bestie everybody depends on 🫶

In general, MPLS-LSR-STD-MIB models incoming labels on MPLS-enabled interfaces being mapped to outgoing labels on MPLS-enabled interfaces. The thing doing the mapping is a conceptual object called an MPLS cross-connect 🔁 Cross-connect entries and their properties live in this MIB module, and other MIB modules usually point to them when they need to refer to the underlying MPLS LSP. ✨

For example, MPLS-TE-STD-MIB models traffic-engineered tunnels 🎀 Those tunnels map to one or more underlying MPLS LSPs, and MPLS-TE-STD-MIB refers to those LSPs by pointing at cross-connect entries in MPLS-LSR-STD-MIB. Main character energy, literally 💅

4.4. MPLS-LDP-STD-MIB 🌸

MPLS-LDP-STD-MIB describes managed objects for modelling and managing the MPLS Label Distribution Protocol (LDP) [RFC3036]. LDP is one of the MPLS protocols used to distribute labels and set up LSPs, so it's a big deal 🔥

This MIB module holds the objects that are common to all LDP implementations. If an LDP implementation offers standard MIB support, this module gives you the core set of objects it needs, and you pair it with one or more of the other LDP MIB modules from the following sections. Think of it as the base layer 🧁

4.5. MPLS-LDP-GENERIC-STD-MIB 🧚

This MIB module provides objects for managing the LDP Per Platform Label Space, and it's usually implemented alongside MPLS-LDP-STD-MIB. It contains tables for configuring MPLS Generic Label Ranges. The LDP Specification doesn't give a way to configure label ranges for Generic Labels, but this MIB module does let you reserve a range of generic labels, because the working group thought that was useful. Honestly, a very reasonable call 🙈💜

4.6. MPLS-LDP-ATM-STD-MIB 🦋

This MIB module is usually supported along with MPLS-LDP-STD-MIB by LDP implementations that use ATM as the Layer 2 medium. Its tables let you configure LDP to use ATM 🌈

4.7. MPLS-LDP-FRAME-RELAY-STD-MIB 🍓

Same vibe as the ATM one! This MIB module is usually supported along with MPLS-LDP-STD-MIB by LDP implementations that use Frame Relay as the Layer 2 medium. Its tables let you configure LDP to use Frame Relay ✨

4.8. MPLS-TE-STD-MIB 🚀

MPLS-TE-STD-MIB describes managed objects for modelling and managing MPLS Traffic Engineered (TE) Tunnels. 🎀

It's built on a table that represents TE tunnels which either originate from, traverse via, or terminate on the LSR in question. The MIB module gives you the configuration and statistics objects that TE tunnels need. ⭐

4.9. MPLS-FTN-STD-MIB 💅

MPLS-FTN-STD-MIB describes managed objects for modelling and managing the MPLS FEC-to-NHLFE (FTN) mappings that happen at an ingress Label Edge Router (LER). 🫶

An LER is an LSR sitting at the edge of an MPLS domain, and it passes traffic into and out of that domain. An ingress LER is responsible for classifying data and assigning it to a suitable LSP or tunnel 🚪

That classification is done using Forwarding Equivalence Classes (FECs), which define the common attributes of data (usually packets) that get treated the same way. Once data is classified, it can be handed off to an LSP or tunnel through the Next Hop Label Forwarding Entry (NHLFE) 🔐

For an IP-to-MPLS mapping, the FEC objects describe IP 6-tuples. These 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). The 6-tuple is the whole vibe 👑

TE-LINK-STD-MIB describes managed objects for modelling and managing 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 that can carry 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 gives you an overview of how the MPLS MIB modules above are related. There are more details further down, once we've looked at each MIB module in more depth 🧐

The arrows in the following diagram show a 'depends on' 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. Big brain stuff, but it makes sense once you see the picture 👀

   +-------> 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 ------------------>+

So, the tea ☕:

  • 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. 🌸

Also, there's a textual convention (MplsIndexType) defined in MPLS-LSR-STD-MIB that MPLS-LDP-STD-MIB imports. Tiny detail, big impact 🙈

4.12. Dependencies on External MIB Modules 🌍

Apart from MPLS-TC-STD-MIB, all the MPLS MIB modules depend on the Interfaces MIB [RFC2863]. MPLS-FTN-STD-MIB refers to IP-capable interfaces where 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 add media-specific extensions to the Interfaces Group so you can manage MPLS interfaces 🔧

The MPLS MIB modules read the Interfaces Group according to [RFC2863]. That document says ifTable holds information on the managed resource's interfaces, and that each sub-layer below the internetwork layer of a network interface counts as an interface. So the MPLS interface shows up as an entry in ifTable 📋

The way entries in ifTable relate to each other is defined by the Interfaces Stack Group in [RFC2863] 🥞

Also, MPLS-LDP-ATM-STD-MIB imports the textual convention AtmVpIdentifier from ATM-TC-MIB to represent an ATM virtual path identifier. 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 gives you a standard arbitrary index, while IndexIntegerNextFree is used by a management agent that needs to pick an appropriate value for an arbitrary index 🔢

Finally, all of the MIB modules import standard textual conventions such as integers, strings, timestamps, and so on, from the MIB modules where they're defined. That's business as usual for a MIB module, so this document won't go into it further 💁‍♀️

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 lets you discover 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 an 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). Careful, this one is easy to mix up 🙈

mplsXCNotificationsEnable is used to enable and disable notifications from MPLS-LSR-STD-MIB. 🔔

5.3. Indexing 🎀

okay so the indexing in MPLS-LSR-STD-MIB is lowkey unusual, bestie 🙈 The MIB module defines a special textual convention called MplsIndexType, and it's the type used for the indexes of mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable, and mplsLabelStackTable. It's an octet string between one and twenty-four octets long, inclusive. 💅

This convention can map simple integers, so the normal indexing techniques still work. But it can also encode fancier indexing rules 🧚 That's useful for implementations that split their label spaces up based on physical or implementation constraints, like handing a subset of labels over to a line card.

It would be unusual, but not impossible, to get really sophisticated with these indexes in a write-access MIB, because the 'next' index value would be hard to figure out 😭 So non-simple values are likely only going to show up in read-only MIBs, where the indexes are generated by signaling protocol implementations or other configuration means. How the non-simple indexes are formatted and interpreted is out of scope for the MIB module definition. It's expected to be part of the manageability statement for a particular device ✨ And when an agent doesn't know the formatting, it should treat the index as a plain octet string containing an integer of between one and twenty-four octets. Simple and iconic 👑

As we covered in the last section, the scalars let agents find a suitable value to use as an index when they create a new row in one of these tables. Those scalars all use a second textual convention, MplsIndexNextType, which is also defined within MPLS-LSR-STD-MIB. This one allows the 'null string', which is a string of length one octet with value 0x00 🍓 The null string tells you that either write access isn't supported or there are no more indexes currently available.

One more thing, and it's a bit of a dilemma 🥺 The nextIndex scalars are used so that at any time, a scalar supplies a value that's currently unused as an index to the specific table. To avoid lacunae (gaps) in a table's indexing under normal usage, implementations are recommended to change the value in a nextIndex scalar only when the index is actually used, meaning when a row is created, and not when the nextIndex scalar is read. In a 'busy' table, this can make row creation attempts fail, so agents have to re-read the scalar before making a second row creation attempt. The desire to avoid that issue is in opposition to the desire to avoid lacunae. Tough choices, periodt 💀

5.4. Notifications 🔔

MPLS-LSR-STD-MIB can issue two notifications, but only if notifications are enabled ✨

  • mplsXCUp reports when a cross-connect becomes active. 🌸
  • mplsXCDown reports when a cross-connect becomes inactive. 🥀

5.5. Dependencies between MIB Module Tables 🦋

The tables in MPLS-LSR-STD-MIB are related the way the diagram below shows. The arrows mean a reference from one table to another. Main character diagram energy 👑

Heads up, the various MIB tables contain two instances of pointers to external tables that aren't currently defined 👀 Entries in an external Traffic Parameters Table (external_Traffic_Table) are pointed to using RowPointers from mplsInSegmentTable (mplsInSegmentTrafficParamPtr) and from mplsOutSegmentTable (mplsOutSegmentTrafficParamPtr). That's how you represent the traffic parameters for the MPLS segment. Or, alternatively, the pointers may indicate an entry in the Tunnel Resource Table (mplsTunnelResourceTable) in MPLS-TE-STD-MIB.

The other one is an external label table, which can store label values if, for some reason, they aren't stored in place within the LSR MIB tables. That might happen if extra per-label space information needs to be stored, and it paves the way for GMPLS, where labels can't always fit in a 32-bit value 🌈 RowPointers are used from mplsInSegmentTable (mplsInSegmentLabelPtr), mplsOutSegmentTable (mplsOutSegmentTopLabelPtr), and 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 the 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.

MPLS-LDP-STD-MIB 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. They're spread through the MIB modules described in the previous section. They are: mplsLdpEntityGenLRTable, mplsLdpEntityAtmParmsTable and mplsLdpEntityAtmLRTable, mplsLdpEntityFrameRelayParmsTable and mplsLdpEntityFrLRTable. They're 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. It does this 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]. Go check that one, bestie 📚

6.5. Dependencies between MIB Module Tables 🌈

The many tables in the four LDP MIB modules are related the way the diagram below shows. The arrows mean a reference from one table to another. Note that in many cases the reference goes through an augmentation of the referenced table, which is giving layered 🎀

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 🎀

okay so MPLS-TE-STD-MIB has a bunch of tables, and they're all doing very different jobs 💅

  • 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.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 💅

okay so TE-LINK-STD-MIB also uses interface stacking to handle TE Link interfaces as logical interfaces 💅 Every TE Link gets its own entry in the ifTable, and how those entries stack on each other is defined by the Interfaces Stack Group in [RFC2863]. Here's what the stack table can look like when TE Links are in play 🦋

+-------------------------------------------------------------------+
| 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 that diagram, "opticalTransport" is just standing in for an underlying physical interface, in this case an optical transport one 🌈 You can literally see TE link management and bundling in the stacking levels ✨ Two TE links each manage one optical transport link, and then those two get combined into a bundle that's managed as a single TE link interface. That TE Link interface supports MPLS, so it shows up as an MPLS interface 💖

A full breakdown of how ifTable objects map to TE Links lives in [TELMIB]. These are a few key ones to get the concept 🌸

  • Each TE Link interface is represented by a separate entry in the ifTable, with a unique ifIndex.
  • The type of an interface in the ifTable is indicated by the ifType object, and the value allocated to identify a TE Link is 200 🎀

11.3. References to Interface MIB Objects from MPLS MIB Modules

okay this part is about how the MPLS MIB modules point back at the Interface MIB stuff 🧚 MPLS-TE-STD-MIB has two objects that reference managing an MPLS tunnel as an interface. mplsTunnelIsIf is a TruthValue that tells you whether the tunnel is present in the ifTable. If the tunnel is managed as an interface, mplsTunnelIfIndex holds the ifIndex of the matching ifTable entry 🦋

MPLS-LSR-STD-MIB has a table called mplsInterfaceTable for setting up MPLS support on specific interfaces 💅 An LSR automatically creates a conceptual row here for every interface that can support MPLS and is configured for it. A row exists in this table if and only if a matching ifTable entry with ifType = mpls(166) exists, so they're very much linked 🫶 If the ifTable entry gets operationally disabled, the mplsInterfaceTable entry is deleted. While an mplsInterfaceTable entry lives, a corresponding entry is managed in mplsInterfacePerfTable, which shows performance counters for that MPLS-capable interface 📈

The ifIndex that identifies MPLS-capable interfaces is also a big deal for indexing in MPLS-LSR-STD-MIB 👑 In-segments (aka incoming LSP labels) live in mplsInSegmentTable, which is indexed by mplsInSegmentIfIndex and mplsInSegmentLabel. mplsInSegmentIfIndex is set to the ifIndex of the incoming MPLS-capable interface, and mplsInSegmentLabel identifies the incoming MPLS label. Also, mplsOutSegmentTable has an mplsOutSegmentIfIndex object that identifies the outgoing MPLS-capable interface, but it is NOT part of the table's index, which is an important detail ⭐

MPLS-LDP-STD-MIB uses ifIndex a lot to figure out which interface MPLS is active on 🍓

And in MPLS-FTN-STD-MIB, mplsFTNMapTable maps entries in mplsFTNTable to the interfaces where those mplsFTNTable entries should be activated. Interfaces are identified by their ifIndex values 🌈

12. Management Options

so this section is kind of a vibe check, because it's not the goal of this document to give instructions or advice to Management Station, Management Agent, or managed entity implementers 🙈 It's still useful to share some observations about how these MIB modules might be used to manage MPLS systems 💜

All MPLS LSPs can show up in MPLS-LSR-STD-MIB 🎀 At transit nodes they look like full cross-connects between incoming labels on incoming interfaces and outgoing labels on outgoing interfaces. At ingress or egress points the cross-connects are unbalanced, with a spoof upstream or downstream leg respectively 💅

Split and merge points of LSPs can be represented as more complex cross-connects in MPLS-LSR-STD-MIB 🦋 Similarly, bidirectional LSPs can be represented by using the same cross-connect index for both the forward and reverse cross-connections 🫶

The modules in the LDP MIB are meant for LDP and CR-LDP only 🌸 LSPs signaled some other way can conveniently be stored in mplsLdpLspTable so they're consistent with LDP-set-up LSPs, but there's not much extra value in that since the table only gives pointers into MPLS-LSR-STD-MIB ✨ If the LSPs are established with associated FECs using a signaling method other than LDP (BGP, for example), it may be worth using mplsLdpLspTable, mplsFecTable, and mplsLdpLspFecTable to correlate them 🧚

Also, if CR-LDP is the signaling protocol, there's no requirement to use the LSP-related tables in the LDP MIB, since the LSP will already be adequately represented in MPLS-TE-MIB and MPLS-LSR-STD-MIB 💖

MPLS tunnels can be represented in MPLS-TE-STD-MIB, with their cross-connects indicated in MPLS-LSR-STD-MIB 👑 Tunnels are often (though not always) set up with a series of constraints, which can be represented in MPLS-TE-STD-MIB. A distinguishing feature of a tunnel is that it has an ingress and an egress, whereas LSPs established through LDP may be end-to-end or hop-by-hop ⭐

All LSPs, tunnels and non-tunnels alike, may be established through signaling protocols that are already defined or still to be studied 🌈 LSPs can also be set up manually, with configuration commands issued to each LSR on the LSP. Those commands may use SNMP, doing SET operations on the MIB module tables and objects described here. Or configuration can go through some non-standard interface, like a Command Line or a Graphical User Interface 🍓 Configured LSPs like these can also be represented in the MIB module tables 💅

Don't let the "permanence" of LSPs mess with your head when you're picking which tables of which MIB modules to use 😭 An MPLS tunnel can have a super long life if an amnesiac user set it up, but it can also have a very short life if it's provisioned automatically to meet on-demand traffic needs 💀 Same goes for an LSP set up in response to a routing protocol (sometimes called a hop-by-hop LSP), which can be just as stable or just as unstable 🙈

this section is the broad picture of how the MIB modules from the PWE3, PPVPN, and CCAMP working groups interact with the MPLS MIB modules 🎀 It's background info and not central to this document, so don't stress 🫶

13.1. PWE3 Working Group MIB Modules

The PWE3 working group wrote [PWE3FW], which describes the framework for MIB modules within PWE3 operation 🦋 PWE3 uses MPLS as an emulated service and as a PSN service, so the MPLS MIB modules above can be leveraged. The PWE3 framework document covers how the MPLS MIB modules and the PWE3 MIB modules interact 💖

13.2. PPVPN Working Group MIB Modules

Right now the PPVPN working group hasn't covered how the MPLS MIB modules interact with its MIB modules 😬 The authors of this document hope to add a section to the PPVPN framework document [PPVPNFW] explaining these interactions later on 🌸 For the moment there are two MIB modules, [VPNMIB] and [VPNTCMIB], which we'll get into next ✨

13.2.1. PPVPN-MPLS-VPN-STD-MIB

PPVPN-MPLS-VPN-STD-MIB describes managed objects used to model and manage RFC2547bis MPLS VPNs [RFC2547Bis] 🧚 It has tables that model virtual routing forwarding entries (VRFs), along with the interfaces tied to those VRFs 👑

13.2.1.1. Position in the OID Tree

transmission -- RFC 2578 [RFC2578]
  |
  +- vpnMIB -- PPVPN-MPLS-VPN-STD-MIB

13.2.1.2. Dependencies

This MIB module doesn't currently have any direct dependencies on the MPLS MIB modules 🙌 It models MPLS VPN interfaces as entries in the Interfaces MIB's Interfaces Table (ifTable) 💅 It may get modified in the future to import textual conventions from MPLS-TC-STD-MIB ✨

A specific textual conventions MIB module, [VPNTCMIB], defines the textual conventions imported into PPVPN-MPLS-VPN-STD-MIB 🫶

13.3. CCAMP Working Group MIB Modules

The CCAMP working group is developing MIB modules for GMPLS that interact directly with the MPLS MIB modules 🌈 Alongside any MIB modules CCAMP produces, a separate CCAMP-specific Management Framework document is expected, describing how those MIB modules relate to the existing MPLS (and other) MIB modules 🍓

14. Traffic Engineering Working Group TE MIB

the TEWG has produced a traffic engineering MIB (TE-MIB) [TEWGMIB] that contains objects for monitoring traffic-engineered tunnels at their ingress points 🧚

Honestly, in a lot of ways TE-MIB holds the same info as MPLS-TE-STD-MIB 👯 Both can be used to monitor MPLS tunnels. The difference is that TE-MIB is minimalistic and works best for TE tunnels as tunnels, but it doesn't have a lot of the advanced features of MPLS-TE-STD-MIB 💅 MPLS-TE-STD-MIB can break tunnels down into hop-by-hop cross-connects, which is powerful but more complex 🔥

The TE-MIB module imports textual conventions from the MPLS-TC-STD-MIB module, so it depends on that document 💖

14.1. Choosing between TE MIB Modules

Okay bestie, so TE-MIB is a super flexible MIB module built to manage traffic engineering tunnels no matter what implementation tech is underneath 🦋 But flexibility plus simplicity means some compromises 💅

  • Some MPLS configuration parameters are just left out 🙈 For example, resource management in TE-MIB is only about bandwidth, so you're missing the full IntServ control.
  • Other TE-MIB parameters are there, but with limited options. For example, you can't configure different label distribution methods per LSP 💀

Extending TE-MIB to related concepts (like DiffServ and Fast Reroute) and integrating it with other MIB modules (like the one in MPLS-LSR-STD-MIB) are not work items at the time of writing. The MPLS MIB modules are more closely integrated, as described in this document ✨

Write/create access to TE-MIB is only available at the ingress 🎀 That's where you can tell an ingress to signal a tunnel with constraints. You cannot use it to configure hop-by-hop cross-connects to build a tunnel.

The whole point of TE-MIB is to let a Management Agent configure tunnels, and to inspect and monitor all tunnels (however they were created) at their ingress points. It does NOT give you info about tunnels at any other point in the network, like transit or egress nodes 🧚 For example, you can configure a tunnel's constraints, and then the ingress computes the tunnel path and signals it. After that, you can use the MIB module at the ingress to keep an eye on the tunnel's path(s), their status, uptime, and counters 👑 This MIB module is not designed to configure hop-by-hop cross-connects to build a tunnel.

15. Security Considerations 🔐

Okay, this part is serious, so listen up 💜 This document just explains how the different MIB modules relevant to MPLS management relate to each other. So on its own, it doesn't have any security implications.

Each specific MIB document defines its own MIB objects, and every one of those documents has to include a proper security considerations section that explains the security aspects of those objects.

Readers should really pay attention to the security implications of making MIB objects available for create or write access through an access protocol like SNMP 😭 SNMPv1 by itself is an insecure environment. Even if the network itself is made secure (for example, by using IPSec), there's no control over who on that secure network gets to access and GET (read) the objects in this MIB. It is recommended that implementers consider the security features provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414], and the View-based Access Control Model STD 62, RFC 3415 [RFC3415], is recommended.

Then it's the customer/user's responsibility to make sure the SNMP entity giving access to an instance of this MIB is properly configured. It should only give access to those objects, and only to those principals (users) who have legitimate rights to access them 🫶

16. Acknowledgements 🌸

Lots of small pieces of text in this document were borrowed from the documents that define the MIB modules described here, so the authors want to give a huge shoutout to everyone who worked on those MIB documents 💖

Thanks also to everyone who came to the November 2002 MPLS MIB open meeting and gave constructive feedback, especially Sharon Chisholm for her thoughts on Management Options ✨

Thanks to Kireeti Kompella for revising the text on TE-MIB 🙌

Honestly, this document would not have been written without the consistent pressure and encouragement from Bert Wijnen 😭🫶

17. Normative References 📚

  • [FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
  • [LDPMIB] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
  • [LSRMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
  • [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB ", RFC 2863, June 2000.
  • [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
  • [TCMIB] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
  • [TELMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
  • [TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.

18. Informative References 🦋

  • [PPVPNFW] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
  • [PWE3FW] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC2547Bis] Rosen, E., et al., "MPLS/BGP VPNs", Work in Progress, October 2002.
  • [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  • [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
  • [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
  • [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
  • [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
  • [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
  • [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
  • [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
  • [TEWGMIB] Kompella, K., "A Traffic Engineering (TE) MIB", RFC 3970, January 2005.
  • [VPNMIB] Nadeau, T., et al., "MPLS/BGP Virtual Private Network Management Information Base Using SMIv2", Work in Progress, November 2002.
  • [VPNTCMIB] Schliesser, B. and T. Nadeau, "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management", Work in Progress, November 2002.

Authors' Addresses 📬

Thomas D. Nadeau
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719

EMail: tnadeau@cisco.com


Cheenu Srinivasan
Bloomberg L.P.
731 Lexington Avenue
New York, NY 10022

Phone: (212) 617-3682
EMail: cheenu@bloomberg.net


Adrian Farrel
Old Dog Consulting

Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔏

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, for keeping the lights on ✨🌈

📦 where this page comes from