[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-nadeau-mpls-mgmt-overview) 00 01 02 03 04 05 06 07 08 09 RFC 4221

Network Working Group                                Thomas D. Nadeau
Internet Draft                                    Cisco Systems, Inc.
Category: Informational
Expires: March 2004                                 Cheenu Srinivasan
                                                       Bloomberg L.P.

                                                        Adrian Farrel
                                                   Old Dog Consulting

                                                       September 2003

   Multiprotocol Label Switching (MPLS) Management Overview

             draft-ietf-mpls-mgmt-overview-09.txt


Status of this Memo

   This document is an Internet-Draft and is in full
   conformance with all provisions of Section 10 of RFC 2026
   [RFC2026].

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.

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 inter-relationships between the different
   MIB modules used for MPLS network management.









Nadeau, Srinivasan and Farrel                                   [Page 1]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

Table of Contents
   1. Introduction                                                    3
   2. Terminology                                                     3
   3. The SNMP Management Framework                                   4
   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                        8
   5. Tables, Scalars and Notifications in MPLS-LSR-STD-MIB           9
    5.1. Tables                                                       9
    5.2. Scalars                                                     10
    5.3. Indexing                                                    10
    5.4. Notifications                                               11
    5.5. Dependencies Between MIB Module Tables                      11
   6. Tables, Scalars and Notifications in the LDP MIB               12
    6.1. MIB Modules                                                 12
    6.2. Tables                                                      12
    6.3. Scalars                                                     13
    6.4. Notifications                                               14
    6.5. Dependencies Between MIB Module Tables                      14
   7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB           15
    7.1. Tables                                                      15
    7.2. Scalars                                                     16
    7.3. Notifications                                               16
    7.4. Dependencies Between MIB Module Tables                      16
   8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB          17
    8.1. Tables                                                      17
    8.2. Scalars                                                     17
    8.3. Notifications                                               17
    8.4. Dependencies Between MIB Module Tables                      17
   9. Tables and Objects in TE-LINK-STD-MIB                          17
    9.1. Tables                                                      17
    9.2. Scalars                                                     18
    9.3. Notifications                                               18
    9.4. Dependencies Between MIB Module Tables                      18
   10. Table Dependencies Between MPLS MIB Modules                   19
   11. A Note on Interfaces                                          19
    11.1. MPLS Tunnels as Interfaces                                 19
    11.2. Application of the Interfaces Group to TE Links            20
    11.3. References to Interface MIB Objects from MPLS MIB Modules  21
   12. Management Options                                            22
   13. Related IETF MIB Modules                                      23
    13.1. PWE3 Working Group MIB Modules                             23
    13.2. PPVPN Working Group MIB Modules                            23
     13.2.1. PPVPN-MPLS-VPN-STD-MIB                                  23
    13.3. CCAMP Working Group MIB Modules                            24
   14. Traffic Engineering Working Group TE MIB                      24
    14.1. Choosing Between TE MIB Modules                            24

Nadeau, Srinivasan and Farrel                                   [Page 2]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   15. Security Considerations                                       25
   16. Acknowledgements                                              26
   17. Intellectual Property Consideration                           26
   18. Normative References                                          26
   19. Informative References                                        27
   20. Authors' Addresses                                            29
   21. Full Copyright Statement                                      29


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.



Nadeau, Srinivasan and Farrel                                   [Page 3]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

3. The SNMP Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This document specifies a
   MIB module that is compliant to the SMIv2, which is described in
   STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
   RFC 2580 [RFC2580].


4. An Introduction to the MPLS Working Group MIB Modules

   This section addresses the MIB documents produced by the
   MPLS working group, namely MPLS TC MIB, MPLS LSR MIB, MPLS
   TE MIB, MPLS LDP MIB, MPLS FTN MIB, and TE LINK MIB. The
   rest of this section briefly describes the following:

   -  the MPLS Object Identifier (OID) tree structure and the
      position of different MPLS related MIB modules on this tree;

   -  the purpose of each of the MIB modules within the MIB
      documents, what it can be used for, and how it relates
      to the other MIB modules.

   Note that each MIB document contains one or more compliance
   statements for the modules and objects that it defines. The
   support for the different MIB modules and objects is, therefore
   beyond the scope of this document although some recommendations
   are included in the sections that follow.























