doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc4221.txt b/doc/rfc/rfc4221.txt
new file mode 100644
index 0000000..b004985
--- /dev/null
+++ b/doc/rfc/rfc4221.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                          T. Nadeau
+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
+
+
+
+Nadeau, et al.               Informational                      [Page 1]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+      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
+
+
+
+Nadeau, et al.               Informational                      [Page 2]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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].
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 3]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 4]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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.
+
+
+
+Nadeau, et al.               Informational                      [Page 5]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   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.
+
+
+
+
+Nadeau, et al.               Informational                      [Page 6]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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.
+
+
+
+
+Nadeau, et al.               Informational                      [Page 7]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   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.
+
+
+
+Nadeau, et al.               Informational                      [Page 8]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   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.
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 9]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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.
+
+
+
+
+Nadeau, et al.               Informational                     [Page 10]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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.
+
+
+
+
+Nadeau, et al.               Informational                     [Page 11]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+5.4.  Notifications
+
+   MPLS-LSR-STD-MIB can issue two notifications (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 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 12]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+                      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.
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 13]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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.
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 14]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   -  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 15]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   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.
+
+
+
+Nadeau, et al.               Informational                     [Page 16]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+      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
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 17]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   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.
+
+
+
+
+Nadeau, et al.               Informational                     [Page 18]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   -  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.
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 19]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   -  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 ----+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 20]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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:
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 21]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   +------------------------------------------------+
+   | 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 22]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   +-------------------------------------------------------------------+
+   | 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
+   interface.  TE link management and bundling can be seen in the levels
+   of interface stacking.  Two TE links are defined, each managing an
+   optical transport link.  These two TE links are combined into a
+   bundle, which is managed as a single TE link interface.  This TE Link
+   interface supports MPLS and is presented as an MPLS interface.
+
+   A detailed listing of the mapping between ifTable objects and their
+   use for TE Links is given in [TELMIB].  A few key objects are listed
+   here to provide an overview of the concepts.
+
+   Each TE Link interface is represented by a separate entry in the
+   ifTable, with 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 a TE Link is 200.
+
+11.3.  References to Interface MIB Objects from MPLS MIB Modules
+
+   MPLS-TE-STD-MIB contains two objects that reference the management of
+   an MPLS tunnel as an interface.  mplsTunnelIsIf is a TruthValue that
+   indicates whether the tunnel is present in the ifTable.  If the
+   tunnel is managed as an interface, the mplsTunnelIfIndex object
+   contains the ifIndex that identifies the corresponding entry in the
+   ifTable.
+
+   MPLS-LSR-STD-MIB includes a table (mplsInterfaceTable) for
+   configuring the support for MPLS on specific interfaces.  A
+   conceptual row in this table is created automatically by an LSR for
+   every interface that is capable of and configured for support of
+   MPLS.  A conceptual row in this table will exist if and only if a
+
+
+
+Nadeau, et al.               Informational                     [Page 23]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   corresponding entry in ifTable exists with ifType = mpls(166).  The
+   fate of the entries in the two tables are closely linked so that if
+   the entry in the ifTable is operationally disabled, the entry in
+   mplsInterfaceTable is deleted.  During the life of an entry in
+   mplsInterfaceTable, a corresponding entry is managed in
+   mplsInterfacePerfTable to show performance counters for the MPLS-
+   capable interface.
+
+   The ifIndex that identifies MPLS-capable interfaces also plays an
+   important indexing role in MPLS-LSR-STD-MIB.  In-segments (that is,
+   incoming LSP labels) are represented in mplsInSegmentTable, which is
+   indexed by the mplsInSegmentIfIndex and mplsInSegmentLabel objects.
+   mplsInSegmentIfIndex is set to the ifIndex of the incoming MPLS-
+   capable interface.  mplsInSegmentLabel identifies the incoming MPLS
+   label.  Note that the corresponding mplsOutSegmentTable contains an
+   mplsOutSegmentIfIndex object to identify the outgoing MPLS-capable
+   interface, but that this does not form part of the index of the
+   table.
+
+   MPLS-LDP-STD-MIB uses ifIndex extensively to identify the interface
+   over which MPLS is active.
+
+   Within MPLS-FTN-STD-MIB, mplsFTNMapTable maps entries in mplsFTNTable
+   to interfaces on which mplsFTNTable entries should be activated.
+   Interfaces are identified using their ifIndex values.
+
+12.  Management Options
+
+   It is not the intention of this document to provide instructions or
+   advice to implementers of Management Stations, Management Agents, or
+   managed entities.  It is, however, useful to make some observations
+   about how the MIB modules described above might be used to manage
+   MPLS systems.
+
+   All MPLS LSPs may appear in MPLS-LSR-STD-MIB.  At transit nodes, they
+   are seen as full cross-connects between incoming labels on incoming
+   interfaces and outgoing labels on outgoing interfaces.  At ingress or
+   egress points, the cross-connections are unbalanced having spoof
+   upstream or downstream legs, respectively.
+
+   Split and merge points of LSPs may 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 each of
+   the forward and reverse cross-connections.
+
+   The modules in the LDP MIB are intended solely for use with LDP and
+   CR-LDP.  LSPs that are signaled through other means may conveniently
+   be stored in mplsLdpLspTable for consistency with LSPs set up using
+
+
+
+Nadeau, et al.               Informational                     [Page 24]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   LDP, but there is little further value to this because the table
+   gives only pointers into MPLS-LSR-STD-MIB.  If, however, the LSPs are
+   established with associated FECs using some signaling method other
+   than LDP (for example, BGP), it may be advantageous to use
+   mplsLdpLspTable, mplsFecTable, and mplsLdpLspFecTable to correlate
+   the LSPs.
+
+   Note that if CR-LDP is the signaling protocol, there is no
+   requirement to use the LSP-related tables in the LDP MIB since the
+   LSP will be adequately represented in MPLS-TE-MIB and MPLS-LSR-STD-
+   MIB.
+
+   MPLS tunnels may be represented in MPLS-TE-STD-MIB with their cross-
+   connects indicated in MPLS-LSR-STD-MIB.  Tunnels are often (although
+   not always) set up with a series of constraints that may be
+   represented in MPLS-TE-STD-MIB.  Note that a distinguishing feature
+   of a tunnel is that it has an ingress and an egress, where LSPs
+   established through LDP may be end-to-end or may be hop-by-hop.
+
+   All LSPs (tunnels and non-tunnels) may be established as a result of
+   signaling protocols already defined or for future study.  In
+   addition, LSPs may be set up manually by issuing configuration
+   commands to each of the LSRs on the LSP.  These commands may utilize
+   SNMP by performing SET operations to the MIB module tables and
+   objects described here.  Alternatively, configuration may be through
+   some non-standard interface such as a Command Line or a Graphical
+   User Interface.  Such configured LSPs may also be represented in the
+   MIB module tables.
+
+   Do not be misled by considerations of the "permanence" of LSPs when
+   deciding which tables of which MIB modules to use.  An MPLS tunnel
+   may have a very long life expectancy if it is set up by an amnesiac
+   user.  Otherwise, it may have a very short lifetime if it is
+   automatically provisioned to satisfy on-demand traffic requirements.
+   Similarly, an LSP established in response to a routing protocol
+   (sometimes known as a hop-by-hop LSP) may be equally stable or
+   unstable.
+
+13.  Related IETF MIB Modules
+
+   This section describes the broad interactions between MIB modules
+   produced by the PWE3, PPVPN, and CCAMP working groups and the MPLS
+   MIB modules.  This information is provided as background and is not
+   central to this document.
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 25]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+13.1.  PWE3 Working Group MIB Modules
+
+   The PWE3 working group has produced a document [PWE3FW] that includes
+   a description of the framework for MIB modules within PWE3 operation.
+   Since the PWE3 architecture includes the use of MPLS as an emulated
+   service and as a PSN service, the MPLS MIB modules described above
+   may be leveraged.  The PWE3 framework document describes the
+   interactions between the MPLS MIB modules and the PWE3 MIB modules.
+
+13.2.  PPVPN Working Group MIB Modules
+
+   At present, the PPVPN working group has not included a discussion of
+   how the MPLS MIB modules interact with the MIB modules being produced
+   by that working group.  The authors of this document hope to make a
+   forthcoming addition to the PPVPN framework document [PPVPNFW]
+   detailing these interactions.  At the moment, there are two MIB
+   modules, [VPNMIB] and [VPNTCMIB], which are discussed next.
+
+13.2.1.  PPVPN-MPLS-VPN-STD-MIB
+
+   PPVPN-MPLS-VPN-STD-MIB describes managed objects that are used to
+   model and manage RFC2547bis MPLS VPNs [RFC2547Bis].  This MIB module
+   contains tables that model virtual routing forwarding entries (VRFs),
+   as well as the interfaces associated with 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 currently has no direct dependencies on any of the
+   MPLS MIB modules.  This MIB module models MPLS VPN interfaces as
+   entries in the Interfaces MIB's Interfaces Table (ifTable).  This MIB
+   module may be modified in the future to import textual conventions
+   from MPLS-TC-STD-MIB.
+
+   A specific textual conventions MIB module [VPNTCMIB] defines textual
+   conventions that are imported into PPVPN-MPLS-VPN-STD-MIB.
+
+13.3.  CCAMP Working Group MIB Modules
+
+   The CCAMP working group is developing MIB modules in support of GMPLS
+   that interact directly with the MPLS MIB modules.  Along with any MIB
+   modules produced by the CCAMP working group, a separate CCAMP-
+
+
+
+
+Nadeau, et al.               Informational                     [Page 26]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   specific Management Framework document is expected to be issued
+   describing the relationship between these MIB modules and 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]
+   containing objects for monitoring traffic-engineered tunnels at their
+   ingress points.
+
+   In many senses TE-MIB contains the same information as MPLS-TE-STD-
+   MIB.  Both MIB modules can be used to monitor MPLS tunnels; however,
+   TE-MIB is minimalistic and caters best to TE tunnels as tunnels, at
+   the expense of not having many advanced features of MPLS-TE-STD-MIB,
+   whereas MPLS-TE-STD-MIB can deconstruct tunnels into hop-by-hop
+   cross-connects, at the expense of more complexity.
+
+   The TE-MIB module imports textual conventions from the MPLS-TC-STD-
+   MIB module and therefore is dependent on that document.
+
+14.1.  Choosing between TE MIB Modules
+
+   TE-MIB is a flexible MIB module designed to manage traffic
+   engineering tunnels regardless of the implementation technology.
+   This flexibility and a focus on simplicity lead to some compromises.
+
+   - Some MPLS configuration parameters are left out.  For example, the
+     resource management in TE-MIB is confined to bandwidth, so missing
+     the full IntServ control.
+
+   - Other TE-MIB parameters are present but with only limited options;
+     for example, the ability to configure different label distribution
+     methods per LSP.
+
+   Extensibility of TE-MIB to related concepts (such as DiffServ and
+   Fast Reroute) and integrations with other MIB modules (such as that
+   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, where
+   it can be used to configure an ingress to signal a tunnel with
+   constraints.  It cannot be used to configure hop-by-hop cross-
+   connects to build a tunnel.
+
+   The purpose of TE-MIB module is to allow a Management Agent to
+   configure tunnels, and to inspect and monitor all tunnels (however
+   created) at their ingress points.  It does not provide information
+
+
+
+Nadeau, et al.               Informational                     [Page 27]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   about tunnels at any other point in the network (that is, at transit
+   or egress nodes).  This module can be used, for example, to configure
+   the constraints of a tunnel, whereupon the ingress would compute the
+   tunnel path and signal it.  The MIB module can then be used at the
+   ingress to monitor the tunnel's path(s), their status, and the
+   tunnel's uptime and counters.  This MIB module is not designed to
+   configure hop-by-hop cross-connects to build a tunnel.
+
+15.  Security Considerations
+
+   This document describes the interrelationships amongst the different
+   MIB modules relevant to MPLS management and as such does not have any
+   security implications in and of itself.
+
+   Each specific MIB document specifies specific MIB objects, and such a
+   document must provide a proper security considerations section that
+   explains the security aspects of those objects.
+
+   The attention of readers is particularly drawn to the security
+   implications of making MIB objects available for create or write
+   access through an access protocol such as SNMP.  SNMPv1 by itself is
+   an insecure environment.  Even if the network itself is made secure
+   (for example, by using IPSec), there is no control over who on the
+   secure network is allowed to access and GET (read) the objects in
+   this MIB.  It is recommended that the implementers consider the
+   security features as 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.
+
+   It is then a customer/user responsibility to ensure that the SNMP
+   entity giving access to an instance of this MIB is properly
+   configured to give access to only those objects, and to those
+   principals (users) that have legitimate rights to access them.
+
+16.  Acknowledgements
+
+   Many small pieces of text in this document have been borrowed from
+   the documents that define the MIB modules described here.  The
+   authors would like to express appreciation to all who worked on those
+   MIB documents.
+
+   Thanks also to all those who attended the November 2002 MPLS MIB open
+   meeting and gave constructive feedback, and in particular to Sharon
+   Chisholm for her thoughts on Management Options.
+
+   Thanks to Kireeti Kompella for revising the text on TE-MIB.
+
+
+
+
+Nadeau, et al.               Informational                     [Page 28]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   Without the consistent pressure and encouragement from Bert Wijnen,
+   this document would not have been written.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 29]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+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.
+
+
+
+Nadeau, et al.               Informational                     [Page 30]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+   [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
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 31]
+
+RFC 4221                MPLS Management Overview           November 2005
+
+
+Full Copyright Statement
+
+   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; nor does it 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 and 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.
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 32]
+