simultaneously set with respect to all other assignments specified in
the same message.
The receiving entity then sends to the originator of the received
message the GetResponse-PDU of identical form except that the value
of the error-status field of the generated message is noError and the
value of the error-index field is zero.
4.1.6. The Trap-PDU
The form of the Trap-PDU is:
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
The Trap-PDU is generated by a protocol entity only at the request of
the SNMP application entity. The means by which an SNMP application
entity selects the destination addresses of the SNMP application
entities is implementation-specific.
Upon receipt of the Trap-PDU, the receiving protocol entity presents
its contents to its SNMP application entity.
The significance of the variable-bindings component of the Trap-PDU
is implementation-specific.
Interpretations of the value of the generic-trap field are:
4.1.6.1. The coldStart Trap
A coldStart(0) trap signifies that the sending protocol entity is
reinitializing itself such that the agent's configuration or the
protocol entity implementation may be altered.
4.1.6.2. The warmStart Trap
A warmStart(1) trap signifies that the sending protocol entity is
reinitializing itself such that neither the agent configuration nor
the protocol entity implementation is altered.
4.1.6.3. The linkDown Trap
A linkDown(2) trap signifies that the sending protocol entity
recognizes a failure in one of the communication links represented in
the agent's configuration.
The Trap-PDU of type linkDown contains as the first element of its
variable-bindings, the name and value of the ifIndex instance for the
affected interface.
4.1.6.4. The linkUp Trap
A linkUp(3) trap signifies that the sending protocol entity
recognizes that one of the communication links represented in the
agent's configuration has come up.
The Trap-PDU of type linkUp contains as the first element of its
variable-bindings, the name and value of the ifIndex instance for the
affected interface.
4.1.6.5. The authenticationFailure Trap
An authenticationFailure(4) trap signifies that the sending protocol
entity is the addressee of a protocol message that is not properly
authenticated. While implementations of the SNMP must be capable of
generating this trap, they must also be capable of suppressing the
emission of such traps via an implementation-specific mechanism.
4.1.6.6. The egpNeighborLoss Trap
An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
the sending protocol entity was an EGP peer has been marked down and
the peer relationship no longer obtains.
The Trap-PDU of type egpNeighborLoss contains as the first element of
its variable-bindings, the name and value of the egpNeighAddr
instance for the affected neighbor.
4.1.6.7. The enterpriseSpecific Trap
A enterpriseSpecific(6) trap signifies that the sending protocol
entity recognizes that some enterprise-specific event has occurred.
The specific-trap field identifies the particular trap which
occurred.
5. Definitions
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetNextRequest-PDU ::=
[1]
IMPLICIT PDU
GetResponse-PDU ::=
[2]
IMPLICIT PDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
PDU ::=
SEQUENCE {
request-id
INTEGER,
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
},
error-index -- sometimes ignored
INTEGER,
variable-bindings -- values are sometimes ignored
VarBindList
}
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the
network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END
6. Acknowledgements
This memo was influenced by the IETF SNMP Extensions working
group:
Karl Auerbach, Epilogue Technology
K. Ramesh Babu, Excelan
Amatzia Ben-Artzi, 3Com/Bridge
Lawrence Besaw, Hewlett-Packard
Jeffrey D. Case, University of Tennessee at Knoxville
Anthony Chung, Sytek
James Davidson, The Wollongong Group
James R. Davin, MIT Laboratory for Computer Science
Mark S. Fedor, NYSERNet
Phill Gross, The MITRE Corporation
Satish Joshi, ACC
Dan Lynch, Advanced Computing Environments
Keith McCloghrie, The Wollongong Group
Marshall T. Rose, The Wollongong Group (chair)
Greg Satz, cisco
Martin Lee Schoffstall, Rensselaer Polytechnic Institute
Wengyik Yeong, NYSERNet
7. References
[1] Cerf, V., "IAB Recommendations for the Development of
Internet Network Management Standards", RFC1052, IAB,
April 1988.
[2] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based internets",
RFC1065, TWG, August 1988.
[3] McCloghrie, K., and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets",
RFC1066, TWG, August 1988.
[4] Cerf, V., "Report of the Second Ad Hoc Network Management
Review Group", RFC1109, IAB, August 1989.
[5] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
RFC1155, Performance Systems International and Hughes LAN
Systems, May 1990.
[6] McCloghrie, K., and M. Rose, "Management Information Base
for Network Management of TCP/IP-based Internets",
RFC1156, Hughes LAN Systems and Performance Systems
International, May 1990.
[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
"A Simple Network Management Protocol", Internet
Engineering Task Force working note, Network Information
Center, SRI International, Menlo Park, California,
March 1988.
[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
"A Simple Gateway Monitoring Protocol", RFC1028,
Proteon, University of Tennessee at Knoxville,
Cornell University, and Rensselaer Polytechnic
Institute, November 1987.
[9] Information processing systems - Open Systems
Interconnection, "Specification of Abstract Syntax
Notation One (ASN.1)", International Organization for
Standardization, International Standard 8824,
December 1987.
[10] 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.
[11] Postel, J., "User Datagram Protocol", RFC768,
USC/Information Sciences Institute, November 1980.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Jeffrey D. Case
SNMP Research
P.O. Box 8593
Knoxville, TN 37996-4800
Phone: (615) 573-1434
Email: case@CS.UTK.EDU
Mark Fedor
Performance Systems International
Rensselaer Technology Park
125 Jordan Road
Troy, NY 12180
Phone: (518) 283-8860
Email: fedor@patton.NYSER.NET
Martin Lee Schoffstall
Performance Systems International
Rensselaer Technology Park
165 Jordan Road
Troy, NY 12180
Phone: (518) 283-8860
Email: schoff@NISC.NYSER.NET
James R. Davin
MIT Laboratory for Computer Science, NE43-507
545 Technology Square
Cambridge, MA 02139
Phone: (617) 253-6020