RFC 1441 Introduction to SNMPv2 April 1993
1. Introduction
The purpose of this document is to provide an overview of
version 2 of the Internet-standard Network Management
Framework, termed the SNMP version 2 framework (SNMPv2). This
framework is derived from the original Internet-standard
Network Management Framework (SNMPv1), which consists of these
three documents:
RFC 1155 [1] which defines the Structure of Management
Information (SMI), the mechanisms used for describing and
naming objects for the purpose of management.
RFC 1212 [2] which defines a more concise description
mechanism, which is wholly consistent with the SMI.
RFC 1157 [3] which defines the Simple Network Management
Protocol (SNMP), the protocol used for network access to
managed objects.
For information on coexistence between SNMPv1 and SNMPv2,
consult [4].
Case, McCloghrie, Rose & Waldbusser [Page 2]

RFC 1441 Introduction to SNMPv2 April 1993
2. Components of the SNMPv2 Framework
A network management system contains: several (potentially
many) nodes, each with a processing entity, termed an agent,
which has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management
stations. Operations of the protocol are carried out under an
administrative framework which defines both authentication and
authorization policies.
Network management stations execute management applications
which monitor and control network elements. Network elements
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to their
management information.
2.1.Structure of Management Information
Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the
Management Information Base (MIB). Collections of related
objects are defined in MIB modules. These modules are written
using a subset of OSI's Abstract Syntax Notation One (ASN.1)
[5]. It is the purpose of the Structure of Management
Information for SNMPv2 document [6] to define that subset.
The SMI is divided into three parts: module definitions,
object definitions, and, trap definitions.
(1) Module definitions are used when describing information
modules. An ASN.1 macro, MODULE-IDENTITY, is used to
concisely convey the semantics of an information module.
(2) Object definitions are used when describing managed
objects. An ASN.1 macro, OBJECT-TYPE, is used to
concisely convey the syntax and semantics of a managed
object.
(3) Notification definitions are used when describing
unsolicited transmissions of management information. An
ASN.1 macro, NOTIFICATION-TYPE, is used to concisely
convey the syntax and semantics of a notification.
Case, McCloghrie, Rose & Waldbusser [Page 3]

RFC 1441 Introduction to SNMPv2 April 1993
2.2. Textual Conventions
When designing a MIB module, it is often useful to new define
types similar to those defined in the SMI. In comparison to a
type defined in the SMI, each of these new types has a
different name, a similar syntax, but a more precise
semantics. These newly defined types are termed textual
conventions, and are used for the convenience of humans
reading the MIB module. It is the purpose of the Textual
Conventions for SNMPv2 document [7] to define the initial set
of textual conventions available to all MIB modules.
Objects defined using a textual convention are always encoded
by means of the rules that define their primitive type.
However, textual conventions often have special semantics
associated with them. As such, an ASN.1 macro, TEXTUAL-
CONVENTION, is used to concisely convey the syntax and
semantics of a textual convention.
2.3. Protocol Operations
The management protocol provides for the exchange of messages
which convey management information between the agents and the
management stations. The form of these messages is a message
"wrapper" which encapsulates a Protocol Data Unit (PDU). The
form and meaning of the "wrapper" is determined by an
administrative framework which defines both authentication and
authorization policies.
It is the purpose of the Protocol Operations for SNMPv2
document [8] to define the operations of the protocol with
respect to the sending and receiving of the PDUs.
2.4. Transport Mappings
The management protocol, version 2 of the Simple Network
Management Protocol, may be used over a variety of protocol
suites. It is the purpose of the Transport Mappings for
SNMPv2 document [9] to define how the SNMPv2 maps onto an
initial set of transport domains. Other mappings may be
defined in the future.
Case, McCloghrie, Rose & Waldbusser [Page 4]