Nadeau, Srinivasan and Farrel                                   [Page 4]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

4.1.  Structure of the MPLS MIB OID Tree

   The MPLS MIB OID tree has the following structure.

      transmission -- RFC 2578 [RFC2578]
        |
        +- mplsStdMIB -- MPLS-TC-STD-MIB
        |    |
        |    +- mplsTCStdMIB -- MPLS-TC-STD-MIB
        |    |
        |    +- mplsLsrStdMIB -- MPLS-LSR-STD-MIB
        |    |
        |    +- mplsTeStdMIB -- MPLS-TE-STD-MIB
        |    |
        |    +- mplsLdpStdMIB -- MPLS-LDP-STD-MIB
        |    |
        |    +- mplsLdpAtmStdMIB -- MPLS-LDP-ATM-STD-MIB
        |    |
        |    +- mplsLdpFrameRelayStdMIB -- MPLS-LDP-FRAME-RELAY-STD-MIB
        |    |
        |    +- mplsLdpGenericStdMIB -- MPLS-LDP-GENERIC-STD-MIB
        |    |
        |    +- mplsFTNStdMIB -- MPLS-FTN-STD-MIB
        |
        +- teLinkStdMIB -- TE-LINK-STD-MIB

   Note: The OIDs for MIB modules are assigned and managed by IANA.
   They can be found in the referenced MIB documents.


4.2.  MPLS-TC-STD-MIB

   MPLS-TC-STD-MIB defines textual conventions [RFC2579] that may be
   common to MPLS related MIB modules.  These conventions allow
   multiple MIB modules to use the same syntax and format for a
   concept that is shared between the MIB modules.

   For example, labels are a central part of MPLS and need to
   be presented in many of the MIB modules. The textual
   convention for representing an MPLS label is defined in
   MPLS-TC-STD-MIB.

   All of the other MPLS MIB modules import textual conventions
   from this MIB module.


4.3.  MPLS-LSR-STD-MIB

   MPLS-LSR-STD-MIB describes managed objects for modeling an MPLS
   Label Switching Router (LSR).  This puts it at the heart of
   the management architecture for MPLS.

   This MIB module is used to model and manage the basic label
   switching behavior of an MPLS LSR.  It represents the label
   forwarding information base (LFIB) of the LSR and provides
   a view of the LSPs that are being switched by the LSR in
   question.

Nadeau, Srinivasan and Farrel                                   [Page 5]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   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 for configuring
   Label Ranges for Generic Labels, the MIB module does provide
   a way to reserve a range of generic labels because this was
   thought to be useful by the working group.


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, Srinivasan and Farrel                                   [Page 6]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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 around 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
   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 representing source and destination
   address ranges, source and destination port ranges, IPv4
   Protocol field or IPv6 next-header field and the DiffServ
   Code Point (DSCP).


4.10. TE-LINK-STD-MIB

   TE-LINK-STD-MIB describes managed objects that are used to model
   and manage TE links, including bundled links, in an MPLS network.

   The TE link feature is designed to aggregate one or more similar
   data channels or TE links between a pair of LSRs. A TE link
   is a sub-interface capable of carrying traffic engineered MPLS
   traffic.

   A bundled link is a sub-interface that bonds the traffic of
   a group of one or more TE links.


Nadeau, Srinivasan and Farrel                                   [Page 7]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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 once 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 a an object, object identifier, or textual convention
   defined in MIB module B, or that MIB module A contains a pointer
   (index or RowPointer) to an object in MIB module B.

   +-------> MPLS-TC-STD-MIB
   |            ^
   |            |
   |         MPLS-LSR-STD-MIB <------------------+
   |                                             |
   +<----------------------- MPLS-LDP-STD-MIB -->+
   |                                    ^        |
   |                                    |        |
   +<-- MPLS-LDP-GENERIC-STD-MIB ------>+        |
   |                                    |        |
   +<-- MPLS-LDP-ATM-STD-MIB ---------->+        |
   |                                    |        |
   +<-- MPLS-LDP-FRAME-RELAY-STD-MIB -->+        |
   |                                             |
   +<------- MPLS-TE-STD-MIB ------------------->+
   |            ^                                |
   |            |                                |
   +<------- MPLS-FTN-STD-MIB ------------------>+

   Thus:

   -  All the MPLS MIB modules depend on MPLS-TC-STD-MIB.

   -  MPLS-LDP-STD-MIB, MPLS-TE-STD-MIB and MPLS-FTN-STD-MIB contain
      references to objects in MPLS-LSR-STD-MIB.

   -  MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP-ATM-STD-MIB and MPLS-LDP-
      FRAME-RELAY-STD-MIB contain references to objects in MPLS-
      LDP-STD-MIB.

   -  MPLS-FTN-STD-MIB contains references to objects in MPLS-TE-
      STD-MIB.

   Note that there is a textual convention (MplsIndexType) defined
   in MPLS-LSR-STD-MIB that is imported by MPLS-LDP-STD-MIB.


