Network Working Group                                  J. Case
          Request for Comments: 1441                 SNMP Research, Inc.
                                                           K. McCloghrie
                                                      Hughes LAN Systems
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                              Carnegie Mellon University
                                                              April 1993

Introduction to version 2 of the

Internet-standard Network Management Framework

Status of this Memo

This RFC specifes an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Table of Contents

1 Introduction
2 Components of the SNMPv2 Framework
2.1 Structure of Management Information
2.2 Textual Conventions
2.3 Protocol Operations
2.4 Transport Mappings
2.5 Protocol Instrumentation
2.6 Administrative Framework
2.7 Conformance Statements
3 Acknowledgements
4 References
5 Security Considerations
6 Authors' Addresses

          Case, McCloghrie, Rose & Waldbusser                   [Page 1]

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]

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]

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]

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]

(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]

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]

David Cullerot, Cabletron Systems
Cathy Cunningham, Microcom
James R. (Chuck) Davin, Bellcore
Michael Davis, Clearpoint
Mike Davison, FiberCom
Cynthia DellaTorre, MITRE
Taso N. Devetzis, Bellcore
Manual Diaz, DAVID Systems, Inc.
Jon Dreyer, Sun Microsystems
David Engel, Optical Data Systems
Mike Erlinger, Lexcel
Roger Fajman, NIH
Daniel Fauvarque, Sun Microsystems
Karen Frisa, CMU
Shari Galitzer, MITRE
Shawn Gallagher, Digital Equipment Corporation Richard Graveman, Bellcore
Maria Greene, Xyplex, Inc.
Michel Guittet, Apple
Robert Gutierrez, NASA
Bill Hagerty, Cabletron Systems
Gary W. Haney, Martin Marietta Energy Systems Patrick Hanil, Nokia Telecommunications
Matt Hecht, SNMP Research, Inc.
Edward A. Heiner, Jr., Synernetics Inc.
Susan E. Hicks, Martin Marietta Energy Systems Geral Holzhauer, Apple
John Hopprich, DAVID Systems, Inc.
Jeff Hughes, Hewlett-Packard
Robin Iddon, Axon Networks, Inc.
David Itusak
Kevin M. Jackson, Concord Communications, Inc. Ole J. Jacobsen, Interop Company
Ronald Jacoby, Silicon Graphics, Inc.
Satish Joshi, SynOptics Communications, Inc.
Frank Kastenholz, FTP Software
Mark Kepke, Hewlett-Packard
Ken Key, SNMP Research, Inc.
Zbiginew Kielczewski, Eicon
Jongyeoi Kim
Andrew Knutsen, The Santa Cruz Operation
Michael L. Kornegay, VisiSoft
Deirdre C. Kostik, Bellcore
Cheryl Krupczak, Georgia Tech
Mark S. Lewis, Telebit

          Case, McCloghrie, Rose & Waldbusser                   [Page 8]

David Lin
David Lindemulder, AT&T/NCR
Ben Lisowski, Sprint
David Liu, Bell-Northern Research
John Lunny, The Wollongong Group
Robert C. Lushbaugh Martin, Marietta Energy Systems Michael Luufer, BBN
Carl Madison, Star-Tek, Inc.
Keith McCloghrie, Hughes LAN Systems
Evan McGinnis, 3Com Corporation
Bill McKenzie, IBM Corporation
Donna McMaster, SynOptics Communications, Inc. John Medicke, IBM Corporation
Doug Miller, Telebit
Dave Minnich, FiberCom
Mohammad Mirhakkak, MITRE
Rohit Mital, Protools
George Mouradian, AT&T Bell Labs
Patrick Mullaney, Cabletron Systems
Dan Myers, 3Com Corporation
Rina Nathaniel, Rad Network Devices Ltd.
Hien V. Nguyen, Sprint
Mo Nikain
Tom Nisbet
William B. Norton, MERIT
Steve Onishi, Wellfleet Communications, Inc.
David T. Perkins, SynOptics Communications, Inc. Carl Powell, BBN
Ilan Raab, SynOptics Communications, Inc.
Richard Ramons, AT&T
Venkat D. Rangan, Metric Network Systems, Inc. Louise Reingold, Sprint
Sam Roberts, Farallon Computing, Inc.
Kary Robertson, Concord Communications, Inc.
Dan Romascanu, Lannet Data Communications Ltd. Marshall T. Rose, Dover Beach Consulting, Inc. Shawn A. Routhier, Epilogue Technology Corporation Chris Rozman
Asaf Rubissa, Fibronics
Jon Saperia, Digital Equipment Corporation
Michael Sapich
Mike Scanlon, Interlan
Sam Schaen, MITRE
John Seligson, Ultra Network Technologies
Paul A. Serice, Corporation for Open Systems

          Case, McCloghrie, Rose & Waldbusser                   [Page 9]

Chris Shaw, Banyan Systems
Timon Sloane
Robert Snyder, Cisco Systems
Joo Young Song
Roy Spitier, Sprint
Einar Stefferud, Network Management Associates John Stephens, Cayman Systems, Inc.
Robert L. Stewart, Xyplex, Inc. (chair)
Kaj Tesink, Bellcore
Dean Throop, Data General
Ahmet Tuncay, France Telecom-CNET
Maurice Turcotte, Racal Datacom
Warren Vik, INTERACTIVE Systems Corporation
Yannis Viniotis
Steven L. Waldbusser, Carnegie Mellon Universitty Timothy M. Walden, ACC
Alice Wang, Sun Microsystems
James Watt, Newbridge
Luanne Waul, Timeplex
Donald E. Westlake III, Digital Equipment Corporation Gerry White
Bert Wijnen, IBM Corporation
Peter Wilson, 3Com Corporation
Steven Wong, Digital Equipment Corporation
Randy Worzella, IBM Corporation
Daniel Woycke, MITRE
Honda Wu
Jeff Yarnell, Protools
Chris Young, Cabletron
Kiho Yum, 3Com Corporation

          Case, McCloghrie, Rose & Waldbusser                  [Page 10]

4. References

[1] Rose, M., and McCloghrie, K., "Structure and
Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.

[2] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16, RFC 1212, March 1991.

[3] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990.

[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1452, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[5] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).

[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[8] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

          Case, McCloghrie, Rose & Waldbusser                  [Page 11]

[9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1449, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1450, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Manager-to-Manager Management Information Base", RFC 1451, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[12] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993.

[13] Galvin, J., and McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993.

[14] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, April 1993.

[15] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

          Case, McCloghrie, Rose & Waldbusser                  [Page 12]

5. Security Considerations

Security issues are not discussed in this memo.

6. Authors' Addresses

Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US

Phone: +1 615 573 1434
Email: case@snmp.com

Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
US

Phone: +1 415 966 7934
Email: kzm@hls.com

Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US

Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us

Steven Waldbusser
Carnegie Mellon University
4910 Forbes Ave
Pittsburgh, PA 15213
US

Phone: +1 412 268 6628
Email: waldbusser@cmu.edu

          Case, McCloghrie, Rose & Waldbusser                  [Page 13]