Network Working Group                                Thomas D. Nadeau
Internet Draft                                    Cisco Systems, Inc.
Category: Informational
Expires: August 2003                                Cheenu Srinivasan
                                                Parama Networks, Inc.

                                                        Adrian Farrel
                                                 Movaz Networks, Inc.

                                                        February 2003


   Multiprotocol Label Switching (MPLS) Management Overview

             draft-ietf-mpls-mgmt-overview-03.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 Bases (MIBs) has been
   developed to help model and manage the various aspects of
   Multiprotocol Label Switching (MPLS) networks.  These MIBs
   are defined in separate drafts and RFCs that focus on the
   specific areas of responsibility of their MIBs.

   This memo describes the management architecture for MPLS
   and indicates the inter-relationships between the different
   MIBs used for MPLS network management.









Nadeau, Srinivasan and Farrel                                   [Page 1]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 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-MIB                                                  5
    4.3. MPLS-LSR-MIB                                                 6
    4.4. MPLS-LDP-MIB                                                 6
    4.5. MPLS-LDP-GENERIC-MIB                                         6
    4.6. MPLS-LDP-ATM-MIB                                             7
    4.7. MPLS-LDP-FRAME-RELAY-MIB                                     7
    4.8. MPLS-TE-MIB                                                  7
    4.9. MPLS-FTN-MIB                                                 7
    4.10. MPLS-LINK-BUNDLING-MIB                                      8
    4.11. MIB Interdependencies                                       8
    4.12. Dependencies on External MIBs                               9
   5. Tables, Scalars and Notifications in MPLS-LSR-MIB               9
    5.1. Tables                                                       9
    5.2. Scalars                                                     10
    5.3. Notifications                                               10
    5.4. Dependencies Between MIB Module Tables                      10
   6. Tables, Scalars and Notifications in the LDP MIB               11
    6.1. MIB Modules                                                 11
    6.2. Tables                                                      11
    6.3. Scalars                                                     12
    6.4. Notifications                                               13
    6.5. Dependencies Between MIB Module Tables                      13
   7. Tables, Scalars and Notifications in MPLS-TE-MIB               14
    7.1. Tables                                                      14
    7.2. Scalars                                                     15
    7.3. Notifications                                               15
    7.4. Dependencies Between MIB Module Tables                      15
   8. Tables, Scalars and Notifications in MPLS-FTN-MIB              16
    8.1. Tables                                                      16
    8.2. Scalars                                                     16
    8.3. Notifications                                               16
    8.4. Dependencies Between MIB Tables                             16
   9. Tables and Objects in MPLS-LINK-BUNDLING-MIB                   16
    9.1. Tables                                                      16
    9.2. Scalars                                                     17
    9.3. Notifications                                               17
    9.4. Dependencies Between MIB Module Tables                      17
   10. MIB Table Dependencies Between MPLS MIBs                      18
   11. A Note on Interfaces                                          18
    11.1. MPLS Tunnels as Interfaces                                 19
    11.2. Application of the Interfaces Group to TE Links            19
    11.3. References to Interface MIB Objects from Other MPLS MIBs   20
   12. Management Options                                            21
   13. Related IETF MIB Modules                                      22
    13.1. pwe3 Working Group MIB Modules                             22
    13.2. ppvpn Working Group MIB Modules                            23
     13.2.1. PPVPN-MPLS-VPN-MIB                                      23
    13.3. ccamp Working Group MIBs                                   23
   14. Traffic Engineering Working Group TE MIB                      23
    14.1. Choosing Between TE MIBs Modules                           24


Nadeau, Srinivasan and Farrel                                   [Page 2]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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


