Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3815

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

Pages: 106
Proposed Standard
Errata
Part 1 of 5 – Pages 1 to 10
None   None   Next

Top   ToC   RFC3815 - Page 1
Network Working Group                                       J. Cucchiara
Request for Comments: 3815                  Marconi Communications, Inc.
Category: Standards Track                                   H. Sjostrand
                                                             ipUnplugged
                                                              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).

Abstract

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 3.5.2.1. Changing Values After Session Establishment . . . . . . . . . . . . 6 3.5.3. The LDP Entity Statistics Table . . . . . . . . 7
Top   ToC   RFC3815 - 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   RFC3815 - Page 3
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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 [RFC2580].

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 MPLS-LDP-STD-MIB, the MPLS-LDP-GENERIC-STD-MIB, the MPLS-LDP-ATM-STD- MIB and the MPLS-LDP-FRAME-RELAY-STD-MIB. The MPLS-LDP-STD-MIB 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 the MPLS-LDP-STD-MIB. The MPLS-LDP-FRAME-RELAY-STD-MIB defines Layer 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   RFC3815 - 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 document.

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   RFC3815 - 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   RFC3815 - 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
   section.

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.
3.5.2.1. 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   RFC3815 - 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 protocol. 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 session. 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   RFC3815 - 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 intialization.

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

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 information. 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 mplsOutSegmentTable.
Top   ToC   RFC3815 - 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
   implemented.

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

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   RFC3815 - 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 MPLS-LDP-STD-MIB.


(page 10 continued on part 2)

Next Section