Network Working Group                                     T. Nadeau, Ed.
Request for Comment: 4802                            Cisco Systems, Inc.
Category: Standards Track                                 A. Farrel, Ed.
                                                      Old Dog Consulting
                                                           February 2007


           Generalized Multiprotocol Label Switching (GMPLS)
            Traffic Engineering Management Information Base

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 IETF Trust (2007).

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 Generalized
   Multiprotocol Label Switching (GMPLS)-based traffic engineering.

Table of Contents

   1. Introduction ....................................................2
      1.1. Migration Strategy .........................................3
   2. Terminology .....................................................3
   3. The Internet-Standard Management Framework ......................4
   4. Outline .........................................................4
      4.1. Summary of GMPLS Traffic Engineering MIB Module ............4
   5. Brief Description of GMPLS TE MIB Objects .......................5
      5.1. gmplsTunnelTable ...........................................5
      5.2. gmplsTunnelHopTable ........................................6
      5.3. gmplsTunnelARHopTable ......................................6
      5.4. gmplsTunnelCHopTable .......................................6
      5.5. gmplsTunnelErrorTable ......................................6
      5.6. gmplsTunnelReversePerfTable ................................6
      5.7. Use of 32-bit and 64-bit Counters ..........................7
   6. Cross-referencing to the gmplsLabelTable ........................7
   7. Example of GMPLS Tunnel Setup ...................................8
   8. GMPLS Traffic Engineering MIB Module ...........................11
   9. Security Considerations ........................................47
   10. Acknowledgments ...............................................48
   11. IANA Considerations ...........................................49
      11.1. IANA Considerations for GMPLS-TE-STD-MIB .................49
      11.2. Dependence on IANA MIB Modules ...........................49
           11.2.1. IANA-GMPLS-TC-MIB Definition ......................50
   12. References ....................................................56
      12.1. Normative References .....................................56
      12.2. Informative References ...................................58

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 Generalized
   Multiprotocol Label Switching (GMPLS) [RFC3945] based traffic
   engineering (TE).  The tables and objects defined in this document
   extend those defined in the equivalent document for MPLS traffic
   engineering [RFC3812], and management of GMPLS traffic engineering is
   built on management of MPLS traffic engineering.

   The MIB modules in this document should be used in conjunction with
   the companion document [RFC4803] for GMPLS-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, [RFC2119].

1.1.  Migration Strategy

   MPLS-TE Label Switched paths (LSPs) may be modeled and managed using
   the MPLS-TE-STD-MIB module [RFC3812].

   Label Switching Routers (LSRs) may be migrated to model and manage
   their TE LSPs using the MIB modules in this document in order to
   migrate the LSRs to GMPLS support, or to take advantage of additional
   MIB objects defined in these MIB modules that are applicable to
   MPLS-TE.

   The GMPLS TE MIB module (GMPLS-TE-STD-MIB) defined in this document
   extends the MPLS-TE-STD-MIB module [RFC3812] through a series of
   augmentations and sparse augmentations of the MIB tables.  The only
   additions are for support of GMPLS or to support the increased
   complexity of MPLS and GMPLS systems.

   In order to migrate from MPLS-TE-STD-MIB support to GMPLS-TE-STD-MIB
   support, an implementation needs only to add support for the
   additional tables and objects defined in GMPLS-TE-STD-MIB.  The
   gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to allow an
   MPLS-TE LSP tunnel to benefit from the additional objects and tables
   of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols.

   The companion document for modeling and managing GMPLS-based LSRs
   [RFC4803] extends the MPLS-LSR-STD-MIB module [RFC3813] with the same
   intentions.

   Textual conventions are defined in [RFC3811] and the IANA-GMPLS-TC-
   MIB module.

