Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4802

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

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

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

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

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.
Top   ToC   RFC4802 - Page 4
   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].
Top   ToC   RFC4802 - Page 5
   -  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
Top   ToC   RFC4802 - Page 6
   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.
Top   ToC   RFC4802 - Page 7

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.
Top   ToC   RFC4802 - Page 8
   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), }
Top   ToC   RFC4802 - Page 9
   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),
   }
Top   ToC   RFC4802 - Page 10
   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)
   }
Top   ToC   RFC4802 - Page 11
   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)
   }



(page 11 continued on part 2)

Next Section