Network Working Group                                      D. Joyal, Ed.
Request for Comments: 5643                                        Nortel
Category: Standards Track                                 V. Manral, Ed.
                                                             IP Infusion
                                                             August 2009


                Management Information Base for OSPFv3

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in IPv6-based internets.
   In particular, it defines objects for managing the Open Shortest Path
   First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF
   version 3 (OSPFv3).

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) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. The Internet-Standard Management Framework ......................3
   2. Overview ........................................................3
      2.1. IPv6 Interfaces ............................................3
      2.2. Addressing Semantics .......................................4
      2.3. Authentication .............................................4
      2.4. Type of Service ............................................4
      2.5. Flooding Scope .............................................4
      2.6. Virtual Links ..............................................4
      2.7. Neighbors ..................................................5
      2.8. OSPFv3 Counters ............................................5
      2.9. Multiple OSPFv3 Instances ..................................5
      2.10. Notifications .............................................5
      2.11. Conventions ...............................................6
   3. OSPFv3 Notification Overview ....................................6
      3.1. Introduction ...............................................6
      3.2. Ignoring Initial Activity ..................................6
      3.3. Throttling Notifications ...................................6
      3.4. One Notification per OSPFv3 Event ..........................7
      3.5. Polling Event Counters .....................................7
   4. Structure of the OSPFv3 MIB Module ..............................7
      4.1. General Variables ..........................................8
      4.2. Area Table .................................................8
      4.3. Area-Scope, Link-Scope, and AS-Scope Link State Database ...8
      4.4. Host Table .................................................8
      4.5. Interface Table ............................................8
      4.6. Virtual Interface Table ....................................8
      4.7. Neighbor, Configured Neighbor, and Virtual Neighbor
           Tables .....................................................8
      4.8. Area Aggregate Table .......................................8
      4.9. Notifications ..............................................9
   5. Definitions .....................................................9
   6. Security Considerations ........................................92
   7. IANA Considerations ............................................93
   8. Acknowledgements ...............................................93
   9. References .....................................................93
      9.1. Normative References ......................................93
      9.2. Informative References ....................................94

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

   This memo defines a portion of the Management Information Base (MIB)
   for managing the Open Shortest Path First Routing Protocol for IPv6
   [RFC5340], otherwise known as OSPF version 3 (OSPFv3).  Though the
   fundamental mechanisms of OSPF version 2 (OSPFv2) [RFC2328] remain
   unchanged in OSPFv3, some changes were necessary due to differences
   in IP address size and in protocol semantics between IPv4 and IPv6.
   In many cases, where the protocol operations have not changed from
   OSPFv2, the specification for OSPFv3 does not restate the details but
   instead refers to the relevant sections in the OSPFv2 specification.
   This MIB module follows along the same lines and includes Reference
   clauses referring to the OSPFv2 specification when applicable.


2.1.  IPv6 Interfaces

   IPv6 interfaces attach to links [RFC2460].  A link is roughly defined
   as the layer below IPv6 (e.g., Ethernet, IPv4 Tunnel).  One or more
   IPv6 prefixes can be associated with an IPv6 interface.  IPv6
   interfaces and the prefixes associated with those interfaces can be
   configured via the IP-MIB [RFC4293].  IPv6 interfaces are configured
   in the IPv6 Interface Table and IPv6 prefixes are configured in the
   Internet Address Prefix Table.  An IPv6 interface is identified by a
   unique index value.  IPv6 Address Prefix Table entries associated
   with an IPv6 interface reference the interface's index.

   Whereas an Interface Identifier in OSPFv2 is a local IPv4 address or
   MIB-2 interface index, an OSPFv3 Interface Identifier is an IPv6
   interface index.  For example, the index value of an OSPFv3 Interface
   Table entry is the IPv6 interface index of the IPv6 interface over
   which OSPFv3 is configured to operate.