2.  Terminology

   This document uses terminology from the MPLS architecture document
   [RFC3031], from the GMPLS architecture document [RFC3945], and from
   the MPLS Traffic Engineering MIB [RFC3812].  Some frequently used
   terms are described next.

   An explicitly routed LSP (ERLSP) is referred to as a GMPLS tunnel.
   It consists of in-segment(s) and/or out-segment(s) at the
   egress/ingress LSRs, each segment being associated with one GMPLS-
   enabled 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 segment and cross-connect objects are defined in the MPLS Label
   Switching Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the
   GMPLS Label Switching Router MIB (GMPLS-LSR-STD-MIB) [RFC4803] for
   the GMPLS-specific extensions to these objects.

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

   Support for GMPLS traffic-engineered tunnels requires the following
   configuration.

   -  Setting up tunnels with appropriate MPLS configuration parameters
      using [RFC3812].

   -  Extending the tunnel definitions with GMPLS configuration
      parameters.

   -  Configuring loose and strict source routed tunnel hops.

   These actions may need to be accompanied with corresponding actions
   using [RFC3813] and [RFC4803] 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, although it should be
   noted that those tables may not be appropriate for measuring
   performance on some types of GMPLS links.

4.1.  Summary of GMPLS Traffic Engineering MIB Module

   The following tables contain MIB objects for performing the actions
   listed above when they cannot be performed solely using MIB objects
   defined in MPLS-TE-STD-MIB [RFC3812].

   -  Tunnel table (gmplsTunnelTable) for providing GMPLS-specific
      tunnel configuration parameters.

   -  Tunnel hop, actual tunnel hop, and computed tunnel hop tables
      (gmplsTunnelHopTable, gmplsTunnelARHopTable, and
      gmplsTunnelCHopTable) for providing additional configuration of
      strict and loose source routed tunnel hops.

   -  Performance and error reporting tables
      (gmplsTunnelReversePerfTable and gmplsTunnelErrorTable).

   These tables are described in the subsequent sections.

   Additionally, the GMPLS-TE-STD-MIB module contains a new
   notification.

   -  The GMPLS Tunnel Down Notification (gmplsTunnelDown) should be
      used for all GMPLS tunnels in place of the mplsTunnelDown
      notification defined in [RFC3812].  An implementation must not
      issue both the gmplsTunnelDown and the mplsTunnelDown
      notifications for the same event.  As well as indicating that a
      tunnel has transitioned to operational down state, this new
      notification indicates the cause of the failure.

5.  Brief Description of GMPLS TE MIB Objects

   The objects described in this section support the functionality
   described in [RFC3473] and [RFC3472] for GMPLS tunnels.  The tables
   support both manually configured and signaled tunnels.

5.1.  gmplsTunnelTable

   The gmplsTunnelTable extends the MPLS traffic engineering MIB module
   (MPLS-TE-STD-MIB [RFC3812]) to allow GMPLS tunnels to be created
   between an LSR and a remote endpoint, and existing GMPLS tunnels to
   be reconfigured or removed.

   Note that we only support point-to-point tunnel segments, although
   multipoint-to-point and point-to-multipoint connections are supported
   by an LSR acting as a cross-connect.

   Each tunnel can thus have one out-segment originating at an LSR
   and/or one in-segment terminating at that LSR.

   Three objects within this table utilize enumerations in order to map
   to enumerations that are used in GMPLS signaling.  In order to
   protect the GMPLS-TE-STD-MIB module from changes (in particular,
   extensions) to the range of enumerations supported by the signaling

   protocols, these MIB objects use textual conventions with values
   maintained by IANA.  For further details, see the IANA Considerations
   section of this document.

5.2.  gmplsTunnelHopTable

   The gmplsTunnelHopTable is used to indicate additional parameters for
   the hops, strict or loose, of a GMPLS tunnel defined in the
   gmplsTunnelTable, when it is established using signaling.  Multiple
   tunnels may share hops by pointing to the same entry in this table.

5.3.  gmplsTunnelARHopTable

   The gmplsTunnelARHopTable is used to indicate the actual hops
   traversed by a tunnel as reported by the signaling protocol after the
   tunnel is set up.  The support of this table is optional since not
   all GMPLS signaling protocols support this feature.

5.4.  gmplsTunnelCHopTable

   The gmplsTunnelCHopTable lists the actual hops computed by a
   constraint-based routing algorithm based on the gmplsTunnelHopTable.
   The support of this table is optional since not all implementations
   support computation of hop lists using a constraint-based routing
   protocol.

5.5.  gmplsTunnelErrorTable

   The gmplsTunnelErrorTable provides access to information about the
   last error that occurred on each tunnel known about by the MIB.  It
   indicates the nature of the error and when and how it was reported,
   and it can give recovery advice through an admin string.

