Network Working Group                                           M. Dubuc
Request for Comments: 4631                                     T. Nadeau
Obsoletes: 4327                                            Cisco Systems
Category: Standards Track                                        J. Lang
                                                             Sonos, Inc.
                                                             E. McGinnis
                                                      Hammerhead Systems
                                                               A. Farrel
                                                      Old Dog Consulting
                                                          September 2006


    Link Management Protocol (LMP) 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 (2006).

Abstract

   This document provides minor corrections to and obsoletes RFC 4327.

   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 the Link
   Management Protocol (LMP).

Table of Contents

   1. The Internet-Standard Management Framework ......................3
   2. Introduction ....................................................3
   3. Terminology .....................................................3
   4. Feature Checklist ...............................................4
   5. Outline .........................................................4
   6. Brief Description of MIB Objects ................................5
      6.1. lmpNbrTable ................................................5
      6.2. lmpControlChannelTable .....................................5
      6.3. lmpControlChannelPerfTable .................................5
      6.4. lmpTeLinkTable .............................................5
      6.5. lmpLinkVerificationTable ...................................5
      6.6. lmpTeLinkPerfTable .........................................6
      6.7. lmpDataLinkTable ...........................................6
      6.8. lmpDataLinkPerfTable .......................................6
   7. Example of LMP Control Channel Setup ............................6
   8. Application of the Interfaces Group to LMP ......................9
      8.1. Support of the LMP Layer by ifTable .......................10
   9. LMP MIB Module Definitions .....................................11
   10. Security Considerations .......................................78
   11. Contributors ..................................................79
   12. Acknowledgements ..............................................79
   13. IANA Considerations ...........................................79
      13.1. IANA Considerations for LMP ifType .......................79
      13.2. IANA Considerations for LMP-MIB ..........................79
   14. Changes from RFC 4327 to RFC 4631 .............................79
   15. References ....................................................80
      15.1. Normative References .....................................80
      15.2. Informative References ...................................81

1.  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].

2.  Introduction

   Current work is under way in the IETF to specify a suite of protocols
   to be used as a common control plane and a separate common
   measurement plane.  Generalized MPLS (GMPLS) [RFC3471] and the Link
   Management Protocol [RFC4204] are key components of this
   standardization activity.  The primary purpose of LMP is to manage
   traffic engineering (TE) links.  Primary goals of LMP are the
   maintenance of the control channel connectivity, correlation of link
   properties, verification of data-bearing links, and detection and
   isolation of link faults.

   We describe in this document a MIB module that can be used to manage
   LMP implementations.  This MIB module covers both configuration and
   performance-monitoring aspects of LMP.

   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 RFC 2119 [RFC2119].

3.  Terminology

   This document uses terminology from the document describing the Link
   Management Protocol [RFC4204].  An "LMP adjacency" is formed between
   two nodes that support the same capabilities, and LMP messages are
   exchanged between the node pair over control channels that form this
   adjacency.  Several control channels can be active at the same time.
   With the exception of messages related to control channel management,
   anytime an LMP message needs to be transferred to a neighbor node, it
   can be sent on any of the active control channels.  The control
   channels can also be used to exchange MPLS control plane information
   or routing information.

   LMP is designed to support aggregation of one or more data-bearing
   links into a traffic-engineering (TE) link.  The data-bearing links
   can be either component links or ports, depending on their
   multiplexing capability (see [RFC4204] for the distinction between
   port and component link).

   Each TE link is associated with an LMP adjacency, and one or more
   control channels are used to exchange LMP messages for a particular
   adjacency.  In turn, control channels are used to manage the TE links
   associated with the LMP adjacency.

4.  Feature Checklist

   The Link Management Protocol MIB module (LMP-MIB) is designed to
   satisfy the following requirements and constraints:

   -  The MIB module supports the enabling and disabling of LMP
      capability on LMP-capable interfaces of a photonic switch, optical
      cross-connect, or router.

   -  The MIB module is used to provide information about LMP
      adjacencies.

   -  Support is provided for configuration of the keep-alive and link
      verification parameters.

   -  The MIB module is used to express the mapping between local and
      remote TE links, as well as local and remote interface identifiers
      for port or component link.

   -  Performance counters are provided for measuring LMP performance on
      a per-control channel basis.  Performance counters are also
      provided for measuring LMP performance on the data-bearing links.

   Note that the LMP MIB module goes hand-in-hand with the TE Link (TE-
   LINK-STD-MIB) MIB module [RFC4220].  The TE link table, which is used
   to associate data-bearing links to TE links, is defined in the TE
   Link MIB.  The TE link table in the LMP MIB module contains TE link
   information specific to LMP.

5.  Outline

   Configuring LMP through an optical device involves the following
   steps:

   -  Enabling LMP on LMP-capable interfaces through control channel
      configuration.

   -  Optionally, specifying link verification parameters.

   -  Configuring the data-bearing links and associating them to the
      appropriate TE link (this association is stored in the
      ifStackTable of the Interfaces Group MIB).

   TE links are managed by the control channels that run between the
   same pair of nodes (LMP adjacency).

