Internet DRAFT - draft-kakkar-ospf-ospfv3-trap-mib

draft-kakkar-ospf-ospfv3-trap-mib





   Network Working Group                                                
   Internet Draft                                          Nitin Kakkar 
   Document: draft-kakkar-ospf-ospfv3-trap-mib-                  Huawei 
   00.txt                                                  Technologies 
                                                              Bangalore 
   Expires: May 2006                                      November 2005 
    
    
                          OSPF Version 3 Trap MIB 
                                      
    
Status of this Memo 
    
   This document is a submission by the author to IETF Network Working 
   Group of the Internet Engineering Task Force (IETF).  Comments should 
   be submitted to the nitink@huawei.com. 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.It is inappropriate to use Internet-Drafts as reference material 
   or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at  
   http://www.ietf.org/ietf/1id-abstracts.txt.  
    
   The list of Internet-Draft Shadow Directories can be accessed at  
   http://www.ietf.org/shadow.html. 
    
    
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 Traps for managing version 3 of the Open 
   Shortest Path First Routing Protocol. Version 3 of the OSPF protocol 
   is specific to the IPv6 address family. 
    
   This memo is intended to complement draft-ietf-ospf-ospfv3-mib-09.txt   
   and uses many definitions provided in this MIB. 
    
                                - 1 - 
 
<Kakkar>                  Expires - May 2006                  [Page 1] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
Conventions used in this document 
    
   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 [i]. 
    
Table of Contents 
    
   1. OSPFv3 Traps Overview..........................................2 
      1.1 Introduction...............................................2 
      1.2 Approach...................................................2 
      1.3 Ignoring Initial Activity..................................3 
      1.4 Throttling Traps...........................................3 
      1.5 One Trap Per OSPFv3 Event..................................3 
      1.6 Polling Event Counters.....................................4 
   2. Trap MIB definition............................................4 
   3. Formal Syntax.................................................14 
   Security Considerations..........................................14 
   References.......................................................14 
   Acknowledgments..................................................15 
   Author's Addresses...............................................16 
    
    
1. 
  OSPFv3 Traps Overview  
    
    
1.1 
    Introduction 
    
   As network topologies become large and complex it is getting more 
   complicated and time consuming to identify the causes and sources of 
   misbehaving devices, by polling alone. A more systematic approach is 
   for devices themselves to notify the network managers of potentially 
   critical conditions using SNMP traps.  
    
   This draft defines a set of traps, objects and mechanisms to enhance 
   the ability to manage IP internetworks which use OSPFv3 as its IGP. 
   It is an optional but very useful extension to the OSPFv3 MIB. 
    
    
1.2 
    Approach 
    
   Whenever an unexpected event occurs, the application notifies the 
   local snmp agent, which generates corresponding SNMP trap message and 
   send it to the appropriate SNMP management stations. The message 
   includes the trap type and may include a list of trap specific 
   variables. 
   Section 2 provides the trap definitions for OSPFv3 which includes the 
   variable lists. The router ID of the originator of the trap is 

 
 
<Kakkar>                  Expires - May 2006                  [Page 2] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
   included in the variable list so that the network manager can easily 
   determine the originator of the trap.  
    
   At times error conditions persist for long duration, To limit the 
   frequency of OSPFv3 traps, the following additional mechanisms are 
   suggested.  
    
    
1.3 
   Ignoring Initial Activity 
    
   Most of the transitional events occur when OSPFv3 is enabled on the 
   router, During this time the designated router is elected and 
   neighbor adjacencies are formed. All these events are normal and 
   expected, but most of them can potentially generate unnecessary SNMP 
   traps, Which should be avoided. To avoid these unnecessary traps, a 
   router should not originate expected OSPFv3 interface related traps 
   until two of that interface's dead timer intervals have elapsed. The 
   expected OSPFv3 interface traps are ospfv3IfStateChange, 
   ospfv3VirtIfStateChange, ospfv3NbrStateChange, 
   ospfv3VirtNbrStateChange, ospfv3TxRetranmit and 
   ospfv3VirtIfTxRetransmit.  
   Additionally, ospfv3MaxAgeLsa and ospfv3OriginateLsa traps should not 
   be originated until two dead timer intervals have elapsed where the 
   dead timer interval used should be the dead timer with the smallest 
   value. 
    
    
