Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3815

Proposed STD
Pages: 106
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)

Part 1 of 5, p. 1 to 10
None       Next RFC Part


Top       ToC       Page 1 
Network Working Group                                       J. Cucchiara
Request for Comments: 3815                  Marconi Communications, Inc.
Category: Standards Track                                   H. Sjostrand
                                                              J. Luciani
                                            Marconi Communications, Inc.
                                                               June 2004

                 Definitions of Managed Objects for the
                 Multiprotocol Label Switching (MPLS),
                   Label Distribution Protocol (LDP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).


   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for the Multiprotocol
   Label Switching, Label Distribution Protocol (LDP).

Table of Contents

   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.   The Internet-Standard Management Framework. . . . . . . . . .  3
   3.   Structure of the MIB Modules. . . . . . . . . . . . . . . . .  3
        3.1.  Overview. . . . . . . . . . . . . . . . . . . . . . . .  3
        3.2.  Future Considerations . . . . . . . . . . . . . . . . .  4
        3.3.  Interface Indexing. . . . . . . . . . . . . . . . . . .  4
        3.4.  Differences from the LDP Specification. . . . . . . . .  4
        3.5.  The MPLS-LDP-STD-MIB Module . . . . . . . . . . . . . .  5
              3.5.1.  LDP Scalar Objects. . . . . . . . . . . . . . .  5
              3.5.2.  The LDP Entity Table. . . . . . . . . . . . . .  6
              Changing Values After Session
                                Establishment . . . . . . . . . . . .  6
              3.5.3.  The LDP Entity Statistics Table . . . . . . . .  7

Top      ToC       Page 2 
              3.5.4.  The LDP Peer Table. . . . . . . . . . . . . . .  7
              3.5.5.  The LDP Session Table . . . . . . . . . . . . .  8
              3.5.6.  The LDP Session Statistics Table. . . . . . . .  8
              3.5.7.  The LDP Hello Adjacency Table . . . . . . . . .  8
              3.5.8.  The LDP LSP Tables. . . . . . . . . . . . . . .  8
              3.5.9.  The FEC Tables. . . . . . . . . . . . . . . . .  9
              3.5.10. The LDP Session Peer Address Table. . . . . . .  9
        3.6.  LDP Notifications . . . . . . . . . . . . . . . . . . .  9
        3.7.  LDP Notification Frequency. . . . . . . . . . . . . . . 10
   4.   MPLS Label Distribution Protocol MIB Definitions. . . . . . . 10
        4.1.  The MPLS-LDP-ATM-STD-MIB Module . . . . . . . . . . . . 60
              4.1.1.  The LDP Entity ATM Table. . . . . . . . . . . . 61
              4.1.2.  The LDP Entity ATM Label Range Table. . . . . . 61
              4.1.3.  The LDP ATM Session Table . . . . . . . . . . . 61
        4.2.  The MPLS-LDP-FRAME-RELAY-STD-MIB Module . . . . . . . . 77
              4.2.1.  The LDP Entity Frame Relay Table. . . . . . . . 77
              4.2.2.  The LDP Entity Frame Relay Label Range Table. . 77
              4.2.3.  The LDP Frame Relay Session Table . . . . . . . 77
        4.3.  The MPLS-LDP-GENERIC-STD-MIB Module . . . . . . . . . . 91
   5.   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 98
   6.   References. . . . . . . . . . . . . . . . . . . . . . . . . . 98
        6.1.  Normative References. . . . . . . . . . . . . . . . . . 98
        6.2.  Informative References. . . . . . . . . . . . . . . . .100
   7.   Security Considerations . . . . . . . . . . . . . . . . . . .100
        7.1.  Security Considerations for MPLS-LDP-STD-MIB. . . . . .100
        7.2.  Security Considerations for MPLS-LDP-ATM-STD-MIB. . . .101
        7.3.  Security Considerations for
              MPLS-LDP-FRAME-RELAY-STD-MIB. . . . . . . . . . . . . .102
        7.4.  Security Considerations for MPLS-LDP-GENERIC-STD-MIB. .103
        7.5.  Additional Security Considerations. . . . . . . . . . .103
   8.   IANA Considerations . . . . . . . . . . . . . . . . . . . . .104
        8.1.  IANA Considerations for MPLS-LDP-STD-MIB. . . . . . . .104
        8.2.  IANA Considerations for MPLS-LDP-ATM-STD-MIB. . . . . .104
        8.3.  IANA Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB. .104
        8.4.  IANA Considerations for MPLS-LDP-GENERIC-STD-MIB. . . .104
   9.   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .105
   10.  Full Copyright Statement. . . . . . . . . . . . . . . . . . .106