1. Introduction

   This memo 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 MIBs.

   For additional information, this draft also includes a
   brief note on MIBs 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 draft 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
   draft and to indicate reference material for readers that
   need to know more about SNMP.

   This draft does not propose any additions to the MPLS MIB
   framework, nor define any standards for the Internet
   community.  It is an informational draft.  In all cases,
   the reader is advised to turn to the draft or RFC that
   defines the MIB 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 MIBs:
   MPLS TC MIB [TCMIB], MPLS LSR MIB [LSRMIB], MPLS TE MIB
   [TEMIB], MPLS LDP MIB [LDPMIB], MPLS FTN MIB [FTNMIB], MPLS
   LINK BUNDLING MIB [LBMIB], and PPVPN MPLS VPN MIB [VPNMIB].

   Throughout this document hyphenated MIB names (such as MPLS-
   TE-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-03.txt    February 2003

3. The SNMP Management Framework

   The SNMP Management Framework presently consists of five
   major components:

   -  An overall architecture, described in RFC 2571
      [RFC2571].

   -  Mechanisms for describing and naming objects and events
      for the purpose of management.  The first version of
      this Structure of Management Information (SMI) is
      called SMIv1 and described in STD 16, RFC 1155
      [RFC1155], STD 16, RFC 1212 [RFC1212] and STD 16, RFC
      1215 [RFC1215].  The second version, called SMIv2, is
      described in STD 58, RFC 2578 [RFC2578], STD 58, RFC
      2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].

   -  Message protocols for transferring management
      information.  The first version of the SNMP message
      protocol is called SNMPv1 and described in STD 15, RFC
      1157 [RFC1157].  A second version of the SNMP message
      protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901
      [RFC1901] and RFC 1906 [RFC1906].  The third version of
      the message protocol is called SNMPv3 and described in
      RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
      [RFC2574].

   -  Protocol operations for accessing management
      information.  The first set of protocol operations and
      associated PDU formats is described in STD 15, RFC 1157
      [RFC1157].  A second set of protocol operations and
      associated PDU formats is described in RFC 1905
      [RFC1905].

   -  A set of fundamental applications described in RFC 2573
      [RFC2573] and the view-based access control mechanism
      described in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management
   Framework can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information
   store, termed the Management Information Base or MIB.
   Objects in the MIB are defined using the mechanisms defined
   in the SMI.


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 MPLS LINK BUNDLING
   MIB.  The rest of this section briefly describes the
   following:



Nadeau, Srinivasan and Farrel                                   [Page 4]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   -  the MPLS Object Identifier (OID) tree structure and the
      position of different MPLS related MIBs 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.


4.1.  Structure of the MPLS MIB OID Tree

   The MPLS MIB OID tree has the following structure.

      transmission -- RFC1213-MIB [RFC1213]
        |
        +- mplsMIB (166?) -- MPLS-TC-MIB
        |    |
        |    +- mplsTCMIB (1) -- MPLS-TC-MIB
        |    |
        |    +- mplsLsrMIB (2) -- MPLS-LSR-MIB
        |    |
        |    +- mplsTeMIB (3) -- MPLS-TE-MIB
        |    |
        |    +- mplsLdpMIB (4) -- MPLS-LDP-MIB
        |    |
        |    +- mplsLdpAtmMIB (5) -- MPLS-LDP-ATM-MIB
        |    |
        |    +- mplsLdpFrameRelayMIB (6) -- MPLS-LDP-FRAME-RELAY-MIB
        |    |
        |    +- mplsLdpGenericMIB (7) -- MPLS-LDP-GENERIC-MIB
        |    |
        |    +- mplsFTNMIB (8) -- MPLS-FTN-MIB
        ?
        +- linkBundlingMIB (TBD) -- LINK-BUNDLING-MIB

   Note: OID information is pending assignment by IANA.
   Conflicts and absent information shown above will be
   included in a later revision.


4.2.  MPLS-TC-MIB

   MPLS-TC-MIB defines textual conventions [RFC2579] and
   object identities 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-MIB.

   All of the other MPLS MIBs import this MIB so that they can
   use one or more of the textual conventions it defines.




Nadeau, Srinivasan and Farrel                                   [Page 5]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

4.3.  MPLS-LSR-MIB

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

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

   Since basic MPLS label switching is common to all MPLS
   applications, this MIB is referenced by many of the other
   MPLS MIB modules.

   In general, MPLS-LSR-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-MIB and
   are typically referenced by other MIB modules in order to
   refer to the underlying MPLS LSP.

   For example, MPLS-TE-MIB models traffic engineered tunnels.
   These tunnels map to one more underlying MPLS LSPs. MPLS-TE-
   MIB refers to the underlying LSP by pointing to cross-
   connect entries in MPLS-LSR-MIB.


4.4.  MPLS-LDP-MIB

   MPLS-LDP-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, this MIB
   module must always be implemented along with one or more of
   the other LDP MIB modules from the following sections.


4.5.  MPLS-LDP-GENERIC-MIB

   This MIB module must be supported by LDP implementations if
   LDP uses a Per Platform Label Space.  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 does
   provide a way to reserve a range of generic labels because
   this was thought to be useful by the working group.