4.12. Dependencies on External MIB Modules

   With the exception of MPLS-TC-STD-MIB, all the MPLS MIB modules
   have dependencies on the Interfaces MIB [RFC2863].  MPLS-FTN-STD-MIB
   references IP-capable interfaces on which received traffic is to
   be classified using indexes in the Interface Table (ifTable) of
   IF-MIB [RFC2863]. The other MPLS MIB modules reference MPLS-

Nadeau, Srinivasan and Farrel                                   [Page 8]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   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 inter-relation 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, while 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 while IndexIntegerNextFree is used by a management agent
   that needs to select an appropriate value for an arbitrary index.

   Finally, all of the MIB modules import standard textual conventions
   such as integers, strings, timestamps etc. from the MIB modules in
   which they are defined.  This is business as usual for a MIB module
   and is not discussed further in this document.


5. Tables, Scalars and Notifications in MPLS-LSR-STD-MIB

5.1.  Tables

   MPLS-LSR-STD-MIB contains the following tables.

   -  The interface configuration table (mplsInterfaceTable)
      is used for enabling MPLS on MPLS-capable interfaces.

   -  The in-segment (mplsInSegmentTable) and out-segment
      (mplsOutSegmentTable) tables are used to configure and monitor LSP
      segments carrying data into and out of the LSR, respectively.

   -  The in-segment mapping table (mplsInSegmentMapTable) provides a
      look-up table that enables the discovery of an in-segment in
      mplsInSegmentTable from the known incoming interface and incoming
      label.

   -  The cross-connect table (mplsXCTable) is used to
      associate in and out segments in order to form a cross-
      connect (i.e. to represent an LSP transiting the LSR).


Nadeau, Srinivasan and Farrel                                   [Page 9]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   -  The label stack table (mplsLabelStackTable) allows the
      specification of multi-label stacks to be imposed on a
      given LSP at this LSR

   -  The MPLS in-segment (mplsInSegmentPerfTable) and out-
      segment (mplsOutSegmentPerfTable) performance tables
      contain objects to measure the performance of LSPs.

   -  The MPLS interface performance table (mplsInterfacePerfTable)
      has objects to measure MPLS performance on a per-interface basis.


5.2.  Scalars

   Where tables in the MIB module have arbitrary indexes, scalars are
   provided to supply the next available index.  This applies to
   mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable and
   mplsLabelStackTable, but see the section on indexing, below.

   mplsMaxLabelStackDepth defines the maximum size of a imposed label
   stack supported at this LSR (and not, as the description in
   MPLS-LSR-STD-MIB states, the maximum label stack depth supported by
   the LSR).

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


5.3. Indexing

   Note that the indexing used by the tables in MPLS-LSR-STD-MIB is
   unusual.  A specific textual convention, MplsIndexType, is defined
   in the MIB module and is used as the type for indexes to
   mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable and
   mplsLabelStackTable.  The textual convention is defined as an
   octet string of between one and twenty four octets inclusive.

   While 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
   it would be hard to determine the 'next' index value.  Thus,
   non-simple values are likely only to be used in read-only MIBs
   where 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.


Nadeau, Srinivasan and Farrel                                  [Page 10]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   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 only change
   the value in an nextIndex scalar when the index is used (that is,
   when a row is created) and not when the nextIndex scalar is read.  In
   a 'busy' table this may result in row creation attempts failing and
   agents having to re-read the scalar before making a second row
   creation attempt.  The desire to avoid this issue is in opposition to
   the desire to avoid lacunae.