6.  Brief Description of MIB Objects

   Sections 6.1 - 6.8 describe objects pertaining to LMP.  The MIB
   objects were derived from the LMP document [RFC4204].

6.1.  lmpNbrTable

   The remote node table is used to identify the pair of nodes that
   exchange LMP messages over control channels.

6.2.  lmpControlChannelTable

   The control channel table is used for enabling the LMP protocol on
   LMP-capable interfaces.  A photonic switch, optical cross-connect, or
   router creates an entry in this table for every LMP-capable interface
   in that device.

6.3.  lmpControlChannelPerfTable

   The control channel performance table is used for collecting LMP
   performance counts on a per-control channel basis.  Each entry in the
   lmpControlChannelTable has a corresponding entry in the
   lmpControlChannelPerfTable.

6.4.  lmpTeLinkTable

   The TE link table is used for specifying LMP information associated
   with TE links.

6.5.  lmpLinkVerificationTable

   The link verification table is used for configuring the LMP link
   verification parameters of TE links.  For every TE link entry in the
   lmpTeLinkTable that supports the link verification procedure, there
   is a corresponding entry in the lmpLinkVerificationTable.

6.6.  lmpTeLinkPerfTable

   The TE link performance table is used for collecting LMP performance
   counts on a per-TE link basis.  Each entry in the lmpTeLinkTable has
   a corresponding entry in the lmpTeLinkPerfTable.

6.7.  lmpDataLinkTable

   The data-bearing link table is used to specify the data-bearing links
   that are associated with TE links.

6.8.  lmpDataLinkPerfTable

   The data-bearing link performance table is used for collecting LMP
   performance counts on data-bearing links.

7.  Example of LMP Control Channel Setup

   In this section, we provide a brief example of using the MIB objects
   described in Section 9 to set up an LMP control channel.  This
   example is not meant to illustrate every nuance of the MIB module,
   but it is intended as an aid to understanding some of the key
   concepts.  It is meant to be read after one goes through the MIB
   itself.

   Suppose that one would like to form an LMP adjacency between two
   nodes using two control channels.  Suppose also that there are three
   data-bearing links.  We also assume that the data-bearing links are
   ports (lambdas) and that the link verification procedure is not
   enabled.  The following example illustrates which rows and
   corresponding objects might be created to accomplish this.

   First, LMP must be enabled between the pair of nodes.

   In lmpNbrTable:
   {
      lmpNbrNodeId                       = 'c0000201'H, -- 192.0.2.1
      lmpNbrAdminStatus                  = up(1),
      lmpNbrRowStatus                    = createAndGo(4),
      lmpNbrStorageType                  = nonVolatile(3)
   }

   Then, the control channels must be set up.  These are created in
   the lmpControlChannelTable.

   In lmpControlChannelTable:
   {
      lmpCcId                           = 1,

      lmpCcUnderlyingIfIndex            = 1,
      lmpCcIsIf                         = false(2),
      lmpCcAuthentication               = false(2),
      lmpCcHelloInterval                = 15,
      lmpCcHelloIntervalMin             = 15,
      lmpCcHelloIntervalMax             = 1000,
      lmpCcHelloDeadInterval            = 45,
      lmpCcHelloDeadIntervalMin         = 45,
      lmpCcHelloDeadIntervalMax         = 1000,
      lmpCcAdminStatus                  = up(1),
      lmpCcRowStatus                    = createAndGo(4),
      lmpCcStorageType                  = nonVolatile(3)
   }

   {
      lmpCcId                           = 2,
      lmpCcUnderlyingIfIndex            = 2,
      lmpCcIsIf                         = false(2),
      lmpCcAuthentication               = false(2),
      lmpCcHelloInterval                = 15,
      lmpCcHelloIntervalMin             = 15,
      lmpCcHelloIntervalMax             = 1000,
      lmpCcHelloDeadInterval            = 45,
      lmpCcHelloDeadIntervalMin         = 45,
      lmpCcHelloDeadIntervalMax         = 1000,
      lmpCcAdminStatus                  = up(1),
      lmpCcRowStatus                    = createAndGo(4),
      lmpCcStorageType                  = nonVolatile(3)
   }

   Next, the three data-bearing links are created.  For each data-
   bearing link, an ifEntry with the same ifIndex needs to be created
   beforehand.

      In lmpDataLinkTable:
   {
      ifIndex                         = 41,
      lmpDataLinkAddressType          = unknown(0),
      lmpDataLinkIpAddr               = ''H,
      lmpDataLinkRemoteIpAddress      = ''H,
      lmpDataLinkRemoteIfId           = 47,
      lmpDataLinkRowStatus            = createAndGo(4),
      lmpDataLinkStorageType          = nonVolatile(3)
   }

   {
      ifIndex                         = 43,
      lmpDataLinkAddressType          = unknown(0),

      lmpDataLinkIpAddr               = ''H,
      lmpDataLinkRemoteIpAddress      = ''H,
      lmpDataLinkRemoteIfId           = 42,
      lmpDataLinkRowStatus            = createAndGo(4),
      lmpDataLinkStorageType          = nonVolatile(3)
   }
   {
      ifIndex                         = 44,
      lmpDataLinkAddressType          = unknown(0),
      lmpDataLinkIpAddr               = ''H,
      lmpDataLinkRemoteIpAddress      = ''H,
      lmpDataLinkRemoteIfId           = 48,
      lmpDataLinkRowStatus            = createAndGo(4),
      lmpDataLinkStorageType          = nonVolatile(3)
   }

   Note that the data-bearing link type (lmpDataLinkType) does not need
   to be provisioned, as it is automatically populated by the node.  The
   definition of the protection role (primary or secondary) for the
   data-bearing links is stored in the componentLinkTable of the TE Link
   MIB module [RFC4220].

   Then, a TE link is created as an ifEntry with ifType teLink in the
   ifTable.

   Once the TE link is created in the ifTable, a TE link entry is
   created in the LMP MIB module to specify TE link information specific
   to LMP.

      In lmpTeLinkTable:
   {
      ifIndex                     = 20,
      lmpTeLinkVerification       = true(1),
      lmpTeLinkFaultManagement    = true(1),
      lmpTeLinkDwdm               = false(2),
      lmpTeLinkRowStatus          = createAndGo(4),
      lmpTeLinkStorageType        = nonVolatile(3)
   }

   and in lmpLinkVerificationTable:
   {
      ifIndex                         = 20,
      lmpLinkVerifyInterval           = 100,
      lmpLinkVerifyDeadInterval       = 300,
      lmpLinkVerifyTransportMechanism = j0Trace(3),
      lmpLinkVerifyAllLinks           = true(1),
      lmpLinkVerifyTransmissionRate   = 100000,
      lmpLinkVerifyWavelength         = 0,

      lmpLinkVerifyRowStatus          = createAndGo(4),
      lmpLinkVerifyStorageType        = nonVolatile(3)
   }

   The association between the data-bearing links and the TE links is
   stored in the ifStackTable [RFC2863].

   In parallel with the entry created in the lmpTeLinkTable, an entry
   may be created in the teLinkTable of the TE Link MIB module
   [RFC4220].