1.  Introduction

   This document defines 4 MIB Modules which together support the
   configuration and monitoring of the Label Distribution Protocol
   (LDP).  The Label Distribution Protocol (LDP) [RFC3036] is one type
   of Multiprotocol Label Switching (MPLS) protocols described in
   [RFC3031] and [RFC3032].  Utilizing all 4 MIB Modules allows an
   operator to configure LDP sessions using 3 different Layer 2 media.
   The Layer 2 media supported by the MIB Modules are Ethernet, ATM and
   Frame Relay as described in [RFC3036], [RFC3034] and [RFC3035].

Top      ToC       Page 3 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   For an introduction to the concepts of MPLS, see [RFC3031].  For
   further on LDP refer to [RFC3037] and [RFC3215].

2.  The Internet-Standard 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 memo 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

3.  Structure of the MIB Modules

   This section describes the structure of the LDP MIB Modules.

3.1.  Overview

   There are 4 MIB Modules in this document.  These MIB Modules are the
   defines objects which are common to all LDP implementations.  The
   MPLS-LDP-GENERIC-STD-MIB defines Layer 2 Per Platform Label Space
   objects for use with the MPLS-LDP-STD-MIB.  The MPLS-LDP-ATM-STD-MIB
   defines Layer 2 Asynchronous Transfer Mode (ATM) objects for use with
   2 FRAME-RELAY objects for use with the MPLS-LDP-STD-MIB.

   The MPLS-LDP-STD-MIB Module MUST be implemented and at least one of
   the Layer 2 MIB Modules MUST be implemented by an Agent developer on
   an Label Switching Router (LSR) or Label Edge Router (LER).  As an
   example, if a Label Switching Router (LSR) or Label Edge Router (LER)
   implementation intends to support LDP utilizing a Layer 2 of
   Ethernet, then the MPLS-LDP-STD-MIB and the MPLS-LDP-GENERIC-STD-MIB
   Modules MUST implemented.  If an LSR/LER implementation intends to
   support LDP utilizing a Layer 2 of ATM, then the MPLS-LDP-STD-MIB
   Module and the MPLS-LDP-ATM-MIB Module MUST be implemented.  If an
   LSR/LER implementation intends to support LDP utilizing a Layer 2 of

Top      ToC       Page 4 
   FRAME-RELAY, then the MPLS-LDP-STD-MIB Module and the MPLS-LDP-FRAME-
   RELAY-STD-MIB Module MUST be implemented.  An LDP implementation that
   utilizes all three Layer 2 media (Ethernet, Frame-Relay, ATM) MUST
   support all 4 MIB Modules.  Each of the Modules will be discussed in
   detail in the following sections.

   There are 2 compliance statements for each MIB Module.  One
   compliance statement is for full compliance which allows both
   configuration and monitoring via SNMP.  The other compliance
   statement is for read-only compliance which allows only monitoring
   via SNMP.

3.2.  Future Considerations

   The LDP Specification [RFC3036] does not specify the use of VPNs or
   multicast for LDP, and thus, objects related to these areas have not
   been included.

   [RFC2684] does not describe VP merge capability and so this feature
   has not been included.

   These areas need to be specified in the LDP Specification or other
   specifications prior to being added in this or any other MIB

3.3.  Interface Indexing

   Interface Indexes as specified in [RFC2863] are used in these MIB
   Modules.  The descriptions of the ifIndexes denote which ifIndex is
   being used.  The use of ifIndex is for actual existing connections.

3.4.  Differences from the LDP Specification

   Currently, there are 3 differences between this specification and the
   LDP Specification.  As described in the Introduction, this document
   is almost entirely based on the LDP specification.  The differences
   are documented here.

   The first difference is that the LDP Entity Table contains some
   DEFVAL clauses which are not specified explicitly in the LDP
   Specification.  These values, although not documented in the LDP
   Specification, are widely used by existing LDP MIB implementations
   and thus, have been adopted within this MPLS-LDP-STD-MIB module.
   Please note, they can certainly be changed during row creation or a
   subsequent SET request.