2.2.  Addressing Semantics

   Router ID, Area ID, and Link State ID remain at the OSPFv2 size of 32
   bits.  To ensure uniqueness, a router running both IPv4 and IPv6
   concurrently can continue to use a local IPv4 host address,
   represented as an unsigned 32-bit value, as the OSPFv3 Router ID.
   Otherwise, the Router ID must be selected using another method (e.g.,
   administratively assigned).

   Router ID, Area ID, and Link State ID do not have addressing
   semantics in OSPFv3, so their syntax is changed to Unsigned32.  The
   Router ID index component comes before the Link State ID index
   component in the OSPFv3 MIB module because the lack of addressing
   semantics in Link State IDs makes them less unique identifiers than
   the Router ID.  It is more useful to do partial Object Identifier
   (OID) lookups extending to the Router ID rather than the Link State
   ID.

2.3.  Authentication

   In OSPFv3, authentication has been removed from the protocol itself.
   MIB objects related to authentication are not carried forward from
   the OSPFv2 MIB module.

2.4.  Type of Service

   OSPFv2 MIB module objects related to Type of Service (ToS) are not
   carried forward to the OSPFv3 MIB module.

2.5.  Flooding Scope

   Flooding scope for link state advertisements (LSAs) has been
   generalized and is now explicitly encoded in the LSA's LS type field.
   The action to take upon receipt of unknown LSA types is also encoded
   in the LS type field [RFC5340].  The OSPFv3 MIB module defines three
   Link State Database tables, one each for Area-scope LSAs, Link-scope
   LSAs, and Autonomous System (AS)-scope LSAs.

2.6.  Virtual Links

   Since addressing semantics have been removed from router-LSAs in
   OSPFv3, virtual links now need to be assigned an Interface ID for
   advertisement in Hello packets and in router-LSAs.  A read-only
   object has been added to the Virtual Interface Table entry to view
   the assigned Interface ID.

2.7.  Neighbors

   The OSPFv3 Neighbor Table is a read-only table that contains
   information learned from Hellos received from neighbors, including
   configured neighbors.  The OSPFv3 Configured Neighbor Table contains
   entries for manually configured neighbors for use on non-broadcast
   multi-access (NBMA) and Point-to-Multipoint interface types.

2.8.  OSPFv3 Counters

   This MIB module defines several counters, namely:

      - ospfv3OriginateNewLsas and ospfv3RxNewLsas in the
        ospfv3GeneralGroup

      - ospfv3AreaSpfRuns and ospfv3AreaNssaTranslatorEvents in the
        ospfv3AreaTable

      - ospfv3IfEvents in the ospfv3IfTable

      - ospfv3VirtIfEvents in the ospfv3VirtIfTable

      - ospfv3NbrEvents in the ospfv3NbrTable

      - ospfv3VirtNbrEvents in the ospfv3VirtNbrTable

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

2.9.  Multiple OSPFv3 Instances

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

2.10.  Notifications

   Notifications define a set of notifications, objects, and mechanisms
   to enhance the ability to manage IP internetworks that use OSPFv3 as
   their Interior Gateway Protocol (IGP).

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

3.  OSPFv3 Notification Overview

3.1.  Introduction

   OSPFv3 is an event-driven routing protocol, where an event can be a
   change in an OSPFv3 interface's link-level status, the expiration of
   an OSPFv3 timer, or the reception of an OSPFv3 protocol packet.  Many
   of the actions that OSPFv3 takes as a result of these events will
   result in a change of the routing topology.

   As routing topologies become large and complex, it is often difficult
   to locate the source of a topology change or unpredicted routing path
   by polling a large number or routers.  Because of the difficulty of
   polling a large number of devices, a more prudent approach is for
   devices to notify a network manager of potentially critical OSPF
   events using SNMP notifications.

   The ospfv3NotificationEnable object provides a coarse level of
   control over the generation of OSPFv3 notifications.  It can be used
   to completely enable or disable generation of OSPFv3 notifications.
   Fine-grain control of individual notifications can be accomplished by
   utilizing the objects defined in RFC 3413 [RFC3413], specifically
   those described in Section 6.