5.6.  gmplsTunnelReversePerfTable

   The gmplsTunnelReversePerfTable provides additional counters to
   measure the performance of bidirectional GMPLS tunnels in which
   packets are visible.  It supplements the counters in
   mplsTunnelPerfTable and augments gmplsTunnelTable.

   Note that not all counters may be appropriate or available for some
   types of tunnel.

5.7.  Use of 32-bit and 64-bit Counters

   64-bit counters are provided in the GMPLS-TE-STD-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.

6.  Cross-referencing to the gmplsLabelTable

   The gmplsLabelTable is found in the GMPLS-LABEL-STD-MIB module in
   [RFC4803] and provides a way to model labels in a GMPLS system where
   labels might not be simple 32-bit integers.

   The hop tables in this document (gmplsTunnelHopTable,
   gmplsTunnelCHopTable, and gmplsTunnelARHopTable) and the segment
   tables in [RFC3813] (mplsInSegmentTable and mplsOutSegmentTable)
   contain objects with syntax MplsLabel.

   MplsLabel (defined in [RFC3811]) is a 32-bit integer that is capable
   of representing any MPLS Label and most GMPLS Labels.  However, some
   GMPLS Labels are larger than 32 bits and may be of arbitrary length.
   Furthermore, some labels that may be safely encoded in 32 bits are
   constructed from multiple sub-fields.  Additionally, some GMPLS
   technologies support the concatenation of individual labels to
   represent a data flow carried as multiple sub-flows.

   These GMPLS cases require that something other than a simple 32-bit
   integer be made available to represent the labels.  This is achieved
   through the gmplsLabelTable contained in the GMPLS-LABEL-STD-MIB
   [RFC4803].

   The tables in this document and [RFC3813] that include objects with
   syntax MplsLabel also include companion objects that are row
   pointers.  If the row pointer is set to zeroDotZero (0.0), then an
   object of syntax MplsLabel contains the label encoded as a 32-bit
   integer.  But otherwise the row pointer indicates a row in another
   MIB table that includes the label.  In these cases, the row pointer
   may indicate a row in the gmplsLabelTable.

   This provides both a good way to support legacy systems that
   implement MPLS-TE-STD-MIB [RFC3812], and a significant simplification
   in GMPLS systems that are limited to a single, simple label type.

   Note that gmplsLabelTable supports concatenated labels through the
   use of a label sub-index (gmplsLabelSubindex).