Top      ToC       Page 5 
   A second difference is the mplsLdpEntityGenericLRTable in the MPLS-
   LDP-GENERIC-STD-MIB Module.  This table, although provided as a way
   to reserve a range of generic labels, does not exist in the LDP
   Specification.  It was added to the MIB due to a request from the
   working group and because this table was considered useful for
   reserving a range of generic labels.

   The third difference is documented by the TEXTUAL-CONVENTION,
   MplsAtmVcIdentifier which is in the MPLS-TC-STD-MIB [RFC3811].  This
   TC was added to restrict vci values to be greater than 31 as
   described in RFC 3035 [RFC3035].

3.5.  The MPLS-LDP-STD-MIB Module

   This MIB Module contains objects which are common to all LDP
   implementations.  This MIB Module MUST always be implemented along
   with one or more of the Layer 2 MIB Modules.  This MIB Module IMPORTS
   IndexInteger and IndexIntegerNextFree TEXTUAL-CONVENTIONs from
   [RFC3289], and IMPORTS InetAddressPrefixLength, InetAddressType,
   InetAddressInetPortNumber TEXTUAL-CONVENTIONs from [RFC3291].

   The mplsLdpEntityTable table allows the Label Edge Router (LER) or
   the Label Switching Router (LSR) to initiate and/or receive requests
   to establish LDP sessions.  As the LDP protocol distributes labels
   and establishes sessions with Peers most of the tables in this module
   are populated by the agent as instructed by the LDP protocol.  The
   exception is the mplsFecTable and the mplsLdpLspFecTable which can be
   configured by the operator to specify Forwarding Equivalence Class
   information for an LSP.

   Some scalars and each table in the MPLS-LDP-STD-MIB Module are
   described in the following subsections.

3.5.1.  LDP Scalar Objects

   There are several scalar objects in the LDP MIB module.  The
   mplsLdpLsrId is a read-only scalar object which reports Label
   Switching Router's (LSR's) Identifier.  This MUST be a globally
   unique value, such as the 32-bit router ID assigned to the LSR.

   The mplsLdpLsrLoopDetectionCapable scalar object denotes whether the
   LSR is capable of supporting loop detection and if so, which form of
   loop detection.

Top      ToC       Page 6 
   There are two LastChange scalar objects, mplsLdpEntityLastChange and
   mplsLdpPeerLastChange.  These objects give an indication of there was
   a change in the number of entries in the table, or if any of the
   values in the respective tables changed.  Please see the object's
   description for more details.

   The mplsLdpEntityIndexNext scalar object is described in the next

3.5.2.  The LDP Entity Table

   The MPLS-LDP-STD-MIB provides objects to configure/set-up potential
   LDP sessions on a specific LSR/LER.  The mplsLdpEntityTable is used
   to configure information which is used by the LDP protocol to setup
   potential LDP Sessions.

   Each entry/row in this table represents a single LDP Entity.  There
   is no maximum number of LDP Entities specified.  However, there is an
   mplsLdpEntityIndexNext object which should be retrieved by the
   command generator prior to creating an LDP Entity.  If the
   mplsLdpEntityIndexNext object is zero, this indicates that the
   LSR/LER is not able to create another LDP Entity at that time.  Changing Values After Session Establishment

   One way to manually modify a session's parameters is by using SNMP to
   change the MIB objects related to that session.  Please note, special
   care should be taken if MIB objects which are used in the MPLS LDP
   Session Initialization need to be modified.  If the modification of
   any of these MIB variables takes place anytime after the start of
   session intialization, then the entire session must be halted.  Any
   information learned by that session must be discarded.  The objects
   should then be modified, and session initialization started.
   Assuming that the configuration was done correctly, then a new
   session will be created.

   For example, assume that an operator wishes to change the
   configuration of a Label Range which is used by a Session that has
   already been established.  The operator should change the
   mplsLdpEntityAdminStatus to "disable(2)".  Setting the
   mplsLdpEntityAdminStatus to "disable(2)" will cause the session to be
   torn down (i.e., this will signal to LDP that it should send out tear
   down messages for that session).  Also, all information related to
   that session should be removed from this MIB by the Agent.  This
   includes Peer information (i.e., relevant row in the mplsPeerTable)
   and Session statistics (i.e., relevant row in the
   mplsLdpSessionTable).  Also, if the MPLS-LSR-STD-MIB module [RFC3813]
   is implemented and the optional Mapping Table objects are