1.4 
   Throttling Traps 
    
   The mechanism for throttling the traps is similar to the mechanism 
   explained in RFC 1224 [5]. The basic premise of the throttling 
   mechanism is that of a sliding window, defined in seconds and an 
   upper bound on the number of traps that may be generated within this 
   window. Note that unlike RFC 1224, traps are not sent to inform the 
   network manager that the throttling mechanism has kicked in. A single 
   window should be used to throttle all OSPF traps types except for the 
   ospfv3LsdbOverflow and the ospfv3LsdbApproachingOverflow trap which 
   should not be throttled.  For example, with a window time of 3, an 
   upper bound of 3, and events to cause trap types 1,3,5 and 7 (4 traps 
   within a 3 second period), the type 7 (the 4th) trap should not be 
   generated. 
    
   Appropriate values are 7 traps with a window time of 10 seconds. 
    
    
1.5 
   One Trap Per OSPFv3 Event 
    
   Several of the traps defined in section 2 are generated as the result 
   of finding an unusual conditions while parsing an OSPFv3 packet or a 
 
 
<Kakkar>                  Expires - May 2006                  [Page 3] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
   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 traps and variables, OSPFv3 should generate at most one trap per 
   OSPF event. Only the variables associated with the first unusual 
   condition should be included with the trap. Similarly, if more than 
   one type of unusual condition is encountered while parsing the 
   packet, only the first event should generate a trap. 
    
    
1.6 
   Polling Event Counters 
    
   Many of the tables in the OSPFv3 MIB contain generalized event 
   counters. By enabling the traps 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 
   specific OSPFv3 traps when a particular counter starts increasing 
   abnormally. 
    
   The following table shows the relationship between the event counters 
   defined in the OSPF MIB and the trap types defined in section 2.  
    
              Counter32                     Trap Type  
        -----------------------     ------------------------  
          ospfv3OriginateNewLsas       ospfv3OriginateLsa  
          ospfv3IfEvents               ospfv3IfStateChange  
                                       ospfv3ConfigError  
                                       ospfv3IfAuthFailure  
                                       ospfv3RxBadPacket  
                                       ospfv3TxRetransmit  
          ospfv3VirtIfEvents           ospfv3VirtIfStateChange  
                                       ospfv3VirtIfConfigError  
                                       ospfv3VirtIfAuthFailure  
                                       ospfv3VirtIfRxBadPacket  
                                       ospfv3VirtIfTxRetransmit  
          ospfv3NbrEvents              ospfv3NbrStateChange  
          ospfv3VirtNbrEvents          ospfv3VirtNbrStateChange  
          ospfv3ExternLSACount         ospfv3LsdbApproachingOverflow  
          ospfv3ExternLSACount         ospfv3LsdbOverflow 
    
    
2. 
   Trap MIB definition 
    
    OSPFv3 Trap Definitions 
    OSPFv3-TRAP-MIB DEFINITIONS ::= BEGIN 
    
       IMPORTS 
 
 