Nadeau, Srinivasan and Farrel                                   [Page 6]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

4.6.  MPLS-LDP-ATM-MIB

   This MIB module must be supported by LDP implementations if
   LDP uses ATM as the Layer 2 medium.  Tables in this MIB
   module allow for configuring LDP to use ATM.


4.7.  MPLS-LDP-FRAME-RELAY-MIB

   This MIB module must be supported 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-MIB

   MPLS-TE-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 or.  The MIB module
   provides configuration and statistics objects needed for TE
   tunnels.


4.9.  MPLS-FTN-MIB

   MPLS-FTN-MIB describes managed objects that are used to
   model and manage the MPLS FEC-to-NHLFE (FTN) mappings that
   take place at an ingress LER.

   A Label Edge Router (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.

   This classification is done using Forwarding Equivalency
   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 through the Next Hop Label Forwarding Entry (NHLFE).

   In the case of an IP-to-MPLS mapping, the FEC objects
   describe IP 5-tuples representing IP source and destination
   ranges, protocol ranges etc. Matching IP packets are mapped
   to an NHLFE that can either be an MPLS LSP or an MPLS TE
   tunnel.









Nadeau, Srinivasan and Farrel                                   [Page 7]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

4.10. MPLS-LINK-BUNDLING-MIB

   MPLS-LINK-BUNDLING-MIB describes managed objects that are
   used to model and manage link bundling in an MPLS network.

   The link bundling feature is designed to aggregate one or
   more similar data channels between a pair of LSRs into a
   bundled link. The data channel is referred to as a TE link
   and is a sub-interface capable of carrying MPLS traffic
   engineered traffic.

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


4.11. MIB 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 "MIB module A depends on MIB module B"
   relationship means that MIB module A uses a structure 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-MIB
   |            ^
   |            |
   |         MPLS-LSR-MIB <-----------------+
   |                                        |
   +<------- MPLS-LDP-MIB ----------------->+
   |         ^                              |
   |         |                              |
   |         +<-- MPLS-LDP-GENERIC-MIB      |
   |         |                              |
   |         +<-- MPLS-LDP-ATM-MIB          |
   |         |                              |
   |         +<-- MPLS-LDP-FRAME-RELAY-MIB  |
   |                                        |
   +<------- MPLS-TE-MIB ------------------>+
   |            ^                           |
   |            |                           |
   +<------- MPLS-FTN-MIB ----------------->+

   Thus:

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

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




Nadeau, Srinivasan and Farrel                                   [Page 8]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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

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


4.12. Dependencies on External MIBs

   With the exception of MPLS-TC-MIB, all the MPLS MIB modules
   have dependencies on the Interfaces MIB [RFC2863].  They
   reference MPLS-capable interfaces in the Interfaces Table
   (ifTable) in this MIB.

   The Interfaces Group of MIB II defines generic managed
   objects for managing interfaces.  The MPLS MIBs 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].


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


5.1.  Tables

   MPLS-LSR-MIB contains the following tables.

   -  The interface configuration table
      (mplsInterfaceConfTable) 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 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-03.txt    February 2003

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

   -  The Traffic Parameter table (mplsTrafficParamTable) is
      used to specify and record LSP related traffic
      parameters.

   -  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 mplsOutSegmentTable, mplsXCTable,
   mplsLabelStackTable and mplsTrafficParamTable.

   mplsMaxLabelStackDepth defines the maximum size of a
   imposed label stack supported at this LSR.

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


5.3.  Notifications

   MPLS-LSR-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.4.  Dependencies Between MIB Module Tables

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











Nadeau, Srinivasan and Farrel                                  [Page 10]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

               mplsInterfacePerfTable
                          ^
                          |
               mplsInterfaceConfTable
                   ^              ^
                   |              |
              +----+              +----+
              |                        |
              | mplsTrafficParamTable  |  mplsLabelStackTable
              |   ^                ^   |      ^
              |   |                |   |      |
    mplsInSegmentTable        mplsOutSegmentTable
          |   |                        |   |
          |   +----> mplsXCTable  <----+   |
          V                                V
    mplsInSegmentPerfTable    mplsOutSegmentPerfTable


6. Tables, Scalars and Notifications in the LDP MIB


