Network Working Group                                           F. Baker
Request For Comments: 1850                                 Cisco Systems
Obsoletes: 1253                                                R. Coltun
Category: Standards Track                   RainbowBridge Communications
                                                           November 1995


               OSPF Version 2 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.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing the Open Shortest Path
   First Routing Protocol.




Table of Contents

   1. The SNMPv2 Network Management Framework ..............    2
   1.1 Object Definitions ..................................    3
   2. Overview .............................................    3
   2.1 Changes from RFC 1253 ...............................    3
   2.2 Textual Conventions .................................    6
   2.3 Structure of MIB ....................................    6
   2.3.1 General Variables .................................    6
   2.3.2 Area Data Structure and Area Stub Metric Table ....    7
   2.3.3 Link State Database and External Link State
         Database ..........................................    7
   2.3.4 Address Table and Host Tables .....................    7
   2.3.5 Interface and Interface Metric Tables .............    7
   2.3.6 Virtual Interface Table ...........................    7
   2.3.7 Neighbor and Virtual Neighbor Tables ..............    7
   2.4 Conceptual Row Creation .............................    7
   2.5 Default Configuration ...............................    8
   3. Definitions ..........................................   10
   3.1 OSPF General Variables ..............................   13
   3.2 OSPF Area Table .....................................   17

   3.3 OSPF Area Default Metrics ...........................   21
   3.4 OSPF Link State Database ............................   25
   3.5 OSPF Address Range Table ............................   27
   3.6 OSPF Host Table .....................................   29
   3.7 OSPF Interface Table ................................   32
   3.8 OSPF Interface Metrics ..............................   39
   3.9 OSPF Virtual Interface Table ........................   42
   3.10 OSPF Neighbor Table ................................   46
   3.11 OSPF Virtual Neighbor Table ........................   51
   3.12 OSPF External Link State Database ..................   54
   3.13 OSPF Route Table Use ...............................   57
   3.14 OSPF Area Aggregate Table ..........................   58
   4. OSPF Traps ...........................................   66
   4.1 Format Of Trap Definitions ..........................   67
   4.2 Approach ............................................   67
   4.3 Ignoring Initial Activity ...........................   67
   4.4 Throttling Traps ....................................   67
   4.5 One Trap Per OSPF Event .............................   68
   4.6 Polling Event Counters ..............................   68
   5. OSPF Trap Definitions ................................   69
   5.1 Trap Support Objects ................................   69
   5.2 Traps ...............................................   71
   6. Acknowledgements ......................................  78
   7. References ............................................  78
   8. Security Considerations ...............................  80
   9. Authors' Addresses ....................................  80

1.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework consists of four major
   components.  They are:

      o RFC 1441 which defines the SMI, the mechanisms used for
        describing and naming objects for the purpose of
        management.

      o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
        for the Internet suite of protocols.

      o RFC 1445 which defines the administrative and other
        architectural aspects of the framework.

      o RFC 1448 which defines the protocol used for network
        access to managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

1.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object object type is named
   by an OBJECT IDENTIFIER, an administratively assigned name.  The
   object type together with an object instance serves to uniquely
   identify a specific instantiation of the object.  For human
   convenience, we often use a textual string, termed the descriptor, to
   refer to the object type.

2.  Overview