8.  Application of the Interfaces Group to LMP

   The Interfaces Group [RFC2863] defines generic managed objects for
   managing interfaces.  This memo contains the media-specific
   extensions to the Interfaces Group for managing LMP control channels
   that are modeled as interfaces.  If the control channel as defined in
   the lmpControlChannelTable is modeled as an ifEntry, then the
   following definition applies.  An lmpControlChannelTable entry is
   designated as being represented as an Interfaces MIB ifEntry if the
   lmpControlChannelEntry object lmpCcIsIf is set to true (1).  In this
   case, the control channel SHOULD be modeled as an ifEntry and provide
   appropriate interface stacking, as defined below.

   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.  Since the LMP interface only
   carries control traffic, it is considered to be below the
   internetwork layer.  Thus, the LMP interface may be represented as an
   entry in the ifTable.  The interrelation of entries in the ifTable is
   defined by Interfaces Stack Group defined in [RFC2863].

   When LMP control channels are modeled as interfaces, the interface
   stack table must appear as follows for the LMP control channel
   interfaces:

      +----------------------------------------+
      | LMP-interface ifType = lmp(227)        +
      +----------------------------------------+
      | Underlying Layer...                    +
      +----------------------------------------+

   In the above diagram, "Underlying Layer..." refers to the ifIndex of
   any interface type over which the LMP interface will transmit its
   traffic.  Note that if the underlying layer provides multiple access

   to its media (i.e., Ethernet), then it is possible to stack multiple
   LMP interfaces on top of this interface in parallel.

   Note that it is not a requirement that LMP control channels be
   modeled as interfaces.  It is acceptable that control channels simply
   exist as logical connections between adjacent LMP-capable nodes.  In
   this case, lmpCcIsIf is set to false(2), and no corresponding entry
   is made in the ifTable.

8.1.  Support of the LMP Layer by ifTable

   Some specific interpretations of ifTable for the LMP layer follow.

   Object        Use for the LMP layer.

   ifIndex       Each LMP interface may be represented by an ifEntry.

   ifDescr       Description of the LMP interface.

   ifType        The value that is allocated for LMP is 227.  This
                 number has been assigned by the IANA.

   ifSpeed       The total bandwidth in bits per second for use by the
                 LMP layer.

   ifPhysAddress Unused.

   ifAdminStatus This variable indicates the administrator's intent as
                 to whether LMP should be enabled, disabled, or running
                 in some diagnostic testing mode on this interface.
                 Also see [RFC2863].

   ifOperStatus  This value reflects the actual or operational status of
                 LMP on this interface.

   ifLastChange  See [RFC2863].

   ifInOctets    The number of received octets over the interface; i.e.,
                 the number of octets received as LMP packets.

   ifOutOctets   The number of transmitted octets over the interface;
                 i.e., the number of octets transmitted as LMP packets.

   ifInErrors    The number of LMP 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 interface
                 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 nonvolatile 'alias' name for the interface, as
                 specified by a network manager.

   ifCounterDiscontinuityTime
                 See [RFC2863].