<Kakkar>                  Expires - May 2006                  [Page 4] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
          MODULE-IDENTITY,OBJECT-TYPE,NOTIFICATION-TYPE,IpAddress 
              FROM SNMPv2-SMI 
          MODULE-COMPLIANCE, OBJECT-GROUP 
              FROM SNMPv2-CONF 
          TEXTUAL-CONVENTION  
              FROM SNMPv2-TC  
          InetAddress, InetAddressPrefixLength  
              FROM INET-ADDRESS-MIB  
          ospfv3RouterId, ospfv3IfIndex, ospfv3IfInstId, ospfv3IfState, 
          ospfv3NbrIfIndex, ospfv3NbrIfInstId, ospfv3VirtIfAreaId, 
          ospfv3VirtIfNeighbor, ospfv3VirtIfState, ospfv3NbrRtrId, 
          ospfv3NbrState, ospfv3VirtNbrArea, ospfv3VirtNbrRtrId, 
          ospfv3VirtIfInstId, ospfv3VirtNbrState,  
          ospfv3ExtAreaLsdbLimit, Ospfv3RouterIdTc, Ospfv3AreaIdTc 
              FROM OSPFV3-MIB; 
    
       ospfv3Trap MODULE-IDENTITY 
          LAST-UPDATED "200511151600Z" -- Tue Nov 15 16:00:00 IST 2005 
          ORGANIZATION "" 
          CONTACT-INFO 
          "Nitin Kakkar 
           Postal:         Huawei Technologies India Pvt Ltd 
                           Level-3, Leela Galleria, 
                           The Leela Palace, #23 Airport Road,  
                           Bangalore 560008, India 
          Tel:             +91 80 5217192 
          E-Mail:          nitink@huawei.com                 " 
          DESCRIPTION 
             "The MIB module to describe traps for the OSPF Version-3 
              Protocol." 
         ::= { ospfv3Objects 13 } 
    
   -- Trap Support Objects 
    
   -- The following are support objects for the OSPFv3 traps. 
    
   ospfv3TrapControl OBJECT IDENTIFIER ::= { ospfv3Trap 1 } 
   ospfv3Traps OBJECT IDENTIFIER ::= { ospfv3Trap 2 } 
    
       ospfv3SetTrap  OBJECT-TYPE 
          SYNTAX      OCTET STRING (SIZE(4)) 
          MAX-ACCESS  read-write 
          STATUS      current 
          DESCRIPTION 
             "A four-octet string serving as a bit  map  for 
              the trap events defined by the OSPFv3 traps. This 
              object is used to enable and  disable  specific 
              OSPFv3 traps where a 1 in the bit field represents  
              enabled. The right-most bit  (least significant)  
 
 
<Kakkar>                  Expires - May 2006                  [Page 5] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
              represents trap 0." 
          ::= { ospfv3TrapControl 1 } 
    
       ospfv3ConfigErrorType OBJECT-TYPE 
          SYNTAX   INTEGER   { 
                     badVersion (1), 
                     areaMismatch (2), 
                     unknownNbmaNbr (3), -- Router is Dr eligible 
                     unknownVirtualNbr (4), 
                     helloIntervalMismatch (5), 
                     deadIntervalMismatch (6), 
                     optionMismatch (7), 
                     instanceMismatch (8) } 
          MAX-ACCESS  read-only 
          STATUS   current 
          DESCRIPTION 
             "Potential types of configuration conflicts. 
              Used by the ospfv3ConfigError and ospfv3ConfigVir- 
              tError traps." 
          ::= { ospfv3TrapControl 2 } 
    
       ospfv3PacketType OBJECT-TYPE 
          SYNTAX   INTEGER   { 
                     hello (1), 
                     dbDescript (2), 
                     lsReq (3), 
                     lsUpdate (4), 
                     lsAck (5) } 
          MAX-ACCESS  read-only 
          STATUS   current 
          DESCRIPTION 
             "OSPFv3 packet types." 
          ::= { ospfv3TrapControl 3 } 
    
       ospfv3PacketSrc OBJECT-TYPE 
          SYNTAX   InetAddress 
          MAX-ACCESS   read-only 
          STATUS   current 
          DESCRIPTION 
             "The IPv6 address of an inbound packet that  can- 
              not be identified by a neighbor instance." 
          ::= { ospfv3TrapControl 4 } 
    
       ospfv3LsdbAreaId OBJECT-TYPE  
          SYNTAX          Ospfv3AreaIdTc  
          MAX-ACCESS      not-accessible  
          STATUS          current  
          DESCRIPTION  
             "The 32-bit identifier of the Area from which the  
 
 
