Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3812

Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)

Pages: 68
Proposed Standard
Part 1 of 3 – Pages 1 to 11
None   None   Next

Top   ToC   RFC3812 - Page 1
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
Top   ToC   RFC3812 - Page 2
   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 . . . . . . . . . . . . . . . . . . . 68

1. 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].
Top   ToC   RFC3812 - Page 3

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.
Top   ToC   RFC3812 - Page 4
   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.
Top   ToC   RFC3812 - Page 5
   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.
Top   ToC   RFC3812 - Page 6
   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
Top   ToC   RFC3812 - Page 7
   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].
Top   ToC   RFC3812 - Page 8
   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.
Top   ToC   RFC3812 - Page 9
   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)
   }
Top   ToC   RFC3812 - Page 10
   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,
Top   ToC   RFC3812 - Page 11
     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)

Next Section