RFC 3815
Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)
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
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].
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
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.
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.
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
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).
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.
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
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)