<Kakkar>                  Expires - May 2006                  [Page 6] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
              LSA was received." 
          REFERENCE  
             "OSPF Version 2, Appendix C.2 Area parameters"  
          ::= { ospfv3TrapControl 5 }  
    
       ospfv3LsdbType OBJECT-TYPE  
          SYNTAX          Unsigned32(0..'FFFFFFFF'h)  
          MAX-ACCESS      not-accessible  
          STATUS          current  
          DESCRIPTION  
             "The type of the link state advertisement.  
              Each link state type has a separate  
              advertisement format. Area-Scope LSAs unrecognized  
              by the router are also stored in this database."  
          ::= { ospfv3TrapControl 6 }  
    
       ospfv3LsdbRouterId OBJECT-TYPE  
          SYNTAX          Ospfv3RouterIdTc  
          MAX-ACCESS      not-accessible  
          STATUS          current  
          DESCRIPTION  
             "The 32-bit number that uniquely identifies the  
              originating router in the Autonomous System."  
          REFERENCE  
             "OSPF Version 2, Appendix C.1 Global parameters"  
          ::= { ospfv3TrapControl 7 }  
    
       ospfv3LsdbLsid OBJECT-TYPE  
          SYNTAX          Unsigned32  
          MAX-ACCESS      not-accessible  
          STATUS          current  
          DESCRIPTION  
             "The Link State ID is an LS Type Specific field 
              containing a unique identifier; 
              it identifies the piece of the routing domain 
              that is being described by the advertisement.  
              In contrast to OSPFv2, the LSID has no  
              addressing semantics."  
           ::= { ospfv3TrapControl 8 }  
   -- Traps 
    
       ospfv3IfStateChange NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3IfIndex, 
                     ospfv3IfInstId, 
                     ospfv3IfState -- The new state 
                    } 
    
 
 
<Kakkar>                  Expires - May 2006                  [Page 7] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3IfStateChange trap signifies that there 
             has been a change in the state of a non-virtual 
             OSPF interface. This trap should  be  generated 
             when  the interface state regresses (e.g., goes 
             from Dr to Down) or progresses  to  a  terminal 
             state  (i.e.,  Point-to-Point, DR Other, Dr, or 
             Backup)." 
          ::= { ospfv3Traps 1 } 
    
       ospfv3VirtIfStateChange NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3VirtIfAreaId, 
                     ospfv3VirtIfNeighbor, 
                     ospfv3VirtIfInstId, 
                     ospfv3VirtIfState  -- The new state 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3IfStateChange trap signifies that there 
             has  been a change in the state of an OSPF virtual 
             interface. 
    
             This trap should be generated when  the  inter- 
             face  state  regresses  (e.g., goes from Point- 
             to-Point to Down) or progresses to  a  terminal 
             state (i.e., Point-to-Point)." 
          ::= { ospfv3Traps 2 } 
    
       ospfv3NbrStateChange NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3NbrIfIndex,  
                     ospfv3NbrIfInstId,  
                     ospfv3NbrRtrId, 
                     ospfv3NbrState  -- The new state 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3NbrStateChange trap signifies that 
             there has been a change in the state of a non- 
             virtual OSPF neighbor. This trap should be 
             generated when the neighbor state regresses 
             (e.g., goes from Attempt or Full  to  1-Way  or 
             Down)  or progresses to a terminal state (e.g., 
             2-Way or Full).  When an  neighbor  transitions 
             from  or  to Full on non-broadcast multi-access 
 
 