RFC 1441 Introduction to SNMPv2 April 1993
Although several mappings are defined, the mapping onto UDP is
the preferred mapping. As such, to provide for the greatest
level of interoperability, systems which choose to deploy
other mappings should also provide for proxy service to the
UDP mapping.
2.5. Protocol Instrumentation
It is the purpose of the Management Information Base for
SNMPv2 document [10] to define managed objects which describe
the behavior of a SNMPv2 entity. The Manager-to-Manager MIB
document [11] defines an initial set of managed objects which
describe the behavior of a SNMPv2 entity which acts in a
manager role. It is expected that extensions to this MIB will
be defined in the future.
2.6. Administrative Framework
It is the purpose of the Administrative Model for SNMPv2
document [12] to define the behavior of a SNMPv2 party - a
conceptual, virtual execution context whose operation is
restricted (for security or other purposes) to an
administratively defined subset of all possible operations of
a particular SNMPv2 entity.
Associated with each SNMPv2 party is a single authentication
protocol and a single privacy protocol. It is the purpose of
the Security Protocols for SNMPv2 document [13] to define
those protocols.
The Party MIB for SNMPv2 document [14] defines managed objects
which correspond to the properties associated with a SNMPv2
party.
2.7. Conformance Statements
It may be useful to define the acceptable lower-bounds of
implementation, along with the actual level of implementation
achieved. It is the purpose of the Conformance Statements for
SNMPv2 document [15] to define the notation used for these
purposes. There are two kinds of notations:
Case, McCloghrie, Rose & Waldbusser [Page 5]

RFC 1441 Introduction to SNMPv2 April 1993
(1) Compliance statements are used when describing
requirements for agents with respect to object
definitions. An ASN.1 macro, MODULE-COMPLIANCE, is used
to concisely convey such requirements.
(2) Capability statements are used when describing
capabilities of agents with respect to object
definitions. An ASN.1 macro, AGENT-CAPABILITIES, is used
to concisely convey such capabilities.
Finally, collections of related objects are grouped together
to form a unit of conformance. An ASN.1 macro, OBJECT-GROUP,
is used to concisely convey the syntax and semantics of a
group.
Case, McCloghrie, Rose & Waldbusser [Page 6]

RFC 1441 Introduction to SNMPv2 April 1993
3.Acknowledgements
The SNMPv2 framework is based on the outstanding technical
direction pioneered by the original authors of the SGMP: James
R. (Chuck) Davin, of the MIT Laboratory for Computer Science,
Mark S. Fedor, of Performance Systems International, Inc.,
Martin L. Schoffstall, also of PSI, and Jeffrey D. Case.
Since the invention of the SGMP in 1987, many individuals have
devoted much energy toward creating the unprecedented success
of the Internet-standard Network Management Framework. As
such, the list of people worthy of acknowledgement is too
great to enumerate here.
However, in retrospect, it seems clear that the concepts in
the original architecture, as envisioned by Chuck Davin, have
provided the basis for the success of the current framework.
We hope that the SNMPv2 framework will be able to successfully
build on this work.
Finally, the comments of the SNMP version 2 working group are
gratefully acknowledged:
Beth Adams, Network Management Forum
Steve Alexander, INTERACTIVE Systems Corporation
David Arneson, Cabletron Systems
Toshiya Asaba
Fred Baker, ACC
Jim Barnes, Xylogics, Inc.
Brian Bataille
Andy Bierman, SynOptics Communications, Inc.
Uri Blumenthal, IBM Corporation
Fred Bohle, Interlink
Jack Brown
Theodore Brunner, Bellcore
Stephen F. Bush, GE Information Services
Jeffrey D. Case, University of Tennessee, Knoxville
John Chang, IBM Corporation
Szusin Chen, Sun Microsystems
Robert Ching
Chris Chiotasso, Ungermann-Bass
Bobby A. Clay, NASA/Boeing
John Cooke, Chipcom
Tracy Cox, Bellcore
Juan Cruz, Datability, Inc.
Case, McCloghrie, Rose & Waldbusser [Page 7]