2.1.  Changes from RFC 1253

   The changes from RFC 1253 are the following:

   (1)  The textual convention PositiveInteger was changed from
        1..'FFFFFFFF'h to 1..'7FFFFFFF'h at the request of
        Marshall Rose.

   (2)  The textual convention TOSType was changed to reflect the
        TOS values defined in the Router Requirements Draft, and
        in accordance with the IP Forwarding Table MIB's values.

   (3)  The names of some objects were changed, conforming to the
        convention that an acronym (for example, LSA) is a single
        word ("Lsa") in most SNMP names.

   (4)  textual changes were made to make the MIB readable by
        Dave Perkins' SMIC MIB Compiler in addition to Mosy.
        This involved changing the case of some characters in
        certain names and removing the DEFVAL clauses for
        Counters.

   (5)  The variables ospfAreaStatus and ospfIfStatus were added,
        having been overlooked in the original MIB.

   (6)  The range of the variable ospfLsdbType was extended to
        include multicastLink (Group-membership LSA) and
        nssaExternalLink (NSSA LSA).

   (7)  The variable ospfIfMetricMetric was renamed
        ospfIfMetricValue, and the following text was removed
        from its description:

        "The value FFFF is distinguished to mean 'no route via

        this TOS'."

   (8)  The variable ospfNbmaNbrPermanence was added, with the
        values 'dynamic' and 'permanent'; by this means,
        dynamically learned and configured neighbors can be
        distinguished.

   (9)  The DESCRIPTION of the variable ospfNbrIpAddr was changed
        from

        "The IP address of this neighbor."

        to

        "The IP address this neighbor is using in its IP Source
        Address.  Note that, on addressless links, this will not
        be 0.0.0.0, but the address of another of the neighbor's
        interfaces."

        This is by way of clarification and does not change the
        specification.

   (10) The OSPF External Link State Database was added.  The
        OSPF Link State Database used to display all LSAs stored;
        in this MIB, it displays all but the AS External LSAs.
        This is because there are usually a large number of
        External LSAs, and they are relicated in all non-Stub
        Areas.

   (11) The variable ospfAreaSummary was added to control the
        import of summary LSAs into stub areas.  If it is
        noAreaSummary (default) the router will neither originate
        nor propagate summary LSAs into the stub area.  It will
        rely entirely on its default route.  If it is
        sendAreaSummary, the router will both summarize and
        propagate summary LSAs.

   (12) The general variables ospfExtLsdbLimit and
        ExitOverflowInterval were introduced to help handle LSDB
        overflow.

   (13) The use of the IP Forwarding Table is defined.

   (14) The ospfAreaRangeTable was obsoleted and replaced with
        the ospfAreaAggregateTable to accommodate two additional
        indexes.  The ospfAreaAggregateEntry keys now include a
        LsdbType (which can be used to differentiate between the
        traditional type-3 Aggregates and NSSA Aggregates) and an

        ospfAreaAggregateMask (which will more clearly express
        the range).

   (15) The variable ospfAreaAggregateEffect was added.  This
        permits the network manager to hide a subnet within an
        area.

   (16) Normally, the border router of a stub area advertises a
        default route as an OSPF network summary.  An NSSA border
        router will generate a type-7 LSA indicating a default
        route, and import it into the NSSA.  ospfStubMetricType
        (ospf internal, type 1 external, or type 2 external)
        indicates the type of the default metric advertised.

   (17) ospfMulticastExtensions is added to the OSPF General
        Group.  This indicates the router's ability to forward IP
        multicast (Class D) datagrams.

   (18) ospfIfMulticastForwarding is added to the Interface
        Group.  It indicates whether, and if so, how, multicasts
        should be forwarded on the interface.

   (19) The MIB is converted to SNMP Version 2.  Beyond simple
        text changes and the addition of the MODULE-IDENTITY and
        MODULE-COMPLIANCE macros, this involved trading the
        TruthValue Textual Convention for SNMP Version 2's, which
        has the same values, and trading the Validation Textual
        Convention for SNMP Version 2's RowStatus.

   (20) ospfAuthType (area authentication type) was changed to an
        interface authentication type to match the key.  It also
        has an additional value, to indicate the use of MD5 for
        authentication.

   (21) ospfIfIntfType has a new value, pointToMultipoint.

   (22) ospfIfDemand (read/write) is added, to permit control of
        Demand OSPF features.

   (23) ospfNbrHelloSuppressed and ospfVirtNbrHelloSuppressed
        were added, (read only). They indicate whether Hellos are
        being suppressed to the neighbor.

   (24) ospfDemandExtensions was added to indicate whether the
        Demand OSPF extensions have been implemented, and to
        disable them if appropriate.

2.2.  Textual Conventions

   Several new data types are introduced as a textual convention in this
   MIB document.  These textual conventions enhance the readability of
   the specification and can ease comparison with other specifications
   if appropriate.  It should be noted that the introduction of the
   these textual conventions has no effect on either the syntax nor the
   semantics of any managed objects.  The use of these is merely an
   artifact of the explanatory method used.  Objects defined in terms of
   one of these methods are always encoded by means of the rules that
   define the primitive type.  Hence, no changes to the SMI or the SNMP
   are necessary to accommodate these textual conventions which are
   adopted merely for the convenience of readers and writers in pursuit
   of the elusive goal of clear, concise, and unambiguous MIB documents.

   The new data types are AreaID, RouterID, TOSType, Metric, BigMetric,
   Status, PositiveInteger, HelloRange, UpToMaxAge, InterfaceIndex, and
   DesignatedRouterPriority.

2.3.  Structure of MIB

   The MIB is composed of the following sections:

     General Variables
     Area Data Structure
     Area Stub Metric Table
     Link State Database
     Address Range Table
     Host Table
     Interface Table
     Interface Metric Table
     Virtual Interface Table
     Neighbor Table
     Virtual Neighbor Table
     External Link State Database
     Aggregate Range Table

   There exists a separate MIB for notifications ("traps"), which is
   entirely optional.

