tech-invite   World Map     

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

RFC 4750

 Errata 
Proposed STD
Pages: 121
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: OSPF

OSPF Version 2 Management Information Base

Part 1 of 5, p. 1 to 7
None       Next RFC Part

Obsoletes:    1850


Top       ToC       Page 1 
Network Working Group                                      D. Joyal, Ed.
Request for Comments: 4750                                        Nortel
Obsoletes: 1850                                          P. Galecki, Ed.
Category: Standards Track                                        Airvana
                                                       S. Giacalone, Ed.
                                                                    CSFB
                                                    Original Authors:
                                                               R. Coltun
                                                          Touch Acoustra
                                                                F. Baker
                                                           Cisco Systems
                                                           December 2006


              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.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

 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 version 2 of the Open
   Shortest Path First Routing Protocol.  Version 2 of the OSPF protocol
   is specific to the IPv4 address family.  Version 3 of the OSPF
   protocol is specific to the IPv6 address family.

   This memo obsoletes RFC 1850; however, it is designed to be backwards
   compatible.  The functional differences between this memo and RFC
   1850 are explained in Appendix B.

Top       Page 2 
Table of Contents

   1. Overview ........................................................3
      1.1. The Internet-Standard Management Framework .................3
      1.2. Conceptual Row Creation ....................................3
      1.3. Default Configuration ......................................4
      1.4. OSPF Counters ..............................................5
      1.5. Multiple OSPF Instances ....................................5
      1.6. Conventions ................................................6
   2. Structure of This MIB ...........................................6
      2.1. The Purposes of the Sections in This MIB ...................6
           2.1.1. General Variables ...................................6
           2.1.2. Area Data Structure and Area Stub Metric Table ......6
           2.1.3. Link State Database and External Link State
                  Database ............................................7
           2.1.4. Address Table and Host Tables .......................7
           2.1.5. Interface and Interface Metric Tables ...............7
           2.1.6. Virtual Interface Table .............................7
           2.1.7. Neighbor and Virtual Neighbor Tables ................7
           2.1.8. Local Link State Database Table and Virtual
                  Local Link State Database Table .....................7
           2.1.9. AS-scope Link State Database Table ..................7
           2.1.10. Area LSA Count Table ...............................7
   3. OSPF MIB Module .................................................8
   4. OSPF Trap Overview .............................................94
      4.1. Introduction ..............................................94
      4.2. Approach ..................................................95
      4.3. Ignoring Initial Activity .................................95
      4.4. Throttling Traps ..........................................95
      4.5. One Trap Per OSPF Event ...................................96
      4.6. Polling Event Counters ....................................96
      4.7. Translating Notification Parameters .......................97
      4.8. Historical Artifacts ......................................97
   5. OSPF Trap Definitions ..........................................98
   6. Security Considerations .......................................110
   7. IANA Considerations ...........................................111
   8. Acknowledgements ..............................................111
   9. References ....................................................111
      9.1. Normative References .....................................111
      9.2. Informative References ...................................111
   Appendix A. TOS Support ..........................................113
   Appendix B. Changes from RFC 1850 ................................113
      B.1. General Group Changes ....................................113
      B.2. OSPF NSSA Enhancement Support ............................113
      B.3. Opaque LSA Support .......................................114
      B.4. Graceful Restart Support .................................116
      B.5. OSPF Compliances .........................................116
      B.6. OSPF Authentication and Security .........................117

Top      ToC       Page 3 
      B.7. OSPF Trap MIB ............................................117
      B.8. Miscellaneous ............................................118

1.  Overview

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

1.2.  Conceptual Row Creation

   For the benefit of row-creation in "conceptual" tables, DEFVAL
   (Default Value) clauses are included in the definitions in section 3,
   suggesting values that an agent should use for instances of variables
   that need to be created due to a Set-Request, but that are not
   specified in the Set-Request.  DEFVAL clauses have not been specified
   for some objects that 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 [RFC791]):

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

   Therefore, 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 columnar objects 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).

Top      ToC       Page 4 
1.3.  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 (AS).  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 OSPF process automatically creates the areas required for the
     interfaces.

   The simplest configuration of an OSPF process requires the following:

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

Top      ToC       Page 5 
   - All broadcast and point-to-point interfaces will be operational.
     Non-broadcast multi-access (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.

1.4.  OSPF Counters

   This MIB defines several counters, namely:

   - ospfOriginateNewLsas, ospfRxNewLsas in the ospfGeneralGroup
   - ospfSpfRuns, ospfAreaNssaTranslatorEvents in the ospfAreaTable
   - ospfIfEvents in the ospfIfTable
   - ospfVirtIfEvents in the ospfVirtIfTable
   - ospfNbrEvents in the ospfNbrTable
   - ospfVirtNbrEvents in the ospfVirtNbrTable

   As a best practice, a management entity, when reading these counters,
   should use the discontinuity object, ospfDiscontinuityTime, to
   determine if an event that would invalidate the management entity
   understanding of the counters has occurred.  A restart of the OSPF
   routing process is a possible example of a discontinuity event.

1.5.  Multiple OSPF Instances

   SNMPv3 supports "Contexts" that can be used to implement MIB views on
   multiple OSPF instances on the same system.  See [RFC3411] or its
   successors for details.

Top      ToC       Page 6 
1.6.  Conventions

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

2.  Structure of This MIB

   This MIB is composed of the following sections:

      General Variables
      Area Data Structure
      Area Stub Metric Table
      Link State Database (LSDB)
      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
      Local Link State Database
      AS-scope Link State Database

   It supports the base OSPFv2 specification [RFC2328] and extensions to
   OSPFv2 such as [RFC1765], [RFC1793], [RFC2370], [RFC3101] and
   [RFC3623].

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

2.1.  The Purposes of the Sections in This MIB

2.1.1.  General Variables

   The general variables describe (as it may seem from the name)
   variables that are global to the OSPF Process.

2.1.2.  Area Data Structure and Area Stub Metric Table

   The Area Data Structure describes all of the OSPF Areas that the
   router participates in.  The Area Table includes data for Not-So-
   Stubby-Area (NSSA) translation.

   The Area Stub Metric Table describes the metrics advertised into a
   stub area by the default router(s).

Top      ToC       Page 7 
2.1.3.  Link State Database and External Link State Database

   The link state database is provided primarily to provide detailed
   information for network debugging.

2.1.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.1.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.  The Interface table includes link-local (Opaque type-9)
   link state advertisement (LSA) statistics.

2.1.6.  Virtual Interface Table

   The Virtual Interface Table describes virtual links to the OSPF
   Process, similarly to the (non-virtual) Interface Tables.  This Table
   includes link-local (Opaque type-9) LSA statistics.

2.1.7.  Neighbor and Virtual Neighbor Tables

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

2.1.8.  Local Link State Database Table and Virtual Local Link State
        Database Table

   The Local Link State Database Table and Virtual Local Link State
   Database Table are identical to the OSPF LSDB Table in format, but
   contain only link-local (Opaque type-9) link state advertisements for
   non-virtual and virtual links.

2.1.9.  AS-scope Link State Database Table

   The AS-scope Link State Database Table is identical to the OSPF LSDB
   Table in format, but contains only AS-scoped link state
   advertisements.

2.1.10.  Area LSA Count Table

   The table, which maintains number of link state advertisements on the
   per-area, per-LSA-type basis.


Next RFC Part