6.1.  MIB Modules

   The MIB for LDP contains four MIB modules.  This structure
   makes it easier for an implementation to select only those
   parts of the MIB that are relevant to it.  The MIB Modules
   are the MPLS-LDP-MIB, the MPLS-LDP-GENERIC-MIB, the MPLS-
   LDP-ATM-MIB and the MPLS-LDP-FRAME-RELAY-MIB.

   The MPLS-LDP-MIB defines objects which are specific to LDP
   without any Layer 2 objects.  The MPLS-LDP-GENERIC-MIB
   defines Layer 2 Per Platform Label Space objects for use
   with the MPLS-LDP-MIB and for use on Ehternet.  The MPLS-
   LDP-ATM-MIB defines Layer 2 Asynchronous Transfer Mode
   (ATM) objects for use with the MPLS-LDP-MIB.  The MPLS-LDP-
   FRAME-RELAY-MIB defines Layer 2 FRAME-RELAY objects for use
   with the MPLS-LDP-MIB.

   The MPLS-LDP-MIB Module MUST be supported and at least one
   of the Layer 2 MIB Modules MUST be supported.


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


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 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.
      The 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-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 have arbitrary indexes, scalars are
   provided to supply the next available index.  This applies
   to the mplsLdpEntityTable and the 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 12]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

6.4.  Notifications

   MPLS-LDP-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-MIB.  Instead, the implementer
   is referred to [RFC2573].


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


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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

7.1.  Tables

   MPLS-TE-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 the mplsTunnelTable are indexed by four
      objects.  The source and destination LSR Ids give
      context to the entry, and an index
      (mplsTunnelIndexIndex) 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 mplsTunnelIndexIndex value.  The
      mplsTunnelPrimaryInstance object gives a quick
      reference back to the preferred instance of the tunnel.

      The mplsTunnelIndexIndex 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 mplsTunnelIndexIndex 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 14]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

7.2.  Scalars

   Where tables in the MIB have arbitrary indexes, scalars are
   provided to supply the next available index.  This applies
   to the mplsTunnelTable, the mplsTunnelResourceTable and the
   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 mplsTunnelTrapEnable is used to enable and
   disable notifications from MPLS-TE-MIB.


7.3.  Notifications

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

   -  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-MIB are related as shown on the
   diagram below.  The arrows indicate a reference from one
   table to another.

                        mplsTunnelPerfTable
                                |
                                V
                         mplsTunnelTable
                             ^      ^
                             |      |
        mplsTunnelResourceTable     +---mplsTunnelHopTable
              ^                     |
              |                     +---mplsTunnelCHopTable
   mplsTunnelCRLDPResTable          |
                                    +---mplsTunnelARHopTable








Nadeau, Srinivasan and Farrel                                  [Page 15]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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

8.1.  Tables

   MPLS-FTN-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 Map 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

   A single scalar (mplsFTNIndexNext) exists.  It is used to
   supply the next valid index into the mplsFTNTable.


8.3.  Notifications

   There are no notifications in this MIB.


8.4.  Dependencies Between MIB Tables

   The tables in MPLS-FTN-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 MPLS-LINK-BUNDLING-MIB

9.1.  Tables

   MPLS-LINK-BUNDLING-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 16]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   -  The TE link OSPF traffic engineering table
      (teLinkOspfTeTable) is used for configuring OSPF
      traffic engineering parameters associated with TE
      links.

   -  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 data-bearing channel table
      (dataBearingChannelTable) is used to identify the data-
      bearing channels that are associated with the TE links
      and specify the data-bearing channel generic traffic
      engineering parameters.

   -  The data-bearing channel link descriptor table
      (dataBearingChannelDescriptorTable) is used to list the
      data-bearing channel link descriptors.

   -  The data-bearing channel bandwidth table
      (dataBearingChannelBandwidthTable) is used to report
      priority-based bandwidth values associated with data-
      bearing channels.


9.2.  Scalars

   A single scalar (linkBundlingTrapEnable) exists.  It is
   used to enable and disable notifications from the MIB from
   being issued by a device.


9.3.  Notifications

   A single notification is defined.

   -  linkBundleMismatch is generated when a mismatch of TE
      parameters between members of a bundled link is found.


9.4.  Dependencies Between MIB Module Tables

   The tables in MPLS-LINK-BUNDLING-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.