2.3.1.  General Variables

   The General Variables are about what they sound like; variables which
   are global to the OSPF Process.

2.3.2.  Area Data Structure and Area Stub Metric Table

   The Area Data Structure describes the OSPF Areas that the router
   participates in.  The Area Stub Metric Table describes the metrics
   advertised into a stub area by the default router(s).

2.3.3.  Link State Database and External Link State Database

   The Link State Database is provided primarily to provide detailed
   information for network debugging.

2.3.4.  Address Table and Host Tables

   The Address Range Table and Host Table are provided to view
   configured Network Summary and Host Route information.

2.3.5.  Interface and Interface Metric Tables

   The Interface Table and the Interface Metric Table together describe
   the various IP interfaces to OSPF.  The metrics are placed in
   separate tables in order to simplify dealing with multiple types of
   service, and to provide flexibility in the event that the IP TOS
   definition is changed in the future.  A Default Value specification
   is supplied for the TOS 0 (default) metric.

2.3.6.  Virtual Interface Table

   Likewise, the Virtual Interface Table describe virtual links to the
   OSPF Process.

2.3.7.  Neighbor and Virtual Neighbor Tables

   The Neighbor Table and the Virtual Neighbor Table describe the
   neighbors to the OSPF Process.

2.4.  Conceptual Row Creation

   For the benefit of row-creation in "conceptual" (see [9]) tables,
   DEFVAL (Default Value) clauses are included in the definitions in
   section 3, suggesting values which an agent should use for instances
   of variables which need to be created due to a Set-Request, but which
   are not specified in the Set-Request.  DEFVAL clauses have not been
   specified for some objects which are read-only, implying that they
   are zeroed upon row creation.  These objects are of the SYNTAX
   Counter32 or Gauge32.

   For those objects not having a DEFVAL clause, both management
   stations and agents should heed the Robustness Principle of the

   Internet (see RFC-791):

     "be liberal in what you accept, conservative in what you
     send"

   That is, management stations should include as many of these columnar
   objects as possible (e.g., all read-write objects) in a Set-Request
   when creating a conceptual row; agents should accept a Set-Request
   with as few of these as they need (e.g., the minimum contents of a
   row creating SET consists of those objects for which, as they cannot
   be intuited, no default is specified.).

   There are numerous read-write objects in this MIB, as it is designed
   for SNMP management of the protocol, not just SNMP monitoring of its
   state.  However, in the absence of a standard SNMP Security
   architecture, it is acceptable for implementations to implement these
   as read-only with an alternative interface for their modification.

2.5.  Default Configuration

   OSPF is a powerful routing protocol, equipped with features to handle
   virtually any configuration requirement that might reasonably be
   found within an Autonomous System.  With this power comes a fair
   degree of complexity, which the sheer number of objects in the MIB
   will attest to.  Care has therefore been taken, in constructing this
   MIB, to define default values for virtually every object, to minimize
   the amount of parameterization required in the typical case.  That
   default configuration is as follows:

   Given the following assumptions:

   -    IP has already been configured

   -    The ifTable has already been configured

   -    ifSpeed is estimated by the interface drivers

   -    The OSPF Process automatically discovers all IP
        Interfaces and creates corresponding OSPF Interfaces

   -    The TOS 0 metrics are autonomously derived from ifSpeed

   -    The OSPF Process automatically creates the Areas required
        for the Interfaces

   The simplest configuration of an OSPF process requires that:

   -    The OSPF Process be Enabled.

   This can be accomplished with a single SET:

                  ospfAdminStat := enabled.

   The configured system will have the following attributes:

   -    The RouterID will be one of the IP addresses of the
        device

   -    The device will be neither an Area Border Router nor an
        Autonomous System Border Router.

   -    Every IP Interface, with or without an address, will be
        an OSPF Interface.

   -    The AreaID of each interface will be 0.0.0.0, the
        Backbone.

   -    Authentication will be disabled

   -    All Broadcast and Point to Point interfaces will be
        operational.  NBMA Interfaces require the configuration
        of at least one neighbor.

   -    Timers on all direct interfaces will be:

          Hello Interval:        10 seconds
          Dead Timeout:          40 Seconds
          Retransmission:         5 Seconds
          Transit Delay:          1 Second
          Poll Interval:        120 Seconds

   -    no direct links to hosts will be configured.

   -    no addresses will be summarized

   -    Metrics, being a measure of bit duration, are unambiguous
        and intelligent.

   -    No Virtual Links will be configured.