<Kakkar>                  Expires - May 2006                  [Page 8] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
             and broadcast networks, the trap should be gen- 
             erated  by the designated router.  A designated 
             router transitioning to Down will be  noted  by 
             ospfv3IfStateChange." 
          ::= { ospfv3Traps 3 } 
    
       ospfv3VirtNbrStateChange NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3VirtNbrArea, 
                     ospfv3VirtNbrIfInstId, 
                     ospfv3VirtNbrRtrId, 
                     ospfv3VirtNbrState  -- The new state 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3IfStateChange trap signifies that there 
             has  been a change in the state of an OSPF vir- 
             tual neighbor.  This trap should  be  generated 
             when  the  neighbor state regresses (e.g., goes 
             from Attempt or  Full  to  1-Way  or  Down)  or 
             progresses to a terminal state (e.g., Full)." 
          ::= { ospfv3Traps 4 } 
    
       ospfv3IfConfigError NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3IfIndex, 
                     ospfv3IfInstId, 
                     ospfv3PacketSrc,  -- The source IPv6 address 
                     ospfv3ConfigErrorType, -- Type of error 
                     ospfv3PacketType 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3IfConfigError  trap  signifies  that  a 
             packet  has  been received on a non-virtual in- 
             terface  from  a  router  whose   configuration 
             parameters  conflict  with this router's confi- 
             guration parameters.  Note that the  event  op- 
             tionMismatch  should  cause  a  trap only if it 
             prevents an adjacency from forming." 
          ::= { ospfv3Traps 5 } 
    
       ospfv3VirtIfConfigError NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3VirtIfAreaId, 
                     ospfv3VirtIfNeighbor, 
 
 
<Kakkar>                  Expires - May 2006                  [Page 9] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
                     ospfv3VirtIfInstId, 
                     ospfv3ConfigErrorType, -- Type of error 
                     ospfv3PacketType 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3VirtIfConfigError trap signifies that a 
             packet has been  received  on a virtual interface 
             from a router  whose  configuration  parameters 
             conflict   with   this  router's  configuration 
             parameters.  Note that the event optionMismatch 
             should  cause a trap only if it prevents an ad- 
             jacency from forming." 
          ::= { ospfv3Traps 6 } 
    
      ospfv3IfRxBadPacket NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3IfIndex, 
                     ospfv3IfInstId, 
                     ospfv3PacketSrc,  -- The source IPv6 address 
                     ospfv3PacketType 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3IfRxBadPacket trap  signifies  that  an 
             OSPF  packet has been received on a non-virtual 
             interface that cannot be parsed." 
          ::= { ospfv3Traps 7 } 
    
       ospfv3VirtIfRxBadPacket NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3VirtIfAreaId, 
                     ospfv3VirtIfNeighbor, 
                     ospfv3VirtIfInstId, 
                     ospfv3PacketType 
                    } 
          STATUS     current 
          DESCRIPTION 
              "An ospfv3VirtIfRxBadPacket trap signifies that an 
              OSPFv3 packet has been received on a virtual  
              interface that cannot be parsed." 
          ::= { ospfv3Traps 8 } 
    
       ospfv3TxRetransmit NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3IfIndex, 
 
 
<Kakkar>                  Expires - May 2006                 [Page 10] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
                     ospfv3IfInstId, 
                     ospfv3NbrRtrId, -- Destination 
                     ospfv3PacketType, 
                     ospfv3LsdbType, 
                     ospfv3LsdbLsid, 
                     ospfv3LsdbRouterId 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3TxRetransmit  trap  signifies  than  an 
             OSPF  packet  has  been retransmitted on a non- 
             virtual interface.  All packets that may be re- 
             transmitted  are associated with an LSDB entry. 
             The LS type, LS ID, and Router ID are  used  to 
             identify the LSDB entry." 
          ::= { ospfv3Traps 9 } 
    
       ospfv3VirtIfTxRetransmit NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3VirtIfAreaId, 
                     ospfv3VirtIfNeighbor, 
                     ospfv3VirtIfInstId, 
                     ospfv3PacketType, 
                     ospfv3LsdbType, 
                     ospfv3LsdbLsid, 
                     ospfv3LsdbRouterId 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3VirtIfTxRetransmit  trap  signifies  than 
             an OSPF packet has been retransmitted on a virtual 
             interface.  All packets that may be retransmitted 
             are  associated with an LSDB entry. The LS type, 
             LS ID, and Router ID are used to identify the LSDB 
             entry." 
          ::= { ospfv3Traps 10 } 
    
       ospfv3OriginateLsa NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3LsdbAreaId,  -- 0.0.0.0 for AS Externals 
                     ospfv3LsdbType, 
                     ospfv3LsdbLsid, 
                     ospfv3LsdbRouterId 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3OriginateLsa trap signifies that a new 
 
 
