Network Working Group D. Joyal, Ed.
Request for Comments: 5643 Nortel
Category: Standards Track V. Manral, Ed.
August 2009 Management Information Base for OSPFv3
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 (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
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
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.,
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
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.
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
- ospfv3AreaSpfRuns and ospfv3AreaNssaTranslatorEvents in the
- 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.
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).
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
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
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
Appropriate values are 7 notifications with a window time of 10
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
4. Structure of the OSPFv3 MIB Module
The MIB is composed of the following sections:
Area-Scope Link State Database
Link-Scope Link State Databases (non-virtual and virtual)
AS-Scope Link State Database
Virtual Interface Table
Configured Neighbor Table
Virtual Neighbor Table
Area Aggregate Table
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
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
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.