7.  Example of GMPLS Tunnel Setup

   This section contains an example of which MIB objects should be
   modified to create a GMPLS tunnel.  This example shows a best effort,
   loosely routed, bidirectional traffic engineered tunnel, which spans
   two hops of a simple network, uses Generalized Label requests with
   Lambda encoding, has label recording and shared link layer
   protection.  Note that these objects should be created on the "head-
   end" LSR.

   First in the mplsTunnelTable:
   {
     mplsTunnelIndex                = 1,
     mplsTunnelInstance             = 1,
     mplsTunnelIngressLSRId         = 192.0.2.1,
     mplsTunnelEgressLSRId          = 192.0.2.2,
     mplsTunnelName                 = "My first tunnel",
     mplsTunnelDescr                = "Here to there and back again",
     mplsTunnelIsIf                 = true(1),
     mplsTunnelXCPointer            = mplsXCIndex.3.0.0.12,
     mplsTunnelSignallingProto      = none(1),
     mplsTunnelSetupPrio            = 0,
     mplsTunnelHoldingPrio          = 0,
     mplsTunnelSessionAttributes    = recordRoute(4),
     mplsTunnelOwner                = snmp(2),
     mplsTunnelLocalProtectInUse    = false(2),
     mplsTunnelResourcePointer      = mplsTunnelResourceIndex.6,
     mplsTunnelInstancePriority     = 1,
     mplsTunnelHopTableIndex        = 1,
     mplsTunnelPrimaryInstance      = 0,
     mplsTunnelIncludeAnyAffinity   = 0,
     mplsTunnelIncludeAllAffinity   = 0,
     mplsTunnelExcludeAnyAffinity   = 0,
     mplsTunnelPathInUse            = 1,
     mplsTunnelRole                 = head(1),
     mplsTunnelRowStatus            = createAndWait(5),
   }

   In gmplsTunnelTable(1,1,192.0.2.1,192.0.2.2):
   {
     gmplsTunnelUnnumIf             = true(1),
     gmplsTunnelAttributes          = labelRecordingRequired(1),
     gmplsTunnelLSPEncoding         = tunnelLspLambda,
     gmplsTunnelSwitchingType       = lsc,
     gmplsTunnelLinkProtection      = shared(2),
     gmplsTunnelGPid                = lambda,
     gmplsTunnelSecondary           = false(2),
     gmplsTunnelDirection           = bidirectional(1)
     gmplsTunnelPathComp            = explicit(2),
     gmplsTunnelSendPathNotifyRecipientType = ipv4(1),
     gmplsTunnelSendPathNotifyRecipient     = 'C0000201'H,
     gmplsTunnelAdminStatusFlags    = 0,
     gmplsTunnelExtraParamsPtr      = 0.0
   }

   Entries in the mplsTunnelResourceTable, mplsTunnelHopTable, and
   gmplsTunnelHopTable are created and activated at this time.

   In mplsTunnelResourceTable:
   {
     mplsTunnelResourceIndex        = 6,
     mplsTunnelResourceMaxRate      = 0,
     mplsTunnelResourceMeanRate     = 0,
     mplsTunnelResourceMaxBurstSize = 0,
     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 network, or the first hop
   in our example.  We have used the fictitious LSR identified by
   "192.0.2.1" as our head-end router.

   In mplsTunnelHopTable:
   {
     mplsTunnelHopListIndex         = 1,
     mplsTunnelPathOptionIndex      = 1,
     mplsTunnelHopIndex             = 1,
     mplsTunnelHopAddrType          = ipv4(1),
     mplsTunnelHopIpv4Addr          = 192.0.2.1,
     mplsTunnelHopIpv4PrefixLen     = 9,
     mplsTunnelHopType              = strict(1),
     mplsTunnelHopRowStatus         = createAndWait(5),
   }

   The following denotes the end of the network, or the last hop in our
   example.  We have used the fictitious LSR identified by "192.0.2.2"
   as our tail-end router.

   In mplsTunnelHopTable:
   {
     mplsTunnelHopListIndex         = 1,
     mplsTunnelPathOptionIndex      = 1,
     mplsTunnelHopIndex             = 2,
     mplsTunnelHopAddrType          = ipv4(1),
     mplsTunnelHopIpv4Addr          = 192.0.2.2,
     mplsTunnelHopIpv4PrefixLen     = 9,
     mplsTunnelHopType              = loose(2),
     mplsTunnelHopRowStatus         = createAndGo(4)
   }

   Now an associated entry in the gmplsTunnelHopTable is created to
   provide additional GMPLS hop configuration indicating that the first
   hop is an unnumbered link using Explicit Forward and Reverse Labels.

   An entry in the gmplsLabelTable is created first to include the
   Explicit Label.

   In gmplsLabelTable:
   {
     gmplsLabelInterface            = 2,
     gmplsLabelIndex                = 1,
     gmplsLabelSubindex             = 0,
     gmplsLabelType                 = gmplsFreeformLabel(3),
     gmplsLabelFreeform             = 0xFEDCBA9876543210
     gmplsLabelRowStatus            = createAndGo(4)
   }

   In gmplsTunnelHopTable(1,1,1):
   {
     gmplsTunnelHopLabelStatuses           = forwardPresent(0)
                                                +reversePresent(1),
     gmplsTunnelHopExplicitForwardLabelPtr = gmplsLabelTable(2,1,0)
     gmplsTunnelHopExplicitReverseLabelPtr = gmplsLabelTable(2,1,0)
   }

   The first hop is now activated:

   In mplsTunnelHopTable(1,1,1):
   {
     mplsTunnelHopRowStatus         = active(1)
   }

   No gmplsTunnelHopEntry is created for the second hop as it contains
   no special GMPLS features.

   Finally, the mplsTunnelEntry is activated:

   In mplsTunnelTable(1,1,192.0.2.1,192.0.2.2)
   {
     mplsTunnelRowStatus            = active(1)
   }