5.4. Notifications

   MPLS-LSR-STD-MIB can issue two notifications (if notifications
   are enabled).

   -  mplsXCUp reports when a cross-connect becomes active.

   -  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 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, Srinivasan and Farrel                                  [Page 11]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

                      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 which are specific to LDP
   without any Layer 2 objects.  MPLS-LDP-GENERIC-STD-MIB
   defines Layer 2 Per Platform Label Space objects for use
   with MPLS-LDP-STD-MIB and for use on Ethernet.  MPLS-LDP-ATM-
   STD-MIB defines Layer 2 Asynchronous Transfer Mode (ATM)
   objects for use with MPLS-LDP-STD-MIB.  MPLS-LDP-FRAME-RELAY-
   STD-MIB defines Layer 2 FRAME-RELAY objects for use with
   MPLS-LDP-STD-MIB.

   The MPLS-LDP-STD-MIB module provides the core support and is
   typically supported along with at least one of the Layer 2
   MIB modules.


6.2.  Tables

   The tables in the LDP MIB for configuring the LDP behavior
   of an LSR are as follows.

   -  The LDP Entity Table (mplsLdpEntityTable) provides a way to
      configure the LSR for using LDP.  There must be at least one LDP
      Entity for the LSR to support LDP.  Each entry/row in this table
      represents a single LDP Entity.

Nadeau, Srinivasan and Farrel                                  [Page 12]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   -  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) which maps
      the LDP MIB's representation of LDP sessions to the underlying LSR
      MIB's representation of the LSPs created by these sessions by
      pointing to mplsInSegmentTable, mplsOutSegmentTable and
      mplsXCTable, respectively.

   -  Statistics may be gathered through the LDP Entity Statistics Table
      (mplsLdpEntityStatsTable) and the LDP Session Statistics Table
      (mplsLdpSesStatsTable)


6.3.  Scalars

   Where tables in the MIB modules have arbitrary indexes,
   scalars are provided to supply the next available index.
   This applies to mplsLdpEntityTable and mplsFecTable.

   Two scalars exist to configure the LSR.  The LSR ID is set in
   mplsLdpLsrId, and the loop detection capabilities are reported
   in mplsLdpLsrLoopDetectionCapable








Nadeau, Srinivasan and Farrel                                  [Page 13]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

6.4.  Notifications

   MPLS-LDP-STD-MIB defines four notifications that a device can
   issue.

   -  mplsLdpInitSesThresholdExceeded is reported when the
      number of Session Initialization messages exceeds a
      configured threshold.

   -  mplsLdpPVLMismatch is issued if the Path Vector Limit
      for a configured Entity and Peer do not match.

   -  mplsLdpSessionUp and mplsLdpSessionDown report the
      transition of Session state.

   No scalar object is provided to enable and disable
   notifications from MPLS-LDP-STD-MIB.  Instead, the implementer
   is referred to [RFC3413].


6.5.  Dependencies Between MIB Module Tables

   The many tables in the four LDP MIB modules are related as
   shown on the diagram below.  The arrows indicate a
   reference from one table to another.  Note that in many
   cases the reference is through an augmentation of the
   referenced table.

   mplsLdpEntityGenLRTable ------------->+
   mplsLdpEntityAtmParmsTable ---------->+
   mplsLdpEntityAtmLRTable ------------->+
   mplsLdpEntityFrameRelayParmsTable --->+
   mplsLdpEntityFrLRTable -------------->+
   mplsLdpEntityStatsTable ------------->+
                                         |
   mplsLdpHelloAdjacencyTable            |
                |                        |
                |  mplsLdpEntityTable <--+
                |      ^       ^
                V      |       |
            mplsLdpPeerTable <-+- mplsLdpSesPeerAddrTable
                       ^       |
                       |       V
                 mplsLdpSessionTable
                              ^   ^
                              |   |
   mplsLdpSesStatsTable ------+   +-- mplsLdpLspFecTable
   mplsLdpAtmSesTable --------+   |    |       |
   mplsLdpFrameRelaySesTable--+   |    |       V
                                  |    |    mplsFecTable
                                  |    V
                                  +-- mplsLdpLspTable






Nadeau, Srinivasan and Farrel                                  [Page 14]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB

