RFC 3812
Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)
Pages: 68
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 11
Network Working Group C. Srinivasan Request for Comments: 3812 Bloomberg L.P. Category: Standards Track A. Viswanathan Force10 Networks, Inc. T. Nadeau Cisco Systems, Inc. June 2004 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) 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 Multiprotocol Label Switching (MPLS) based traffic engineering (TE).Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The Internet-Standard Management Framework . . . . . . . . . . 3 4. Feature List . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Summary of Traffic Engineering MIB Module. . . . . . . . 4 6. Brief Description of MIB Objects . . . . . . . . . . . . . . . 4 6.1. mplsTunnelTable. . . . . . . . . . . . . . . . . . . . . 4 6.2. mplsTunnelResourceTable. . . . . . . . . . . . . . . . . 5 6.3. mplsTunnelHopTable . . . . . . . . . . . . . . . . . . . 5 6.4. mplsTunnelARHopTable . . . . . . . . . . . . . . . . . . 5 6.5. mplsTunnelCHoptable. . . . . . . . . . . . . . . . . . . 5 6.6. mplsTunnelPerfTable. . . . . . . . . . . . . . . . . . . 6 6.7. mplsTunnelCRLDPResTable. . . . . . . . . . . . . . . . . 6 7. Use of 32-bit and 64-bit Counters. . . . . . . . . . . . . . . 6
8. Application of the Interface Group to MPLS Tunnels . . . . . . 6 8.1. Support of the MPLS Tunnel Interface by ifTable. . . . . 7 9. Example of Tunnel Setup. . . . . . . . . . . . . . . . . . . . 8 10. The Use of RowPointer. . . . . . . . . . . . . . . . . . . . . 11 11. MPLS Traffic Engineering MIB Definitions . . . . . . . . . . . 11 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 63 13. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 64 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 64 14.1. IANA Considerations for MPLS-TE-STD-MIB. . . . . . . . . 65 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 15.1. Normative References . . . . . . . . . . . . . . . . . . 65 15.2. Informative References . . . . . . . . . . . . . . . . . 66 16. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 67 17. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 681. Introduction
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 modeling a Multiprotocol Label Switching (MPLS) [RFC3031] based traffic engineering. This MIB module should be used in conjunction with the companion document [RFC3813] for MPLS based traffic engineering configuration and management. 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 BCP 14, RFC 2119, reference [RFC2119].2. Terminology
This document uses terminology from the MPLS architecture document [RFC3031] and MPLS Label Switch Router MIB [RFC3813]. Some frequently used terms are described next. An explicitly routed LSP (ERLSP) is referred to as an MPLS tunnel. It consists of in-segment(s) and/or out-segment(s) at the egress/ingress LSRs, each segment being associated with one MPLS interface. These are also referred to as tunnel segments. Additionally, at an intermediate LSR, we model a connection as consisting of one or more in-segments and/or one or more out- segments. The binding or interconnection between in-segments and out-segments is performed using a cross-connect. These objects are defined in the MPLS Label Switch Router MIB [RFC3813].
3. 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].4. Feature List
The MPLS traffic engineering MIB module is designed to satisfy the following requirements and constraints: - The MIB module supports configuration of point-to-point unidirectional tunnels. - MPLS tunnels need not be interfaces, but it is possible to configure a tunnel as an interface. - The MIB module supports tunnel establishment via an MPLS signalling protocol wherein the tunnel parameters are specified using this MIB module at the head end of the LSP, and end-to-end tunnel LSP establishment is accomplished via signalling. The MIB module also supports manually configured tunnels, i.e., those for which label associations at each hop of the tunnel LSP are provisioned by the administrator via the LSR MIB [RFC3813]. - The MIB module supports persistent, as well as non-persistent tunnels.5. Outline
Traffic engineering support for MPLS tunnels requires the following configuration: - Setting up MPLS tunnels along with appropriate configuration parameters. - Configuring tunnel for loose and strict source routed hops.
These actions may need to be accompanied by corresponding actions using [RFC3813] to establish and configure tunnel segments, if this is done manually. Also, the in-segment and out-segment performance tables, mplsInSegmentPerfTable, and mplsOutSegmentPerfTable [RFC3813], should be used to determine performance of the tunnels and tunnel segments, in addition to mplsTunnelPerfTable in this MIB module.5.1. Summary of Traffic Engineering MIB Module
The MIB module objects for performing these actions consist of the following tables: - Tunnel table (mplsTunnelTable) for setting up MPLS tunnels. - Resource table (mplsTunnelResourceTable) for setting up the tunnel resources. - Tunnel specified, actual, and computed hop tables (mplsTunnelHopTable, mplsTunnelARHopTable, and mplsTunnelCHopTable) for strict and loose source routed MPLS tunnel hops. - Tunnel performance table (mplsTunnelPerfTable) for measuring tunnel performance. - CRLDP resource table (mplsTunnelCRLDPResTable) for specifying resource objects applicable to tunnels signaled using CRLDP. These tables are described in the subsequent sections.6. Brief Description of MIB Objects
The objects described in this section support the functionality described in documents [RFC3209] and [RFC3212]. The tables support both manually configured and signaled tunnels.6.1. mplsTunnelTable
The mplsTunnelTable allows new MPLS tunnels to be created between an MPLS LSR and a remote endpoint, and existing tunnels to be reconfigured or removed. Note that we only support point-to-point tunnels, although multipoint-to-point and point-to-multipoint connections are supported by an LSR acting as a cross-connect. Each MPLS tunnel can thus have one out-segment originating at an LSR and/or one in-segment terminating at that LSR.
mplsTunnelTable does not define the in and out segments forming the tunnel. Instead, these are defined by creating rows in the in- segment and out-segment tables, defining relationships in the cross- connect table, and referring to these rows in the mplsTunnelTable using a cross-connect index, mplsTunnelXCIndex. These segment and cross-connect related objects are defined in [RFC3813].6.2. mplsTunnelResourceTable
mplsTunnelResourceTable is used to indicate the resources required for a tunnel. Multiple tunnels may share the same resources by pointing to the same entry in this table. Tunnels that do not share resources must point to separate entries in this table.6.3. mplsTunnelHopTable
mplsTunnelHopTable is used to indicate the hops, strict or loose, for an MPLS tunnel defined in mplsTunnelTable, when it is established via signalling. Multiple tunnels may share the same hops by pointing to the same entry in this table. Each row also has a secondary index, mplsTunnelHopIndex, corresponding to the next hop of this tunnel. The scalar mplsTunnelMaxHops indicates the maximum number of hops that can be specified on each tunnel supported by this LSR. At transit LSRs, this table contains the hops, strict or loose, that apply to the downstream part of this tunnel only. This corresponds to the requested path received through the signaling protocol.6.4. mplsTunnelARHopTable
mplsTunnelARHopTable is used to indicate the actual hops traversed by a tunnel as reported by the MPLS signalling protocol after the tunnel is setup. The support of this table is optional since not all MPLS signalling protocols may support this feature. At transit LSRs, this table contains the actual hops traversed by the tunnel along its entire length if that information is available. This corresponds to the recorded path reported by the MPLS signalling protocol, possibly derived from multiple signaling messages.6.5. mplsTunnelCHoptable
mplsTunnelCHopTable lists the actual hops computed by a constraint- based routing algorithm based on the mplsTunnelHopTable for the MPLS signalling protocol in use. The support of this table is optional since not all implementations may support computation of hop lists using a constraint-based routing protocol.
At transit LSRs, this table contains the hops computed to apply to the downstream part of this tunnel. This corresponds to the requested path signaled from this LSR through the signaling protocol.6.6. mplsTunnelPerfTable
mplsTunnelPerfTable provides several counters to measure the performance of the MPLS tunnels. This table augments mplsTunnelTable.6.7. mplsTunnelCRLDPResTable
mplsTunnelCRLDPResTable contains resource information for those tunnels that are signaled using CRLDP [RFC3212]. This is a sparse extension to mplsTunnelResourceTable and is also indexed by mplsTunnelResourceIndex. As with mplsTunnelResourceTable, multiple tunnels may share the same resources by pointing to the same entry in this table. Tunnels that do not share resources must point to separate entries in this table. The mplsTunnelCRLDPResTable may be supported only by implementations that support the CR-LDP signaling protocol.7. Use of 32-bit and 64-bit Counters
64-bit counters are provided in this MIB module for high-speed interfaces where the use of 32-bit counters might be impractical. The requirements on the use of 32-bit and 64-bit counters (copied verbatim from [RFC2863]) are as follows: For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported.8. Application of the Interface Group to MPLS Tunnels
The Interfaces Group of MIB II defines generic managed objects for managing interfaces. This memo contains the media-specific extensions to the Interfaces Group for managing MPLS Tunnels as logical interfaces. This memo assumes the interpretation of the Interfaces Group to be in accordance with [RFC2863] which 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, the MPLS interface is represented as an entry in the ifTable. The inter-relation 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 above diagram, "Underlying Layer" refers to the ifIndex of any interface type for which MPLS internetworking has been defined. Examples include ATM, Frame Relay, and Ethernet.8.1. Support of the MPLS Tunnel Interface by ifTable
Some specific interpretations of the ifTable for those MPLS tunnels represented as interfaces follow: Object Use for the MPLS tunnel. ifIndex Each MPLS tunnel is represented by an ifEntry. ifDescr Description of the MPLS tunnel. ifType The value that is allocated for the MPLS tunnel is 150. ifSpeed The total bandwidth in bits per second for use by the MPLS tunnel. ifPhysAddress Unused. ifAdminStatus See [RFC2863]. ifOperStatus This value reflects the actual operational status of the MPLS tunnel. Assumes the value down(2) if the MPLS tunnel is down. ifLastChange See [RFC2863].
ifInOctets The number of octets received over the
MPLS tunnel.
ifOutOctets The number of octets transmitted over
the MPLS tunnel.
ifInErrors The number of labeled packets dropped
due to uncorrectable errors.
ifInUnknownProtos The number of received packets
discarded during packet header
validation, including packets with
unrecognized label values.
ifOutErrors See [RFC2863].
ifName Textual name (unique on this system) of
the MPLS tunnel or an octet string of
zero length.
ifLinkUpDownTrapEnable
Default is disabled (2).
ifConnectorPresent Set to false (2).
ifHighSpeed See [RFC2863].
ifHCInOctets The 64-bit version of ifInOctets;
supported if required by the compliance
statements in [RFC2863].
ifHCOutOctets The 64-bit version of ifOutOctets;
supported if required by the compliance
statements in [RFC2863].
ifAlias The non-volatile 'alias' name for the
MPLS tunnel as specified by a network
manager.
9. Example of Tunnel Setup
This section contains an example of which MIB objects should be
modified if one would like to create a best effort, loosely routed,
unidirectional traffic engineered tunnel, which spans two hops of a
simple network. Note that these objects should be created on the
"head-end" LSR. Those objects relevant to illustrating the
relationships amongst different tables are shown here. Other objects
may be needed before conceptual row activation can happen.
The RowStatus values shown in this section are those to be used in the set request, typically createAndGo(4) which is used to create the conceptual row and have its status immediately set to active. A subsequent retrieval operation on the conceptual row will return a different value, such as active(1). Please see [RFC2579] for a detailed discussion on the use of RowStatus. In mplsTunnelResourceTable: { mplsTunnelResourceIndex = 5, mplsTunnelResourceMaxRate = 0, mplsTunnelResourceMeanRate = 0, mplsTunnelResourceMaxBurstSize = 0, mplsTunnelResourceMeanBurstSize = 0, mplsTunnelResourceExBurstSize = 0, mplsTunnelResourceExBurstSize = unspecified (1), mplsTunnelResourceWeight = 0, -- Mandatory parameters needed to activate the row go here mplsTunnelResourceRowStatus = createAndGo (4) } The next two instances of mplsTunnelHopEntry are used to denote the hops this tunnel will take across the network. The following denotes the beginning of the tunnel, or the first hop. We have used the fictitious LSR identified by "192.168.100.1" as our example head-end router. In mplsTunnelHopTable: { mplsTunnelHopListIndex = 1, mplsTunnelPathOptionIndex = 1, mplsTunnelHopIndex = 1, mplsTunnelHopAddrType = ipv4 (1), mplsTunnelHopIpAddr = "192.168.100.1", mplsTunnelHopIpPrefixLen = 32, mplsTunnelHopType = strict (2), mplsTunnelHopInclude = true (1), mplsTunnelHopPathOptionName = "Here to there", mplsTunnelHopEntryPathComp = explicit (2), -- Mandatory parameters needed to activate the row go here mplsTunnelHopRowStatus = createAndGo (4) }
The following denotes the end of the tunnel, or the last hop in our
example. We have used the fictitious LSR identified by
"192.168.101.1" as our end router.
In mplsTunnelHopTable:
{
mplsTunnelHopListIndex = 1,
mplsTunnelPathOptionIndex = 1,
mplsTunnelHopIndex = 2,
mplsTunnelHopAddrType = ipv4 (1),
mplsTunnelHopIpAddr = "192.168.101.1",
mplsTunnelHopIpPrefixLen = 32,
mplsTunnelHopType = loose (2),
mplsTunnelHopInclude = true (1),
mplsTunnelHopPathOptionName = "Here to there",
mplsTunnelHopEntryPathComp = explicit (2),
-- Mandatory parameters needed to activate the row go here
mplsTunnelHopRowStatus = createAndGo (4)
}
The following denotes the configured tunnel "head" entry:
In mplsTunnelTable:
{
mplsTunnelIndex = 1,
mplsTunnelInstance = 0,
mplsTunnelIngressLSRId = 192.168.100.1,
mplsTunnelEgressLSRId = 192.168.101.1,
mplsTunnelName = "My first tunnel",
mplsTunnelDescr = "Here to there",
mplsTunnelIsIf = true (1),
-- RowPointer MUST point to the first accessible column
mplsTunnelXCPointer = 0.0,
mplsTunnelSignallingProto = none (1),
mplsTunnelSetupPrio = 0,
mplsTunnelHoldingPrio = 0,
mplsTunnelSessionAttributes = 0,
mplsTunnelLocalProtectInUse = false (0),
-- RowPointer MUST point to the first accessible column
mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5,
mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1,
mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAnyAffinity = 0,
mplsTunnelPathInUse = 1,
mplsTunnelRole = head (1),
-- Mandatory parameters needed to activate the row go here
mplsTunnelRowStatus = createAndGo (4)
}
Note that any active or signaled instances of the above tunnel would
appear with the same primary mplsTunnelIndex, but would have values
greater than 0 for mplsTunnelInstance. They would also have other
objects such as the mplsTunnelXCPointer set accordingly.
10. The Use of RowPointer
RowPointer is a textual convention used to identify a conceptual row
in a conceptual table in a MIB by pointing to the first accessible
object. In this MIB module, in mplsTunnelTable, the objects
mplsTunnelXCPointer and mplsTunnelResourcePointer are of type
RowPointer. The object mplsTunnelXCPointer points to a specific
entry in the mplsXCTable [RFC3813]. This entry in the mplsXCTable is
the associated LSP for the given MPLS tunnel entry. The object
mplsTunnelResourcePointer points to a specific entry in a traffic
parameter table. An example of such a traffic parameter table is
mplsTunnelResourceTable. It indicates a specific instance of a
traffic parameter entry that is associated with a given MPLS tunnel
entry. These RowPointer objects MUST point to the first instance of
the first accessible columnar object in the appropriate conceptual
row in order to allow the manager to find the appropriate
corresponding entry in either MPLS-LSR-STD-MIB [RFC3813] or MPLS-TE-
STD-MIB. If object mplsTunnelXCPointer returns zeroDotZero, it
implies that there is no LSP associated with that particular instance
of tunnel entry. If object mplsTunnelResourcePointer returns
zeroDotZero, it implies that there is no QoS resource associated with
that particular instance of tunnel entry.
(page 11 continued on part 2)