<Kakkar>                  Expires - May 2006                 [Page 11] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
             LSA  has  been originated by this router.  This 
             trap should not be invoked for simple refreshes 
             of  LSAs  (which happesn every 30 minutes), but 
             instead will only be invoked  when  an  LSA  is 
             (re)originated due to a topology change.  Addi- 
             tionally, this trap does not include LSAs  that 
             are  being  flushed  because  they have reached 
             MaxAge." 
          ::= { ospfv3Traps 11 } 
    
       ospfv3MaxAgeLsa NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3LsdbAreaId,  -- 0.0.0.0 for AS Externals 
                     ospfv3LsdbType, 
                     ospfv3LsdbLsid, 
                     ospfv3LsdbRouterId 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3MaxAgeLsa trap signifies  that  one  of 
             the LSA in the router's link-state database has 
             aged to MaxAge." 
          ::= { ospfv3Traps 12 } 
    
       ospfv3UnknownLsa NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfLsid, 
                     ospfv3IfIndex, -- Input interface 
                     ospfv3IfInstId, 
                     ospfOrigRouterId, -- Originator routerID 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3UnknownLsa trap signifies  that  one  of 
             the Nbr has sent an UNknown LSA. Only DR generate  
             this trap and If NBR state is less than Exchange 
             need not originate this trap" 
          ::= { ospfv3Traps 13 } 
    
       ospfv3LsdbOverflow NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3ExtAreaLsdbLimit 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3LsdbOverflow trap  signifies  that  the 
 
 
<Kakkar>                  Expires - May 2006                 [Page 12] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
             number of LSAs in the router's link-state data- 
             base has exceeded ospfv3ExtAreaLsdbLimit." 
          ::= { ospfv3Traps 14 } 
    
       ospfv3LsdbApproachingOverflow NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                     ospfv3ExtAreaLsdbLimit 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3LsdbApproachingOverflow trap  signifies 
             that  the  number of LSAs in the router's link- 
             state database has exceeded ninety  percent  of 
             ospfv3ExtAreaLsdbLimit." 
          ::= { ospfv3Traps 15 } 
      
      ospfv3AsbrStatusChange NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3AsbrStatusChange trap signifies 
             that  device's Asbr Status has changed." 
          ::= { ospfv3Traps 16 } 
                             
      ospfv3AbrStatusChange NOTIFICATION-TYPE 
          OBJECTS   { 
                     ospfv3RouterId, -- The originator of the trap 
                    } 
          STATUS     current 
          DESCRIPTION 
             "An ospfv3AbrStatusChange trap  signifies 
             that  device's Abr Status has changed. 
             There are two distinct definitions  
             of ABR given by IBM & Cisco, Implementations are free 
             to follow their own interpretation of ABR while 
             originating this trap" 
           ::= { ospfv3Traps 17 }  
       
   -- conformance information 
    
   ospfv3TrapConformance OBJECT IDENTIFIER ::= { ospfv3Trap 3 } 
    
   ospfv3TrapGroups      OBJECT IDENTIFIER ::= { ospfv3TrapConformance 1 
   } 
   ospfv3TrapCompliances OBJECT IDENTIFIER ::= { ospfv3TrapConformance 2 
   } 
 
 
