rfc1215.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 507 行 · 第 1/2 页
TXT
507 行
Network Working Group M. Rose, Editor
Request for Comments: 1215 Performance Systems International
March 1991
A Convention for Defining Traps
for use with the SNMP
Status of this Memo
This memo suggests a straight-forward approach towards defining traps
used with the SNMP. Readers should note that the use of traps in the
Internet-standard network management framework is controversial. As
such, this memo is being put forward for information purposes.
Network management practitioners who employ traps are encouraged to
make use of this document. Practitioners who do not employ traps can
safely ignore this document.
This memo provides information for the Internet community. It does
not specify any standard. Distribution of this memo is unlimited.
Table of Contents
1. Historical Perspective ................................ 1
2. Defining Traps ........................................ 2
2.1 Mapping of the TRAP-TYPE macro ....................... 3
2.1.1 Mapping of the ENTERPRISE clause ................... 3
2.1.2 Mapping of the VARIABLES clause .................... 4
2.1.3 Mapping of the DESCRIPTION clause .................. 4
2.1.4 Mapping of the REFERENCE clause .................... 4
2.1.5 Mapping of the TRAP-TYPE value ..................... 4
2.2 Usage Examples ....................................... 5
2.2.1 Enterprise-specific Trap ........................... 5
2.2.2 Generic-Traps for use with the SNMP ................ 5
3. Acknowledgements ...................................... 7
4. References ............................................ 9
5. Security Considerations................................ 9
6. Author's Address....................................... 9
1. Historical Perspective
As reported in RFC 1052, IAB Recommendations for the Development of
Internet Network Management Standards [1], a two-prong strategy for
network management of TCP/IP-based internets was undertaken. In the
short-term, the Simple Network Management Protocol (SNMP), defined in
RFC 1067, was to be used to manage nodes in the Internet community.
In the long-term, the use of the OSI network management framework was
be examined. Two documents were produced to define the management
SNMP Working Group [Page 1]
RFC 1215 Convention for Defining Traps March 1991
information: RFC 1065, which defined the Structure of Management
Information (SMI), and RFC 1066, which defined the Management
Information Base (MIB). Both of these documents were designed so as
to be compatible with both the SNMP and the OSI network management
framework.
This strategy was quite successful in the short-term: Internet-based
network management technology was fielded, by both the research and
commercial communities, within a few months. As a result of this,
portions of the Internet community became network manageable in a
timely fashion.
As reported in RFC 1109, Report of the Second Ad Hoc Network
Management Review Group [2], the requirements of the SNMP and the OSI
network management frameworks were more different than anticipated.
As such, the requirement for compatibility between the SMI/MIB and
both frameworks was suspended. This action permitted the operational
network management framework, based on the SNMP, to respond to new
operational needs in the Internet community by producing MIB-II.
In May of 1990, the core documents were elevated to "Standard
Protocols" with "Recommended" status. As such, the Internet-standard
network management framework consists of: Structure and
Identification of Management Information for TCP/IP-based internets,
RFC 1155 [3], which describes how managed objects contained in the
MIB are defined; Management Information Base for Network Management
of TCP/IP-based internets, which describes the managed objects
contained in the MIB, RFC 1156 [4]; and, the Simple Network
Management Protocol, RFC 1157 [5], which defines the protocol used to
manage these objects.
2. Defining Traps
Due to its initial requirement to be protocol-independent, the
Internet-standard SMI does not provide a means for defining traps.
Instead, the SNMP defines a few standardized traps and provides a
means for management enterprises to transmit enterprise-specific
traps.
However, with the introduction of experimental MIBs, some of which
have a need to define experiment-specific traps, a convenient means
of defining traps is desirable. The TRAP-TYPE macro is suggested for
this purpose:
IMPORTS
ObjectName
FROM RFC1155-SMI;
SNMP Working Group [Page 2]
RFC 1215 Convention for Defining Traps March 1991
TRAP-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= "ENTERPRISE" value
(enterprise OBJECT IDENTIFIER)
VarPart
DescrPart
ReferPart
VALUE NOTATION ::= value (VALUE INTEGER)
VarPart ::=
"VARIABLES" "{" VarTypes "}"
| empty
VarTypes ::=
VarType | VarTypes "," VarType
VarType ::=
value (vartype ObjectName)
DescrPart ::=
"DESCRIPTION" value (description DisplayString)
| empty
ReferPart ::=
"REFERENCE" value (reference DisplayString)
| empty
END
It must be emphasized however, that the use of traps is STRONGLY
discouraged in the Internet-standard Network Management Framework.
The TRAP-TYPE macro is intended to allow concise definitions of
existing traps, not to spur the definition of new traps.
2.1. Mapping of the TRAP-TYPE macro
It should be noted that the expansion of the TRAP-TYPE macro is
something which conceptually happens during implementation and not
during run-time.
2.1.1. Mapping of the ENTERPRISE clause
The ENTERPRISE clause, which must be present, defines the management
enterprise under whose registration authority this trap is defined
(for a discussion on delegation of registration authority, see the
SMI [3]). This value is placed inside the enterprise field of the
SNMP Trap-PDU.
By convention, if the value of the ENTERPRISE clause is
SNMP Working Group [Page 3]
RFC 1215 Convention for Defining Traps March 1991
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
as defined in MIB-II [7], then instead of using this value, the value
of sysObjectID is placed in the enterprise field of the SNMP Trap-
PDU. This provides a simple means of using the TRAP-TYPE macro to
represent the existing standard SNMP traps; it is not intended to
provide a means to define additional standard SNMP traps.
2.1.2. Mapping of the VARIABLES clause
The VARIABLES clause, which need not be present, defines the ordered
sequence of MIB objects which are contained within every instance of
the trap type. Each variable is placed, in order, inside the
variable-bindings field of the SNMP Trap-PDU. Note that at the
option of the agent, additional variables may follow in the
variable-bindings field.
However, if the value of the ENTERPRISE clause is
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
as defined in MIB-II [7], then the introduction of additional
variables must not result in the serialized SNMP Message being larger
than 484 octets.
2.1.3. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which need not be present, contains a textual
definition of the trap type. Note that in order to conform to the
ASN.1 syntax, the entire value of this clause must be enclosed in
double quotation marks, although the value may be multi-line.
Further, note that if the MIB module does not contain a textual
description of the trap elsewhere then the DESCRIPTION clause must be
present.
2.1.4. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a textual
cross-reference to a trap, event, or alarm, defined in some other MIB
module. This is useful when de-osifying a MIB produced by some other
organization.
2.1.5. Mapping of the TRAP-TYPE value
The value of an invocation of the TRAP-TYPE macro is the (integer)
number which is uniquely assigned to the trap by the registration
authority indicated by the ENTERPRISE clause. This value is placed
SNMP Working Group [Page 4]
RFC 1215 Convention for Defining Traps March 1991
inside the specific-trap field of the SNMP Trap-PDU, and the
generic-trap field is set to "enterpriseSpecific(6)".
By convention, if the value of the ENTERPRISE clause is
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
as defined in MIB-II [7], then the value of an invocation of the
TRAP-TYPE macro is placed inside the generic-trap field of the SNMP
Trap-PDU, and the specific-trap field is set to 0. This provides a
simple means of using the TRAP-TYPE macro to represent the existing
standard SNMP traps; it is not intended to provide a means to define
additional standard SNMP traps.
2.2. Usage Examples
2.2.1. Enterprise-specific Trap
Consider a simple example of an enterprise-specific trap that is sent
when a communication link failure is encountered:
myEnterprise OBJECT IDENTIFIER ::= { enterprises 9999 }
myLinkDown TRAP-TYPE
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?