Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5643

Management Information Base for OSPFv3

Pages: 95
Proposed Standard
Errata
Part 1 of 4 – Pages 1 to 9
None   None   Next

Top   ToC   RFC5643 - Page 1
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.
Top   ToC   RFC5643 - Page 2

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
Top   ToC   RFC5643 - Page 3

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.
Top   ToC   RFC5643 - Page 4

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.
Top   ToC   RFC5643 - Page 5

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).
Top   ToC   RFC5643 - Page 6

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
Top   ToC   RFC5643 - Page 7
   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
Top   ToC   RFC5643 - Page 8
        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.
Top   ToC   RFC5643 - Page 9

4.9. Notifications

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


(page 9 continued on part 2)

Next Section