[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

     Internet Draft            OSPF Trap MIB                  February 1993
     
     
                           OSPF Version 2 Traps
     
     
     
                                Rob Coltun
     
                                Consultant
     
                              (301) 340-9416
                            rcoltun@ni.umd.edu
     
     
                                Fred Baker
     
                     Advanced Computer Communications
                             315 Bollay Drive
                      Santa Barbara, California 93117
     
                              fbaker@acc.com
     
     
     
     
     
                             Table Of Contents
     
     
     
     1.0 Status Of This Memo ...................................... 2
     2.0 Abstract ................................................. 2
     3.0 The Network Management Framework ......................... 2
     4.0 Objects .................................................. 3
     4.0 Format Of Definitions .................................... 3
     5.0 Approach ................................................. 4
     5.1 Ignoring Initial Activity ................................ 4
     5.2 Throttling Traps ......................................... 4
     5.3 One Trap Per OSPF Event .................................. 4
     5.4 Polling Event Counters ................................... 5
     6.0 OSPF Trap Definitions .................................... 6
     6.1 Imports .................................................. 6
     6.2 Trap Support Objects ..................................... 6
     6.3 Traps .................................................... 7
     7.0 Acknowledgements ......................................... 12
     8.0 References ............................................... 12
     
     
     
     
     
     
     
     
     
     
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 1]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
     1.0     Status Of This Memo
     
          This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
          other documents at any time. It is not appropriate to use  Inter-
          net  Drafts as reference material or to cite them other than as a
          "working draft" or "work in progress."
     
          Please check the I-D abstract listing contained in each  Internet
          Draft  directory to learn the current status of this or any other
          Internet Draft.
     
          This memo does not, in its draft form, specify a standard for the
          Internet community.
     
     
     2.0     Abstract
     
          OSPF [1] is an event driven routing protocol, where an event  can
          be a change in an OSPF interface's link-level status, the expira-
          tion of an OSPF timer  or  the  reception  of  an  OSPF  protocol
          packet.  Many of the actions that OSPF takes as a result of these
          events will result in a change of the routing topology.  As rout-
          ing  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.  Another approach is
          to notify a network manager of potentially critical  OSPF  events
          with SNMP traps.
     
          This draft document defines a set of traps, objects  and  mechan-
          isms  to enhance the ability to manage IP internetworks which use
          OSPF as its IGP.  It is meant as an extension  to  the  OSPF  MIB
          [2].
     
     
     3.0     The Network Management Framework
     
          The Internet-standard Network Management  Framework  consists  of
          three components. They are:
     
               RFC 1155 [5] which defines the SMI, the mechanisms used  for
               describing and naming objects for the purpose of management.
               RFC 1212 [8] defines a more concise  description  mechanism,
               which is wholly consistent with the SMI.
     
               RFC 1156 [6] which defines MIB-I, the core  set  of  managed
               objects  for  the  Internet suite of protocols. RFC 1213 [9]
               defines MIB-II, an evolution of MIB-I based  on  implementa-
               tion experience and new operational requirements.
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 2]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
               RFC 1157 [7] which defines the SNMP, the protocol  used  for
               network access to managed objects.
     
          The Framework permits new objects to be defined for  the  purpose
          of experimentation and evaluation.
     
     
     4.0     Objects
     
          Managed objects are accessed via  a  virtual  information  store,
          termed the Management Information Base or MIB. Objects in the MIB
          are defined using the subset  of  Abstract  Syntax  Notation  One
          (ASN.1)  [3] defined in the SMI. In particular, each object has a
          name, a syntax, and an encoding. The name is an  object  identif-
          ier, an administratively assigned name, which specifies an object
          type. The object type together with an object instance serves  to
          uniquely  identify  a  specific  instantiation of the object. For
          human convenience, we often use  a  textual  string,  termed  the
          OBJECT DESCRIPTOR, to also refer to the object type.
     
          The syntax of an object type defines the abstract data  structure
          corresponding  to  that  object type.  The ASN.1 language is used
          for this purpose. However, the SMI purposely restricts the  ASN.1
          constructs  which may be used.  These restrictions are explicitly
          made for simplicity.
     
          The encoding of an object type is simply how that object type  is
          represented  using  the  object type's syntax. Implicitly tied to
          the notion of an object type's syntax and  encoding  is  how  the
          object type is represented when being transmitted on the network.
     
          The SMI specifies the use of the basic encoding  rules  of  ASN.1
          [4], subject to the additional requirements imposed by the SNMP.
     
          The SMI does not provide a means for defining traps.   The  SNMP,
          however,  does  define  a few standard traps and provides a means
          for defining  enterprise-specific  traps.   The  TRAP-TYPE  macro
          defined  in  RFC  1215  [10] suggests a straight-forward approach
          towards defining traps used with the SNMP.
     
     
     4.1     Format of Definitions
     
          Section 6 contains the specification of  all  object  types  con-
          tained in this MIB module. The object types are defined using the
          conventions defined in the SMI,  as  amended  by  the  extensions
          specified in RFC 1212.
     
          Section 6.3 contains contains  the  trap  definitions  using  the
          TRAP-TYPE macro described in RFC 1215.
     
     
     
     
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 3]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
     5.0     Approach
     
          The mechanism for sending traps  is  straight-forward.   When  an
          exception  event occurs, the application notifies the local agent
          who sends a trap to the  appropriate  SNMP  management  stations.
          The message includes the trap type and may include a list of trap
          specific variables.  A new object is defined in section 6.2  that
          will allow a network manager to enable or disable particular OSPF
          traps.  Section 6.3 gives the trap definitions which includes the
          variable  lists.   The router ID of the originator of the trap is
          included in the variable list so that  the  network  manager  may
          easily determine the source of the trap.
     
          To limit the frequency of OSPF traps,  the  following  additional
          mechanisms are suggested.
     
     
     5.1     Ignoring Initial Activity
     
          The majority of critical events occur when OSPF is enabled  on  a
          router, at which time the designated router is elected and neigh-
          bor adjacencies are formed.  During this initial period a  poten-
          tial flood of traps is unnecessary since the events are expected.
          To  avoid  unnecessary  traps,  a  router  should  not  originate
          expected   OSPF   interface  related  traps  until  two  of  that
          interface's dead timer intervals have elapsed.  The expected OSPF
          interface  traps  are  ospfIfStateChange,  ospfVirtIfStateChange,
          ospfNbrStateChange, ospfVirtNbrStateChange,  ospfTxRetranmit  and
          ospfVirtIfTxRetransmit.  Additionally, ospfMaxAgeLsa and ospfOri-
          ginateLsa 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.
     
     
     5.2     Throttling Traps
     
          The mechanism for throttling the traps is similar to the  mechan-
          ism explained in RFC 1224 [11] section 5.  The basic idea is that
          there is a sliding window in seconds and an upper  bound  on  the
          number of traps that may be generated within this window.  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 ospfLsdbOverflow and the ospfLsdbApproachingOver-
          flow trap which should not be throttled.   For  example,  if  the
          window  time is 3, the upper bound is 3 and the events that would
          cause trap types 1,3,5 and 7 occur within a 3 second period,  the
          type 7 trap should not be generated.
     
          Appropriate values are 7 traps with a window time of 10 seconds.
     
     
     5.3     One Trap Per OSPF Event
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 4]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
          Several of the traps defined in section 6.3 are generated as  the
          result  of  finding  an  unusual  condition while parsing an OSPF
          packet or a processing a timer event.  There may be more than one
          unusual  condition  detected while handling the event.  For exam-
          ple, 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, OSPF 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  con-
          dition  is  encountered  while parsing the packet, only the first
          event will generate a trap.
     
     
     5.4     Polling Event Counters
     
          Many of the tables in the  OSPF  MIB  contain  generalized  event
          counters.   By enabling the traps defined in this document a net-
          work manager can obtain more  specific  information  about  these
          events.   A network manager may want to poll these event counters
          and enable specific OSPF 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 6.3.
     
     
     
                     Counter                    Trap Type
             -----------------------   ------------------------
             ospfOriginateNewLsas       ospfOriginateLsa
             ospfIfEvents               ospfIfStateChange
                                        ospfConfigError
                                        ospfIfAuthFailure
                                        ospfRxBadPacket
                                        ospfTxRetransmit
             ospfVirtIfEvents           ospfVirtIfStateChange
                                        ospfVirtIfConfigError
                                        ospfVirtIfAuthFailure
                                        ospfVirtIfRxBadPacket
                                        ospfVirtIfTxRetransmit
             ospfNbrEvents              ospfNbrStateChange
             ospfVirtNbrEvents          ospfVirtNbrStateChange
             ospfExternLSACount         ospfLsdbApproachingOverflow
             ospfExternLSACount         ospfLsdbOverflow
     
     
     
     
     
     
     
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 5]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
     6.0                    OSPF Trap Definitions
     
     6.1                    Imports
     
          RFCXXX-MIB DEFINITIONS ::= BEGIN
               IMPORTS
                    IpAddress, OSPF
                         FROM RFC1155-SMI
                    OBJECT-TYPE
                         FROM RFC1212
                    TRAP-TYPE
                         FROM RFC1215
                    ospfRouterId, ospfIfIpAddress, ospfAddressLessIf,
                    ospfAreaId, ospfIfType, ospfIfState, ospfVirtAreaId,
                    ospfVirtIfNeighbor, ospfVirtIfState, ospfNbrIpAddr,
                    ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrState,
                    ospfVirtNbrArea, ospfVirtNbrRtrId, ospfLsdbAreaId,
                    ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId,
                    ospfExtLsdbLimit
                         FROM RFC1253-OSPF MIB
     
     
     6.2     Trap Support Objects
     
     -- Trap Support Objects
     
          ospfTrapGroup OBJECT IDENTIFIER ::= { ospf 14 }
     
          ospfSetTrap     OBJECT-TYPE
               SYNTAX  OCTET STRING
               ACCESS  read-write
               STATUS  mandatory
               DESCRIPTION
                         "A four-octet string serving as a bit map for  the
                         trap events defined by the OSPF traps. This object
                         is used to enable and disable specific OSPF  traps
                         where  a  1  in  the bit field represents enabled.
                         The right-most bit (least significant)  represents
                         trap 0."
               ::= { ospfTrapGroup 1 }
     
     
          ospfConfigErrorType     OBJECT-TYPE
               SYNTAX  INTEGER {
                         badVersion (1),
                         areaMismatch (2),
                         unknownNbmaNbr (3), -- Router is Dr eligible
                         unknownVirtualNbr (4),
                         authTypeMismatch(5),
                         authFailure (6),
                         netMaskMismatch (7),
                         helloIntervalMismatch (8),
                         deadIntervalMismatch (9),
                         optionMismatch (10) }
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 6]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                         "Potential types of configuration conflicts.  Used
                         by  the  ospfConfigError  and  ospfConfigVirtError
                         traps."
               ::= { ospfTrapGroup 2 }
     
     
          ospfPacketType  OBJECT-TYPE
               SYNTAX  INTEGER {
                         hello (1),
                         dbDescript (2),
                         lsReq (3),
                         lsUpdate (4),
                         lsAck (5) }
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                         "OSPF packet types."
               ::= { ospfTrapGroup 3 }
     
     
     6.3     Traps
     
     -- Traps
     
          ospfIfStateChange       TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfIfIpAddress,
                    ospfAddressLessIf,
                    ospfIfState } -- The new state
               DESCRIPTION
                    "An ospfIfStateChange trap  signifies  that  there  has
                    been a change in the state of a non-virtual OSPF inter-
                    face. 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)."
               ::= 0
     
     
          ospfVirtIfStateChange   TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtAreaId,
                    ospfVirtIfNeighbor,
                    ospfVirtIfState } -- The new state
               DESCRIPTION
                    "An ospfIfStateChange trap  signifies  that  there  has
                    been   a  change  in  the  state  of  an  OSPF  virtual
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 7]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
                    interface." This trap  should  be  generated  when  the
                    interface  state  regresses (e.g., goes from "Point-to-
                    Point to "Down") or  progresses  to  a  terminal  state
                    (i.e., Point-to-Point)."
               ::= 1
     
     
          ospfNbrStateChange      TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfNbrIpAddr,
                    ospfNbrAddressLessIndex,
                    ospfNbrRtrId,
                    ospfNbrState } -- The new state
               DESCRIPTION
                    "An ospfNbrStateChange trap signifies  that  there  has
                    been a change in the state of a non-virtual OSPF neigh-
                    bor.  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 transi-
                    tions from or to "Full" on  non-broadcast  multi-access
                    and broadcast networks, the trap should be generated by
                    the designated router.  A designated router transition-
                    ing to "Down" will be noted by ospfIfStateChange."
               ::= 2
     
     
          ospfVirtNbrStateChange  TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtNbrArea,
                    ospfVirtNbrRtrId,
                    ospfVirtNbrState } -- The new state
               DESCRIPTION
                    "An ospfIfStateChange trap  signifies  that  there  has
                    been a change in the state of an OSPF virtual 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")."
               ::= 3
     
     
          ospfIfConfigError       TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfIfIpAddress,
                    ospfAddressLessIf,
                    IpAddress,  -- The source IP address
                    ospfConfigErrorType, -- Type of error
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 8]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
                    ospfPacketType }
               DESCRIPTION
                    "An ospfIfConfigError trap signifies that a packet  has
                    been  received on a non-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 adjacency from forming."
               ::= 4
     
     
          ospfVirtIfConfigError   TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtAreaId,
                    ospfVirtIfNeighbor,
                    ospfConfigErrorType, -- Type of error
                    ospfPacketType }
               DESCRIPTION
                    "An ospfConfigError 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 adjacency from forming."
               ::= 5
     
     
          ospfIfAuthFailure       TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfIfIpAddress,
                    ospfAddressLessIf,
                    IpAddress,  -- The source IP address
                    ospfConfigErrorType, -- authTypeMismatch or authFailure
                    ospfPacketType }
               DESCRIPTION
                    "An ospfIfAuthFailure trap signifies that a packet  has
                    been  received on a non-virtual interface from a router
                    whose authentication key or  authentication  type  con-
                    flicts with this router's authentication key or authen-
                    tication type."
               ::= 6
     
     
          ospfVirtIfAuthFailure   TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtAreaId,
                    ospfVirtIfNeighbor,
                    ospfConfigErrorType, -- authTypeMismatch or authFailure
     
     
     
     Coltun and Baker     Expires August 31 1993                   [Page 9]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
                    ospfPacketType }
               DESCRIPTION
                    "An ospfVirtIfAuthFailure trap signifies that a  packet
                    has  been received on a virtual interface from a router
                    whose authentication key or  authentication  type  con-
                    flicts with this router's authentication key or authen-
                    tication type."
               ::= 7
     
     
          ospfIfRxBadPacket       TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfIfIpAddress,
                    ospfAddressLessIf,
                    IpAddress,  -- The source IP address
                    ospfPacketType }
               DESCRIPTION
                    "An  ospfIfRxBadPacket  trap  signifies  that  an  OSPF
                    packet  has  been  received  on a non-virtual interface
                    that cannot be parsed."
               ::= 8
     
     
          ospfVirtIfRxBadPacket   TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtAreaId,
                    ospfVirtIfNeighbor,
                    ospfPacketType }
               DESCRIPTION
                    "An ospfRxBadPacket trap signifies that an OSPF  packet
                    has been received on a virtual interface that cannot be
                    parsed."
               ::= 9
     
     
          ospfTxRetransmit        TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfIfIpAddress,
                    ospfAddressLessIf,
                    ospfNbrRtrId, -- Destination
                    ospfPacketType,
                    ospfLsdbType,
                    ospfLsdbLsid,
                    ospfLsdbRouterId }
               DESCRIPTION
                    "An ospfTxRetransmit trap signifies than an OSPF packet
                    has been retransmitted on a non-virtual interface.  All
                    packets that may be retransmitted are  associated  with
     
     
     
     Coltun and Baker     Expires August 31 1993                  [Page 10]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
                    an  LSDB  entry.  The LS type, LS ID, and Router ID are
                    used to identify the LSDB entry."
               ::= 10
     
     
          ospfVirtIfTxRetransmit  TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfVirtAreaId,
                    ospfVirtIfNeighbor,
                    ospfPacketType,
                    ospfLsdbType,
                    ospfLsdbLsid,
                    ospfLsdbRouterId }
               DESCRIPTION
                    "An ospfTxRetransmit 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."
               ::= 11
     
     
          ospfOriginateLsa        TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfLsdbAreaId,  -- 0.0.0.0 for AS Externals
                    ospfLsdbType,
                    ospfLsdbLsid,
                    ospfLsdbRouterId }
               DESCRIPTION
                    "An ospfOriginateLsa trap signifies that a new 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.
                    Additionally,  this trap does not include LSAs that are
                    being flushed because they have reached MaxAge."
               ::= 12
     
     
          ospfMaxAgeLsa   TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfLsdbAreaId,  -- 0.0.0.0 for AS Externals
                    ospfLsdbType,
                    ospfLsdbLsid,
                    ospfLsdbRouterId }
               DESCRIPTION
                    "An ospfMaxAgeLsa trap signifies that one of the LSA in
                    the router's link-state database has aged to MaxAge."
     
     
     
     Coltun and Baker     Expires August 31 1993                  [Page 11]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
               ::= 13
     
     
          ospfLsdbOverflow        TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfExtLsdbLimit }
               DESCRIPTION
                    "An ospfLsdbOverflow trap signifies that the number  of
                    LSAs  in  the router's link-state database has exceeded
                    ospfExtLsdbLimit."
               ::= 14
     
     
          ospfLsdbApproachingOverflow     TRAP-TYPE
               ENTERPRISE      ospf
               VARIABLES {
                    ospfRouterId, -- The originator of the trap
                    ospfExtLsdbLimit }
               DESCRIPTION
                    "An ospfLsdbApproachingOverflow trap signifies that the
                    number  of LSAs in the router's link-state database has
                    exceeded ninety percent of ospfExtLsdbLimit."
               ::= 15
     END
     
     
     7.0     Acknowledgements
     
          This document was produced by the OSPF Working Group, chaired  by
          John Moy.
     
          In addition, the comments of the following individuals  are  also
          acknowledged:
                  Dino Farinacci  cisco
                  Vince Fuller    BARRNet
                  Stan Froyd      ACC
                  Dean Morris     Digital Equipment Corp.
                  John Moy        Proteon, Inc.
     
     
     
     8.0     References
     
          [1]  J. Moy, The OSPF Specification, Version 2 Internet
               Draft, Internet Engineering Task Force, (November, 1992).
     
          [2]  F. Baker and R. Coltun, OSPF Version 2 Management
               Information Base Internet Draft, Internet Engineering
               Task Force, (November 1992)
     
          [3]  Information processing systems - Open Systems
               Interconnection - Specification of Abstract Syntax
     
     
     
     Coltun and Baker     Expires August 31 1993                  [Page 12]


     Internet Draft            OSPF Trap MIB                  February 1993
     
     
               Notation One (ASN.1), International Organization for
               Standardization.  International Standard 8824, (December,
               1987).
     
          [4]  Information processing systems - Open Systems
               Interconnection - Specification of Basic Encoding Rules
               for Abstract Notation One (ASN.1), International
               Organization for Standardization.  International Standard
               8825, (December, 1987).
     
          [5]  M.T. Rose and K. McCloghrie, Structure and Identification
               of Management Information for TCP/IP-based internets,
               Internet Working Group Request for Comments 1155.
               Network Information Center, SRI International, Menlo
               Park, California, (May, 1990).
     
          [6]  K. McCloghrie and M.T. Rose, Management Information Base
               for Network Management of TCP/IP-based internets,
               Internet Working Group Request for Comments 1156.
               Network Information Center, SRI International, Menlo
               Park, California, (May, 1990).
     
          [7]  J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
               Simple Network Management Protocol, Internet Working
               Group Request for Comments 1157.  Network Information
               Center, SRI International, Menlo Park, California, (May,
               1990).
     
          [8]  Rose, M.T.; McCloghrie, K.,eds. Concise MIB definitions.
               Internet Request for Comments 1212. Network Information
               Center, SRI International, Menlo Park, California, (1991 March).
     
          [9]  M.T. Rose (editor), Management Information Base for
               Network Management of TCP/IP-based internets, Internet
               Working Group Request for Comments 1213.  Network
               Information Center, SRI International, Menlo Park,
               California, (May, 1990).
     
          [10] M.T. Rose, A Convention for Defining Traps for
               use with the SNMP, Internet Request for Comments
               1215. Network Information Center, SRI International,
               Menlo Park, California, (March, 1991).
     
          [11] L. Steinberg, Techniques for Managing Asynchronously
               Generated Alerts.  Internet Request for Comments 1224.
               Network Information Center, SRI International, Menlo Park,
               California, (May, 1991).
     
     
     
     
     
     
     
     
     
     
     Coltun and Baker     Expires August 31 1993                  [Page 13]
     

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/