3.2.  Ignoring Initial Activity

   The majority of critical events occur when OSPFv3 is enabled on a
   router, at which time the Designated Router is elected and neighbor
   adjacencies are formed.  During this initial period, a potential
   flood of notifications is unnecessary since the events are expected.
   To avoid unnecessary notifications, a router should not originate
   expected OSPFv3 interface-related notifications until two of that
   interface's dead timer intervals have elapsed.  The expected OSPFv3
   interface notifications are ospfv3IfStateChange,
   ospfv3VirtIfStateChange, ospfv3NbrStateChange, and
   ospfv3VirtNbrStateChange.

3.3.  Throttling Notifications

   The mechanism for throttling the notifications is similar to the
   mechanism explained in RFC 1224 [RFC1224].  The basic premise of the
   throttling mechanism is that of a sliding window, defined in seconds

   and with an upper bound on the number of notifications that may be
   generated within this window.  Note that unlike RFC 1224,
   notifications are not sent to inform the network manager that the
   throttling mechanism has kicked in.

   A single window should be used to throttle all OSPFv3 notifications
   types except for the ospfv3LsdbOverflow and the
   ospfv3LsdbApproachingOverflow notifications, which should not be
   throttled.  For example, with a window time of 3, an upper bound of
   3, and events to cause notifications 1, 2, 3, and 4 (4 notifications
   within a 3-second period), the 4th notification should not be
   generated.

   Appropriate values are 7 notifications with a window time of 10
   seconds.

3.4.  One Notification per OSPFv3 Event

   Several of the notifications defined in this MIB module are generated
   as the result of finding an unusual condition while parsing an OSPFv3
   packet or processing a timer event.  There may be more than one
   unusual condition detected while handling the event.  For example, a
   Link State Update packet may contain several retransmitted link state
   advertisements (LSAs), or a retransmitted database description packet
   may contain several database description entries.  To limit the
   number of notifications and variables, OSPFv3 should generate at most
   one notification per OSPFv3 event.  Only the variables associated
   with the first unusual condition should be included with the
   notification.  Similarly, if more than one type of unusual condition
   is encountered while parsing the packet, only the first event will
   generate a notification.

3.5.  Polling Event Counters

   Many of the tables in the OSPFv3 MIB module contain generalized event
   counters.  By enabling the notifications defined in this document, a
   network manager can obtain more specific information about these
   events.  A network manager may want to poll these event counters and
   enable OSPFv3 notifications when a particular counter starts
   increasing abnormally.

4.  Structure of the OSPFv3 MIB Module

   The MIB is composed of the following sections:

        General Variables
        Area Table
        Area-Scope Link State Database

        Link-Scope Link State Databases (non-virtual and virtual)
        AS-Scope Link State Database
        Host Table
        Interface Table
        Virtual Interface Table
        Neighbor Table
        Configured Neighbor Table
        Virtual Neighbor Table
        Area Aggregate Table
        Notifications

4.1.  General Variables

   The General Variables are global to the OSPFv3 Process.

4.2. Area Table

   The Area Data Structure describes the OSPFv3 Areas that the router
   participates in.

4.3.  Area-Scope, Link-Scope, and AS-Scope Link State Database

   The link state databases are provided primarily to provide detailed
   information for network debugging.  There are separate tables for
   Link-scope LSAs received over non-virtual and virtual interfaces.

4.4.  Host Table

   The Host Table is provided to view configured Host Route information.

4.5.  Interface Table

   The Interface Table describes the various IPv6 links on which OSPFv3
   is configured.

4.6.  Virtual Interface Table

   The Virtual Interface Table describes virtual OSPFv3 links.

4.7.  Neighbor, Configured Neighbor, and Virtual Neighbor Tables

   The Neighbor Table, the Configured Neighbor Table, and the Virtual
   Neighbor Table describe the neighbors to the OSPFv3 Process.

4.8.  Area Aggregate Table

   The Area Aggregate Table describes prefixes, which summarize routing
   information for export outside of an Area.

4.9.  Notifications

   Notifications are defined for OSPFv3 events.  Several objects are
   defined specifically as variables to be used with notifications.