tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3812

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

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

Part 1 of 3, p. 1 to 11
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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 RFC Part