Nadeau, Srinivasan and Farrel                                  [Page 17]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

                   teLinkTable
                            ^
                            |
   teLinkOspfLinkTable -----+
                            |
   teLinkDescriptorTable ---+
                            |
   teLinkSrlgTable ---------+
                            |
   teLinkBandwidthTable ----+

                   dataBearingChannelTable
                                        ^
                                        |
   dataBearingChannelDescriptorTable ---+
                                        |
   dataBearingChannelBandwidthTable ----+


10.   MIB Table Dependencies Between MPLS MIBs

   Section 4.8 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-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 MIB II defines generic managed
   objects for managing interfaces.  The MPLS MIBs make
   references to interfaces in order that it can be clearly
   determined where the procedures managed by the MIBs should
   be performed.  Additionally, the MPLS MIBs (notably the
   MPLS-TE-MIB and the MPLS-LINK-BUNDLING-MIB) utilize
   interface stacking within the Interface Group.








Nadeau, Srinivasan and Farrel                                  [Page 18]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

11.1. MPLS Tunnels as Interfaces

   The MPLS-TE-MIB builds on the concept of managing MPLS
   Tunnels as logical interfaces.  [RFC2863] states that the
   interfaces table (ifTable) contains information on the
   managed resource's interfaces, and that each sub-layer
   below the internetwork layer of a network interface is
   considered an interface.  Thus, an MPLS Tunnel managed as
   an interface is represented as an entry in the ifTable.
   The interrelation of entries in the ifTable is defined by
   the Interfaces Stack Group defined in [RFC2863].

   When using MPLS Tunnels as interfaces, the interface stack
   table might appear as follows:

   +------------------------------------------------+
   | MPLS tunnel interface ifType = mplsTunnel(150) |
   +------------------------------------------------+
   |        MPLS interface ifType = mpls(166)       |
   +------------------------------------------------+
   |               Underlying layer                 |
   +------------------------------------------------+

   In the diagram above, "Underlying layer" refers to the
   ifIndex of any interface type for which MPLS
   internetworking has been defined.  Examples include ATM,
   Frame Relay, and Ethernet.

   A detailed listing of the mapping between ifTable objects
   and their use for MPLS Tunnels is given in [TCMIB].  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

   The MPLS-LINK-BUNDLING-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:

Nadeau, Srinivasan and Farrel                                  [Page 19]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   +---------------------------------------------------------------+
   | MPLS interface ifType = mpls(166)                             |
   +---------------------------------------------------------------+
   | TE link-interface (bundle) ifType = teLink(200)               |
   +------------------------------+-+------------------------------+
   | TE link ifType = teLink(200) | | TE link ifType = teLink(200) |
   +-------------+--+-------------+ +-------------+--+-------------+
   |opticalTrans |  |opticalTrans | |opticalTrans |  |opticalTrans |
   |ifType = 196 |  |ifType = 196 | |ifType = 196 |  |ifType = 196 |
   +-------------+  +-------------+ +-------------+  +-------------+

   In the above diagram, "opticalTrans" 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 two optical transport links.
   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 [LBMIB].  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 Other MPLS MIBs

   The MPLS-TE-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.

   The MPLS-LSR-MIB includes a table (mplsInterfaceConfTable)
   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 the mplsInterfaceConfTable is deleted. During the life
   of an entry in the mplsInterfaceConfTable a corresponding
   entry is managed in the mplsInterfacePerfTable to show
   performance counters for the MPLS-capable interface.

Nadeau, Srinivasan and Farrel                                  [Page 20]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   The ifIndex that identifies MPLS-capable interfaces also
   plays an important indexing role in the MPLS-LSR-MIB.  In-
   segments (that is incoming LSP labels) are represented in
   the 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.

   The MPLS-LDP-MIB use ifIndex extensively to identify the
   interface over which MPLS is active.

   Within the MPLS-FTN-MIB, the mplsFTNMapTable maps entries
   in the mplsFTNTable to interfaces on which the mplsFTNTable
   entries should be used.  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 the MPLS-LSR-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 the MPLS-LSR-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 the mplsLdpLspTable for
   consistency with LSPs set up using LDP, but there is little
   further value to this since the table gives only pointers
   into the MPLS-LSR-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 the mplsLdpLspTable, mplsFecTable and
   mplsLdpLspFecTable to correlate the LSPs.