<Kakkar>                  Expires - May 2006                 [Page 13] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
    
   -- compliance statements 
    
       ospfv3TrapCompliance MODULE-COMPLIANCE 
          STATUS  current 
          DESCRIPTION 
             "The compliance statement " 
          MODULE  -- this module 
          MANDATORY-GROUPS { ospfv3TrapControlGroup } 
    
          GROUP       ospfv3TrapControlGroup 
          DESCRIPTION 
             "This group is optional but recommended for all 
             OSPFv3 systems" 
    
          ::= { ospfv3TrapCompliances 1 } 
    
   -- units of conformance 
    
       ospfv3TrapControlGroup    OBJECT-GROUP 
          OBJECTS   { 
                     ospfv3SetTrap, 
                     ospfv3ConfigErrorType, 
                     ospfv3PacketType, 
                     ospfv3PacketSrc 
                    } 
          STATUS     current 
          DESCRIPTION 
             "These objects are required  to  control  traps 
             from OSPF systems." 
          ::= { ospfv3TrapGroups 1 } 
    
   END 
    
    
3. 
   Formal Syntax 
    
   The following syntax specification uses the augmented Backus-Naur 
   Form (BNF) as described in RFC-2234. 
    
    
Security Considerations 
    
   This document does not introduce any new security issues to OSPFv3 
    
    
References 
    

 
 
<Kakkar>                  Expires - May 2006                 [Page 14] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
                                                                         
    
   [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 
   Rose, M. and S. Waldbusser, "Structure of Management Information 
   Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.  
    
   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 
   Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 
   RFC 2579, April 1999. 
    
   [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 
   Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 
   58, RFC 2580, April 1999. 
    
   [RFC2863] McCloghrie, K., Kastenholtz, F., "The Interfaces Group 
   MIB", RFC 2863, June 2000. 
    
   [RFC1224] L. Steinberg, "Techniques for Managing Asynchronously 
   Generated Alerts" 
    
   [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 
   "Introduction and Applicability Statements for Internet-Standard 
   Management Framework", RFC 3410, December 2002. 
    
   [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 
    
   [RFC1850] Baker, F., and Coltun, R., "OSPF Version 2 Management 
   Information Base", RFC 1850, November 1995. 
    
   [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 
   RFC 3101, January 2003. 
    
   [RFC2370] Coltun, R., "The OSPF Opqaue LSA Option", RFC 2370, July 
   1998. 
    
   [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. 
    
   [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 
   1793, April 1995.  
    
    
    
Acknowledgments 
    
   This document is based on the MIB for OSPF version 2 by Rob Coltun 
   and Fred Baker [8] and MIB for OSPF version 3[13] by Dan Joyal and 
   Vishwas Manral. I would like to acknowledge KL Srini, Fuchao, Praveen 
   GS, & Others for their constructive comments. 

 
 
<Kakkar>                  Expires - May 2006                 [Page 15] 
Internet Draft         OSPF Version 3 Trap MIB          November 2005 
 
 
    
    
Author's Addresses 
    
   Nitin Kakkar  
   Huawei Technologies India Pvt Ltd, 
   Level-3, Leela Galleria, 
   The Leela Palace, #23 Airport Road,  
   Bangalore 560008, India 
   Phone: +91 80 5217192 
   Email: nitink@huawei.com 
    
    
Disclaimer of Validity 
 
   "This document and the information contained herein are provided on    
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE   
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR   
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF   
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED   
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."   
 
  
Copyright Statement  
  
   Copyright (C) The Internet Society (2005).  This document is  
   subject to the rights, licenses and restrictions contained in BCP   
   78, and except as set forth therein, the authors retain all their  
   rights. 
    
















 
 
<Kakkar>                  Expires - May 2006                 [Page 16]