Top      ToC       Page 7 
   implemented, then all information related to the LSPs in this session
   should be removed from these MIB modules. [For more information
   please see the section on "The Mapping Tables".]  At this point, the
   operator could modify the Label Range.  Lastly, the operator should
   set the mplsLdpEntityAdminStatus to "enable(1)".  At this point
   session initialization should occur.  The LDP Entity goes through the
   Session Initialization in order to communicate the new Label Ranges
   to the Peer and establish new LSPs.

3.5.3.  The LDP Entity Statistics Table

   The mplsLpdEntityStatsTable is a read-only table which contains
   statistical information related to failed attempts to establish
   sessions.  Each row in this table AUGMENTS an mplsLdpEntityEntry.
   This table could be used to give insight into how to reconfigure
   values so that a session could be successfully established.  For
   example, if the mplsLdpEntityStatsSessionRejectedLRErrors Counter
   object was increasing, then this would indicate that the Label Range
   (LR) may need to be adjusted.

3.5.4.  The LDP Peer Table

   The mplsLdpPeerTable is a read-only table which contains information
   about LDP Peers known to LDP Entities.  In other words, the Peer
   information is learned by LDP through initialization or discovery.
   This table should be populated by the agent as directed by the LDP

   A row in this table is related to one or more rows in the Hello
   Adjacency Table and related to a single row in the Session Table.
   The values in the Peer table are specific to a Peer and may or may
   not be the same values used in the session.  The reason is that the
   Peer and Entity negotiate certain values.  The Entity's values are
   configured in the mplsLdpEntityTable and the Peer's values are
   learned (and placed into the mplsLdpPeerTable).  The
   mplsLdpSessionTable shows the values used in establishing the

   One example, of when the Peer's values and the Session's values may
   differ is with the Peer's Path Limit information.  The Peer's Path
   Limit information is learned from the session initialization phase.
   The actual value for the Path Vector Limit is the Peer's value and
   may not be the same value that appears in the session.  There could
   be a mismatch in this value between the Entity and the Peer.  In the
   event of a mismatch, then the session will use the Path Limit set by
   the Entity (and not the Peer).

Top      ToC       Page 8 
   The Peer Table information was placed in a separate table from the
   Session information to allow for a more comprehensive and coherent
   MIB model.

3.5.5.  The LDP Session Table

   The mplsLdpSessionTable is a read-only table.  Each entry in this
   table represents a single session between an LDP Entity and a Peer.
   The mplsLdpSessionEntry AUGMENTS the mplsLdpPeerEntry.

   The information in this table is learned during session
   establishment.  NOTE: rows in this table will appear during session

3.5.6.  The LDP Session Statistics Table

   The mplsLdpSessionStatsTable is a read-only table which contains
   statistical information on sessions.  This table AUGMENTS the

3.5.7.  The LDP Hello Adjacency Table

   This is a table of all adjacencies between all LDP Entities and all
   LDP Peers.  A Session may have one or more adjacencies.  A session
   should not have zero adjacencies, because this indicates that the
   session has lost contact with the Peer.  A session which has zero
   Hello Adjacencies should be removed.

3.5.8.  The LDP LSP Tables

   The Label Information Base (LIB) contains information about labels
   learned by the LSR.  The LIB for LDP, CR-LDP and MPLS-RSVP (i.e., all
   currently defined MPLS protocols) is represented in the LSR MIB
   [RFC3813].  The LIB is represented by the LSR MIB's mplsXCTable (mpls
   Cross Connect Table), mplsInSegmentTable (mpls In Segment Table) and
   the mplsOutSegmentTable (mpls Out Segment Table).  The mplsXCTable
   models the cross-connection of the incoming label with a specific
   outgoing label.  The mplsInSegmentTable stores the incoming label's
   information, and the mplsOutSegmentTable stores the outgoing label's

   The LDP Session that created the LSP and the LSP's (incoming label,
   outgoing label) pair along with other information is contained in the
   MPLS-LSR-STD-MIB module's mplsXCTable, the mplsInSegmentTable and the