Nadeau, Srinivasan and Farrel                                  [Page 21]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   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 the MPLS-TE-
   MIB and the MPLS-LSR-MIB.

   MPLS tunnels may be represented in the MPLS-TE-MIB with
   their cross-connects indicated in the MPLS-LSR-MIB.
   Tunnels are often (although not always) set up with a
   series of constraints that may be represented in the MPLS-
   TE-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 write
   operations to the MIB 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 tables.

   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.


13.1. pwe3 Working Group MIB Modules

   The pwe3 working group has produced a document [PWE3FW]
   that includes a description of the framework for PWE3 MIBs.
   Since the PWE3 architecture includes the use of MPLS as an
   emulated service and as a PSN service, the MPLS MIBs
   described above may be leveraged.  The pwe3 framework
   document describes the interactions between the MPLS MIBs
   and the PWE3 MIBs.







Nadeau, Srinivasan and Farrel                                  [Page 22]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

13.2. ppvpn Working Group MIB Modules

   At present, the ppvpn working group has not included a
   discussion of how the MPLS MIBs interact with the MIBs
   being produced by that working group.  The authors of this
   draft hope to make a forthcoming addition to the ppvpn
   framework document [PPVPNFW] detailing these interactions.
   At the moment, there is only a single MIB module [VPNMIB]
   produced which is discussed next.

13.2.1.  PPVPN-MPLS-VPN-MIB

   PPVPN-MPLS-VPN-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 -- RFC1213-MIB
        |
        +- vpnMIB (TBD) -- PPVPN-MPLS-VPN-MIB

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


13.3. ccamp Working Group MIBs

   At present, there are no MIBs produced by the ccamp working
   group that interact directly with the MPLS MIBs.  However,
   in the future, the existing MPLS MIBs will need to be
   extended and augmented to facilitate the technology being
   produced by this working group.  Along with any MIBs
   produced by the ccamp working group, a separate ccamp-
   specific Management Framework document is expected to be
   issued describing the relationship between these MIBs and
   the existing MPLS (and other) MIBs.


14.   Traffic Engineering Working Group TE MIB

   The tewg has produced a traffic engineering MIB [TEWGMIB]
   containing objects for monitoring traffic engineered MPLS
   based tunnels at their ingress points.

   In many senses the tewg TE MIB contains the same
   information as MPLS-TE-MIB.  Both MIBs can be used to
   monitor MPLS tunnels.



Nadeau, Srinivasan and Farrel                                  [Page 23]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   The tewg TE MIB was initially styled towards simple textual
   representation of information about tunnels.  This made it
   simple to implement as a read only MIB, displaying details
   of existing tunnels that were configured or established
   through other means.

   As write access has been added, the MIB continues to allow
   simple representations of tunnels.

   The price of this simplicity within the MIB, however, is an
   increased complexity in the Management Station or greater
   sophistication in the operator. It is necessary to apply
   parsing rules to text strings to in order to fully
   interpret or to configure tunnels.

   Many advanced features of MPLS tunnels are not included in
   this MIB.


14.1. Choosing Between TE MIBs Modules

   The tewg TE MIB is a flexible MIB designed to manage
   traffic engineering tunnels regardless of the
   implementation technology.  This flexibility and a focus on
   simplicity leads to many compromises.  Some MPLS
   configuration parameters are left out, while others are
   present with only limited options.

   MPLS-TE-MIB should be used for a fully configurable high
   function implementation.  It provides objects for managing
   all features of MPLS Tunnels.

   The tewg TE MIB may be used for quick implementation or for
   non-complex situations.  It may be particularly suitable
   for read-only inspection of tunnels established by some
   other means (such as a CLI).


15.   Security Considerations

   This document describes the inter-relationships amongst the
   different MIBs relevant to MPLS management and as such does
   not have any security implications beyond those imposed by
   these MIBs themselves.


16.   Acknowledgements

   Many small pieces of text in this draft have been borrowed
   from the documents that define the MIBs described here.
   The authors would like to express appreciation to all who
   worked on those MIBs.

   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.