7.1.  Tables

   MPLS-TE-STD-MIB contains the following tables.

   -  The Tunnel Table (mplsTunnelTable) is used to configure
      and report MPLS tunnels.  Note that reporting of
      tunnels in this table at transit LSRs is optional.

      Entries in mplsTunnelTable are indexed by four
      objects.  The source and destination LSR IDs give
      context to the entry, and an index  (mplsTunnelIndex)
      identifies the tunnel itself.  However, the fourth index
      (mplsTunnelInstance) may give rise to some confusion since
      its usage is not clearly explained.

      The description says: "Uniquely identifies an instance
      of a tunnel. It is useful to identify multiple
      instances of tunnels for the purposes of backup and
      parallel tunnels." In the case of backup tunnels,
      multiple instances of the same tunnel may be defined,
      but only one is active at any time. Different instances
      may have different properties (such as explicit
      routes), and one instance may be set up to protect
      against failure of another. Parallel tunnels may be
      used to provide load sharing or protection.

      The mplsTunnelInstancePriority object is used to
      indicate the precedence of tunnels with the same LSR
      Ids and mplsTunnelIndex value.  The mplsTunnelPrimaryInstance
      object gives a quick reference back to the preferred instance
      of the tunnel.

      The mplsTunnelIndex value is typically signaled as
      the Tunnel ID, and the mplsTunnelInstance as the LSP Id
      in protocols where both fields exist.  In protocols
      where there is only one identifying index (usually
      known as the LSP Id), only the mplsTunnelIndex is
      signaled.

   -  The Resource Table (mplsTunnelResourceTable) is used to
      configure resources to be requested on this tunnel.
      The CRLDP resource table (mplsTunnelCRLDPResTable) is
      used to request additional resource details that are
      specific to tunnels signaled using CR-LDP.

   -  The routes requested, computed and actually used for a
      tunnel are found in the Tunnel Hop Table
      (mplsTunnelHopTable) Tunnel Computed Hop Table
      (mplsTunnelCHopTable) and Tunnel Actual Hop Table
      (mplsTunnelARHopTable).

   -  Statistics about the performance of tunnels may be
      gathered through the Tunnel Performance Table
      (mplsTunnelPerfTable).


Nadeau, Srinivasan and Farrel                                  [Page 15]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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


Nadeau, Srinivasan and Farrel                                  [Page 16]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB

8.1.  Tables

   MPLS-FTN-STD-MIB contains the following tables.

   -  The FEC-to-NHLFE Table (mplsFTNTable) defines the FEC to NHLFE
      rules to be applied to incoming packets, and the actions to be
      taken on matching packets.

   -  The FEC-to-NHLFE Mapping Table (mplsFTNMapTable) provides
      the capability to activate FTN rules defined in the
      mplsFTNTable on specific interfaces in the system.

   -  Performance statistics for FTN rules are found in the
      mplsFTNPerfTable.


8.2.  Scalars

   This MIB module contains the scalars mplsFTNTableLastChanged and
   mplsFTNMapTableLastChanged to indicate the last time an object
   changed in mplsFTNTable and mplsFTNMapTable respectively. Another
   scalar, mplsFTNIndexNext, is used to supply the next valid index for
   creating new conceptual rows in mplsFTNTable.


8.3.  Notifications

   There are no notifications in this MIB module.

8.4.  Dependencies Between MIB Module Tables

   The tables in MPLS-FTN-STD-MIB are related as shown on the diagram
   below.  The arrows indicate a reference from one table to another.

                         mplsFTNTable
                              ^
                              |
                       mplsFTNMapTable
                              ^
                              |
                       mplsFTNPerfTable


9. Tables and Objects in TE-LINK-STD-MIB

9.1.  Tables

   TE-LINK-STD-MIB contains the following tables.

   -  The TE link table (teLinkTable) is used to specify TE links,
      including bundled links, and their generic traffic engineering
      parameters.

   -  The TE link descriptor table (teLinkDescriptorTable) is used to
      list the TE link descriptors.

Nadeau, Srinivasan and Farrel                                  [Page 17]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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

Nadeau, Srinivasan and Farrel                                  [Page 18]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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 since so 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 in order 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                 |
   +------------------------------------------------+



