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]