Top      ToC       Page 9 
   In order to utilize the MPLS-LSR-STD-MIB module's mplsXCTable,
   mplsInSegmentTable and mplsOutSegmentTable for LDP LSPs, there needs
   to be a mechanism to associate LDP sessions with LDP LSPs created as
   a result of those LDP sessions.  The mplsInSegmentLdpLspTable and
   mplsOutSegmentLdpLspTable in this MIB contain information to find the
   LDP LSP entries in the mplsInSegmentTable, mplsOutSegmentTable and
   the mplsXCTable.

   These two tables, the mplsInSegmentLdpLspTable and
   mplsOutSegmentLdpLspTable, have been made optional in the conformance
   section of the MIB.  They only need to be supported if the LSR MIBs
   mplsInSegmentTable, mplsOutSegmentTable and mplsXCTable are

   As discussed in the section, "Changing Values after Session
   Establishment", if a session is torn down, then all the information
   related to this session, must be removed from the both LDP MIB and,
   if implemented, from the LSR MIB.

3.5.9.  The FEC Tables

   The mplsLdpFecTable is a table which contains FEC (Forwarding
   Equivalence Class) information.  Each entry/row represents a single
   FEC Element.  There is also an LDP LSP FEC Table, mplsLdpLspFecTable,
   which associates FECs with the LSPs.

3.5.10.  The LDP Session Peer Address Table

   The mplsLdpSessionPeerAddrTable is a table which extends the
   mplsLdpSessionTable.  This table is a read-only table which stores
   Addresses learned after session initialization via Address Message

3.6.  LDP Notifications

   Currently, there are several notifications which are specific for
   LDP.  These are described in this section.  There are no objects
   which enable or disable notifications from being generated.  RFC 3413
   [RFC3413] contains MIB modules which can be implemented that will
   enable or disable these notifications from being generated.

   The mplsLdpInitSessionThresholdExceeded notification indicates to the
   operator that there may be a misconfigured mplsLdpEntityEntry because
   the session associated with this Entity is not being established, and
   the Entity keeps trying to establish the session.  A side effect of
   this situation is that a row in the mplsLdpSessionTable may not be
   reaching the operational state as indicated by the
   mplsLdpSessionState object.  If the value of

Top      ToC       Page 10 
   mplsLdpEntityInitSessionThreshold is 0 (zero) then this is equal to
   specifying the value of infinity for the threshold, and the
   mplsLdpInitSessionThresholdExceeded notification will never be sent.

   The mplsLdpPathVectorLimitMismatch notification is generated when
   there is a mismatch in the Path Vector Limits between the Entity and
   Peer during session initialization.  The session uses the value which
   is configured as the Entity's Path Vector Limit.  However, a
   notification should be generated to indicate that a mismatch
   occurred.  For further details, please see Section 3.5.3 of the LDP
   Specification [RFC3036].

   The mplsLdpSessionUp and mplsLdpSessionDown notifications are
   generated when there is an appropriate change in the
   mplsLdpSessionState object, e.g., when sessions change state (Up to
   Down for the mplsLdpSessionDown notification, or Down to Up for the
   mplsLdpSessionUp notification).  There was discussion about combining
   these two notifications into a single notification, however, some NMS
   applications can utilize two different notifications, rather than
   having to parse the varbind list of a single notification.  For
   example, the SessionDown is matched to a SessionUp notification more
   easily by some NMS applications, than having to parse a Varbind list
   in a SessionChange type of notification.

3.7.  LDP Notification Frequency

   LDP Notifications are expected to be few in number when LDP is
   ubiquitously deployed in a relatively stable network.  A notification
   receiver, e.g., an NMS, that receives these notifications should not
   be overwhelmed by the frequency of LDP notifications.  If this
   assertion proves to be inaccurate, then a throttling object to
   throttle these notifications may be added to future versions of the

(page 10 continued on part 2)

Next RFC Part