Nadeau, Srinivasan and Farrel                                  [Page 19]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   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 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 inter-relation
   of entries in the ifTable is defined by Interfaces Stack Group
   defined in [RFC2863].  When using TE Link interfaces, the
   interface stack table might appear as follows:

   +-------------------------------------------------------------------+
   | MPLS interface ifType = mpls(166)                                 |
   | ifIndex = 1                                                       |
   +-------------------------------------------------------------------+
   | TE link (bundled link) ifType = teLink(200)                       |
   | ifIndex = 2                                                       |
   +--------------------------------+-+--------------------------------+
   | TE link ifType = teLink(200)   | | TE link ifType = teLink(200)   |
   | ifIndex = 3                    | | ifIndex = 4                    |
   +--------------------------------+ +--------------------------------+
   | Component link                 | | Component link                 |
   | ifType = opticalTransport(196) | | ifType = opticalTransport(196) |
   | ifIndex = 5                    | | ifIndex = 6                    |
   +--------------------------------+ +--------------------------------+

   In the above diagram, "opticalTransport" is an example of an
   underlying physical interface: in this case an optical transport
   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.

Nadeau, Srinivasan and Farrel                                  [Page 20]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   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 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 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 use 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.


Nadeau, Srinivasan and Farrel                                  [Page 21]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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 LDP, but there is little
   further value to this since 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 manually set up 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.

Nadeau, Srinivasan and Farrel                                  [Page 22]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   Do not be mislead 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 set up by an amnesiac user, or a very short lifetime 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 information and is not central to this document.


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




Nadeau, Srinivasan and Farrel                                  [Page 23]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

13.2.1.2.    Dependencies

   This MIB module currently has no direct dependencies to 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-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 so 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 leads
   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.




Nadeau, Srinivasan and Farrel                                  [Page 24]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   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 is not a work item
   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
   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 inter-relationships 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 such an insecure environment.  Even if the network itself is
   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









Nadeau, Srinivasan and Farrel                                  [Page 25]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

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.

   Without the consistent pressure and encouragement from
   Bert Wijnen, this document would not have been written.


17.   Intellectual Property Consideration

   The IETF takes no position regarding the validity or scope
   of any intellectual property 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; neither does it represent that it has made any
   effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track
   and standards-related documentation can be found in BCP-11.
   Copies of claims of rights made available for publication
   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 Secretariat.

   The IETF invites any interested party to bring to its
   attention any copyrights, patents or patent applications, or
   other proprietary rights which may cover technology that may
   be required to practice this standard.  Please address the
   information to the IETF Executive Director.


18.   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",
                 Internet Draft <draft-ietf-mpls-ftn-mib-08.txt>,
                 August 2003 (work in progress).

   [LDPMIB]      J. Cucchiara, et al., "Definitions of
                 Managed Objects for the Multiprotocol Label
                 Switching, Label Distribution Protocol
                 (LDP)", <draft-ietf-mpls-ldp-mib-13.txt>,
                 August 2003 (work in progress).