Nadeau, Srinivasan and Farrel                                  [Page 24]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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

   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C,
                 Viswanathan, A. and H. Sjostrand,
                 "Definition of Textual Conventions and
                 OBJECT-IDENTITIES for Multi-Protocol Label
                 Switching (MPLS) Management", Internet Draft
                 <draft-ietf-mpls-tc-mib-03.txt>, January
                 2002 (work in progress).

   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Label Switch Router Management
                 Information Base", Internet Draft <draft-
                 ietf-mpls-lsr-mib-09.txt>, October 2002
                 (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-09.txt>,
                 October 2002 (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-09.txt>,
                 November 2002 (work in progress).







Nadeau, Srinivasan and Farrel                                  [Page 25]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   [FTNMIB]      Nadeau, T., Srinivasan, C., and A.
                 Viswanathan, "Multiprotocol Label Switching
                 (MPLS) FEC-To-NHLFE (FTN) Management
                 Information Base", Internet Draft <draft-
                 ietf-mpls-ftn-mib-05.txt>, November 2002
                 (work in progress).

   [LBMIB]       Dubuc, M., Dharanikota, S., Nadeau, T., J.
                 Lang, "Link Bundling Management Information
                 Base Using SMIv2", Internet Draft <draft-
                 ietf-mpls-bundle-mib-04.txt>, November 2002
                 (work in progress).

   [VPNMIB]      Nadeau, T., Fang, L., Van Der Linde, H.,
                 Brannon, S., Chiussi, F., Dube, J, and M.
                 Tatham, "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).

   [PWE3FW]      Pate, P., Xiao, X., White., C., Kompella.,
                 K., Malis, A., Johnson, T., and T. Nadeau,
                 "Framework for Pseudo Wire Emulation Edge-to-
                 Edge (PWE3)", Internet Draft <draft-ietf-
                 pwe3-framework-01.txt>, June, 2002 (work in
                 progress).

   [PPVPNFW]     Callon, R., Suzuki, M., Gleeson, B., Malis,
                 A., Muthukrishnan, K., Rosen, E., Sargor,
                 C., and J. Yu, "A Framework for Provider
                 Provisioned Virtual Private Networks",
                 Internet Draft <draft-ietf-ppvpn-framework-
                 07.txt>, January 2003 (work in progress).

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


19.   Informative References

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

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

   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for
                 TCP/IP-based Internets", RFC 1155, May 1990.

   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J.
                 Davin, "Simple Network Management Protocol",
                 RFC 1157, May 1990.


Nadeau, Srinivasan and Farrel                                  [Page 26]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", RFC 1212, March 1991.

   [RFC1213]     McCloghrie, K, and M. Rose, "Management
                 Information Base for Network Management of
                 TCP/IP Based Internets", RFC 1213, March
                 1991.

   [RFC1215]     M. Rose, "A Convention for Defining Traps
                 for use with the SNMP", RFC 1215, March
                 1991.

   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Introduction to Community-based
                 SNMPv2", RFC 1901, January 1996.

   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Protocol Operations for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1905, January 1996.

   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Transport Mappings for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1906, January 1996.

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

   [RFC2570]     Case, J., Mundy, R., Partain, D., and B.
                 Stewart, "Introduction to Version 3 of the
                 Internet-standard Network Management
                 Framework", RFC 2570, April 1999.

   [RFC2571]     Harrington, D., Presuhn, R., and B. Wijnen,
                 "An Architecture for Describing SNMP
                 Management Frameworks", RFC 2571, April
                 1999.

   [RFC2572]     Case, J., Harrington D., Presuhn R., and B.
                 Wijnen, "Message Processing and Dispatching
                 for the Simple Network Management Protocol
                 (SNMP)", RFC 2572, April 1999.

   [RFC2573]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2573, April 1999.

   [RFC2574]     Blumenthal, U., and B. Wijnen, "User-based
                 Security Model (USM) for version 3 of the
                 Simple Network Management Protocol
                 (SNMPv3)", RFC 2574, April 1999.

   [RFC2575]     Wijnen, B., Presuhn, R., and K. McCloghrie,
                 "View-based Access Control Model (VACM) for
                 the Simple Network Management Protocol
                 (SNMP)", RFC 2575, April 1999.


Nadeau, Srinivasan and Farrel                                  [Page 27]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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

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

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


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
  Parama Networks, Inc.
  1030 Broad Street
  Shrewsbury, NJ 07702
  Phone: +1-732-544-9120 x731
  Email: cheenu@paramanet.com

  Adrian Farrel
  Movaz Networks, Inc.
  7926 Jones Branch Drive, Suite 615
  McLean, VA 22102
  Phone: +1-703-847-1867
  Email: afarrel@movaz.com












Nadeau, Srinivasan and Farrel                                  [Page 28]


Internet Draft     draft-ietf-mpls-mgmt-overview-03.txt    February 2003

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]