Nadeau, Srinivasan and Farrel                                  [Page 26]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T. Nadeau,
                 "MPLS Label Switching Router Management Information
                 Base", Internet Draft <draft-ietf-mpls-lsr-mib-12.txt>,
                 August 2003 (work in progress).

   [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., Cucchiara, J., (Editors) "Definitions of
                 Textual Conventions for Multiprotocol Label Switching
                 (MPLS) Management", Internet Draft <draft-ietf-mpls-tc-
                 mib-09.txt>, August 2003 (work in progress).

   [TELMIB]      Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang,
                 "Traffic Engineering Management Information Base",
                 Internet Draft <draft-ietf-mpls-telink-mib-03.txt>,
                 August 2003 (work in progress).

   [TEMIB]       Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Traffic Engineering Management
                 Information Base Using SMIv2", Internet
                 Draft <draft-ietf-mpls-te-mib-12.txt>,
                 August 2003 (work in progress).


19.   Informative References

   [PPVPNFW]     Callon, R., Suzuki, M., (Editors) "A Framework
                 for Layer 3 Provider Provisioned Virtual Private
                 Networks", Internet Draft <draft-ietf-ppvpn-
                 framework-08.txt>, March 2003 (work in progress).

   [PWE3FW]      Pate, P., (Editor), "Framework for Pseudo Wire
                 Emulation Edge-to-Edge (PWE3)", Internet Draft
                 <draft-ietf-pwe3-framework-01.txt>, June, 2002
                 (work in progress).

   [RFC2026]     S. Bradner, "The Internet Standards Process
                 -- Revision 3", RFC 2026, October 1996.

   [RFC2401]     Kent, S., and Atkinson, R., "Security
                 Architecture for the Internet Protocol", RFC
                 2401, November 1998.

   [RFC2547Bis]  Rosen, E. et al, "MPLS/BGP VPNs", Internet
                 Draft <draft-ietf-ppvpn-rfc2547bis-03.txt>,
                 October 2002.

   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                 Case, J., Rose, M. and S. Waldbusser, "Structure
                 of Management Information Version 2 (SMIv2)",
                 STD 58, RFC 2578, April 1999.


Nadeau, Srinivasan and Farrel                                  [Page 27]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                 Case, J., Rose, M. and S. Waldbusser, "Textual
                 Conventions for SMIv2", STD 58, RFC 2579, April
                 1999.

   [RFC2580]     McCloghrie, K., Perkins, D., Schoenwaelder, J.,
                 Case, J., Rose, M. and S. Waldbusser, "Conformance
                 Statements for SMIv2", STD 58, RFC 2580, April 1999.

   [RFC2863]     McCloghrie, K. and F. Kastenholtz, "The
                 Interfaces Group MIB ", RFC 2863, June 2000.

   [RFC3031]     Rosen, E., Viswanathan, A., and Callon, R.,
                 "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 Stewart, B.,
                 "Introduction and Applicability Statements for
                 Internet-Standard Management Framework", RFC 3410,
                 December 2002.

   [RFC3413]     Levi, D., Meyer, P., Stewart, B., "Simple Network
                 Management Protocol (SNMP) Applications", RFC 3413
                 December 2002.

   [RFC3414]     Blumenthal, U., Wijnen, B., "User-based Security
                 Model (USM) for version 3 of the Simple Network
                 Management Protocol (SNMPv3)", RFC 3414, December
                 2002.

   [RFC3415]     Wijnen, B., Presuhn, R., McCloghrie, K., "View-
                 based Access Control Model (VACM) for the Simple
                 Network Management Protocol (SNMP)", RFC 3415,
                 December 2002.

   [TEWGMIB]     Kompella, K., "A Traffic Engineering MIB",
                 Internet Draft <draft-ietf-tewg-mib-03.txt>,
                 September 2002 (work in progress).

   [VPNMIB]      Nadeau, T., et al., "MPLS/BGP Virtual Private
                 Network Management Information Base Using SMIv2",
                 Internet Draft, <draft-ietf-ppvpn-mpls-vpn-mib-
                 05.txt>, November 2002 (work in progress).

   [VPNTCMIB]    Schliesser, B., Nadeau, T., "Definition of
                 Textual Conventions for Provider Provisioned
                 Virtual Private Network (PPVPN) Management",
                 Internet Draft, <draft-ietf-ppvpn-tc-mib-
                 02.txt>, November 2002 (work in progress).





Nadeau, Srinivasan and Farrel                                  [Page 28]

Internet Draft     draft-ietf-mpls-mgmt-overview-09.txt   September 2003

20.   Authors' Addresses

  Thomas D. Nadeau
  Cisco Systems, Inc.
  300 Apollo Drive
  Chelmsford, MA 01824
  Phone: +1-978-244-3051
  Email: tnadeau@cisco.com

  Cheenu Srinivasan
  Bloomberg L.P.,
  499 Park Avenue,
  New York, NY 10022
  Tel: (212) 893-3682
  Email: cheenu@bloomberg.net

  Adrian Farrel
  Old Dog Consulting
  Tel: +44 (0) 1978 860944
  Email: adrian@olddog.co.uk


21.   Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights
   Reserved.

   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on
   or otherwise explain it or assist in its implementation may
   be prepared, copied, published and distributed, in whole or
   in part, without restriction of any kind, provided that the
   above copyright notice and this paragraph are included on
   all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its
   successors or assigns. This document and the information
   contained herein is provided on an "AS IS" basis and THE
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS 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.






Nadeau, Srinivasan and Farrel                                  [Page 29]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/