RFC 1155
`
`SMI
`
`May 1990
`
`{ atEntry }
`
`and specifying, using a protocol-specific mechanism,
`instance
`
`the object
`
`{ atNetAddress } = {
`
`internet “10.0.0.52" }
`
`refers to all instances of entries in the table for which the
`
`associated atNetAddress value is { internet “10.0.0.52" }.
`
`Each management protocol must provide a mechanism for accessing
`simple (non—aggregate) object types.
`Each management protocol
`specifies whether or not it supports access to aggregate object
`types. Further,
`the protocol must specify which instances are
`"returned" when an object type/instance pairing refers to more than
`one instance of a type.
`
`To afford support for a variety of management protocols, all
`information by which instances of a given object type may be usefully
`distinguished, one from another,
`is represented by instances of
`object types defined in the MIB.
`
`4.3. Macros for Managed Objects
`
`In order to facilitate the use of tools for processing the definition
`of the MIB,
`the OBJECT-TYPE macro may be used. This macro permits
`the key aspects of an object type to be represented in a formal way.
`
`OBJECT-TYPE MACRO
`BEGIN
`TYPE NOTATION
`
`type (TYPE Objectsyntax)
`"SYNTAX"
`"ACCESS" Access
`"STATUS" Status
`
`VALUE NOTATION ::= value (VALUE ObjectName)
`
`Access
`
`"read-only"
`|
`"read—write"
`|
`"write—on1y"
`| "not—accessible"
`Status ::= "mandatory"
`| "optional"
`| "obsolete"
`
`END
`
`Given the object types defined earlier, we might
`following definitions being present in the MIB:
`
`imagine the
`
`atIndex OBJECT-TYPE
`
`Rose & Mccloghrie
`
`[Page 14]
`
`1232
`
`SAP 1002 (Part 4 of 4)
`CBM ofU.S. Patent No. 8,037,158
`
`1232
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`SYNTAX
`ACCESS
`
`INTEGER
`read-write
`
`STATUS mandatory
`::= { atEntry 1
`}
`
`atPhysAddress OBJECT—TYPE
`SYNTAX OCTET STRING
`ACCESS
`read-write
`
`STATUS mandatory
`::= { atEntry 2
`}
`
`atNetAddress OBJECT-TYPE
`SYNTAX NetworkAddress
`ACCESS
`read-write
`STATUS mandatory
`-:= { atEntry 3
`}
`
`atEntry OBJECT-TYPE
`SYNTAX AtEntry
`ACCESS
`read-write
`
`STATUS mandatory
`::= { atTable 1 }
`
`atTable OBJECT—TYPE
`
`SEQUENCE OF AtEntry
`SYNTAX
`read-write
`ACCESS
`STATUS mandatory
`::= { at 1 }
`
`AtEntry ::= SEQUENCE {
`atlndex
`INTEGER,
`atPhysAddress
`OCTET STRING,
`atNetAddress
`NetworkAddress
`
`}
`
`The first five definitions describe object types, relating, for
`example,
`the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
`atEntry 1 }.
`In addition,
`the syntax of this object is defined
`(INTEGER) along with the access permitted (read-write) and status
`(mandatory).
`The sixth definition describes an ASN.1 type called
`AtEntry.
`
`Rose & Mccloghrie
`
`[Page 15]
`
`1233
`
`1233
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`5. Extensions to the MIB
`
`Every Internet-standard MIB document obsoletes all previous such
`documents.
`The portion of a name,
`termed the tail,
`following the
`OBJECT IDENTIFIER
`
`{ mgmt version-number }
`
`used to name objects shall remain unchanged between versions.
`versions may:
`
`New
`
`(1) declare old object types obsolete (if necessary). but n0t
`delete their names;
`
`(2) augment the definition of an object type corresponding to a
`list by appending non-aggregate object types to the object types
`in the list; or,
`
`(3) define entirely new object types.
`
`New versions may not:
`
`(1) change the semantics of any previously defined object without
`changing the name of that object.
`
`These rules are important because they admit easier support for
`multiple versions of the Internet-standard MIB.
`In particular,
`semantics associated with the tail of a name remain constant
`
`the
`
`throughout different versions of the MIB. Because multiple versions
`of the MIB may thus coincide in "tail—space," implementations
`supporting multiple versions of the MIB can be vastly simplified.
`
`However, as a consequence, a management agent might return an
`instance corresponding to a superset of the expected object type.
`Following the principle of robustness,
`in this exceptional case, a
`manager should ignore any additional information beyond the
`definition of the expected object type. However,
`the robustness
`principle requires that one exercise care with respect to control
`actions:
`if an instance does not have the same syntax as its
`In both
`expected object type,
`then those control actions must fail.
`the monitoring and control cases,
`the name of an object returned by
`an operation must be identical to the name requested by an operation.
`
`Rose & Mccloghrie
`
`[Page 16]
`
`1234
`
`1234
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`6. Definitions
`
`RFC1l55—SMI DEFINITIONS ::= BEGIN
`
`EXPORTS -— EVERYTHING
`
`internet, directory, mgmt,
`experimental, private, enterprises,
`OBJECT—TYPE, ObjectName, Objectsyntax, Simplesyntax,
`Applicationsyntax, NetworkAddress,
`IpAddress,
`Counter, Gauge, TimeTicks, Opaque;
`
`-— the path to the root
`
`internet
`
`OBJECT IDENTIFIER ::= {
`
`iso org(3) dod(6)
`
`1
`
`}
`
`directory
`
`OBJECT IDENTIFIER ::= {
`
`internet 1
`
`mgmt
`
`OBJECT IDENTIFIER ::= { internet 2
`
`experimental OBJECT IDENTIFIER ::= {
`
`internet 3
`
`private
`enterprises
`
`internet 4
`OBJECT IDENTIFIER ::= {
`OBJECT IDENTIFIER -
`=
`{ private 1
`
`}
`
`}
`
`}
`
`}
`
`}
`
`-- definition of object types
`
`OBJECT—TYPE MACRO
`BEGIN
`TYPE NOTATION
`
`type (TYPE Objectsyntax)
`"SYNTAX"
`"ACCESS" Access
`"STATUS" Status
`
`VALUE NOTATION ::= value (VALUE ObjectName)
`
`Access
`
`Status
`
`“read-only"
`| "read-write"
`| "write-only"
`| "not—accessible"
`= "mandatory"
`I "optional"
`I "obsolete"
`
`END
`
`-- names of objects in the MIB
`
`ObjectName ::=
`OBJECT IDENTIFIER
`
`Rose & Mccloghrie
`
`[Page 17]
`
`1235
`
`1235
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`-- syntax of objects in the MIB
`
`=
`
`Objectsyntax
`CHOICE {
`simple
`Simplesyntax,
`
`-- note that simple SEQUENCES are not directly
`—- mentioned here to keep things simple (i.e.,
`—- prevent mis-use). However, application—wide
`-- types which are IMPLICITly encoded simple
`-- SEQUENCES may appear in the following CHOICE
`
`application—wide
`Applicationsyntax
`
`}
`
`=
`
`Simplesyntax
`CHOICE {
`number
`INTEGER,
`
`string
`OCTET STRING,
`
`object
`OBJECT IDENTIFIER,
`
`empty
`NULL
`
`}
`
`Applicationsyntax
`CHOICE {
`address
`NetworkAddress,
`
`=
`
`counter
`Counter,
`
`gauge
`Gauge,
`
`ticks
`TimeTicks,
`
`arbitrary
`Opaque
`
`Rose & Mccloghrie
`
`[Page 18]
`
`1236
`
`1236
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`—- other application-wide types, as they are
`—- defined, will be added here
`}
`
`—- application-wide types
`
`NetworkAddress
`
`CHOICE {
`internet
`IpAddress
`
`}
`
`IpAddress ::=
`-— in network-byte order
`[APPLICATION 0]
`IMPLICIT OCTET STRING (SIZE (4))
`
`::=
`Counter
`[APPLICATION 1]
`IMPLICIT INTEGER (O..4294967295)
`
`Gauge ::=
`[APPLICATION 2]
`IMPLICIT INTEGER (O..4294967295)
`
`TimeTicks ::=
`[APPLICATION 3]
`IMPLICIT INTEGER (0..4294967295)
`
`Opaque ::=
`[APPLICATION 4]
`IMPLICIT OCTET STRING
`
`-- arbitrary ASN.1 value,
`--
`"double-wrapped"
`
`END
`
`Rose & Mccloghrie
`
`[Page 19]
`
`1237
`
`1237
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`7. Acknowledgements
`
`This memo was influenced by three sets of contributors to earlier
`drafts:
`
`First, Lee Labarre of the MITRE Corporation, who as author of the
`NETMAN SMI
`[4], presented the basic roadmap for the SMI.
`
`individuals who provided valuable comments on this
`Second, several
`memo prior to its initial distribution:
`
`James R. Davin, Proteon
`Mark S. Fedor, NYSERNet
`Craig Partridge, BBN Laboratories
`Martin Lee Schoffstall, Rensselaer Polytechnic Institute
`Wengyik Yeong, NYSERNet
`
`Third,
`
`the IETF MIB working group:
`
`Karl Auerbach, Epilogue Technology
`K. Ramesh Babu, Excelan
`Lawrence Besaw, Hewlett-Packard
`Jeffrey D. Case, University of Tennessee at Knoxville
`James R. Davin, Proteon
`Mark S. Fedor, NYSERNet
`Robb Foster, BBN
`Phill Gross, The MITRE Corporation
`Bent Torp Jensen, Convergent Technology
`Lee Labarre, The MITRE Corporation
`Dan Lynch, Advanced Computing Environments
`Keith McCloghrie, The Wollongong Group
`Dave Mackie, 3Com/Bridge
`Craig Partridge, BBN (chair)
`Jim Robertson, 3Com/Bridge
`Marshall T. Rose, The Wollongong Group
`Greg Satz, cisco
`Martin Lee Schoffstall, Rensselaer Polytechnic Institute
`Lou Steinberg,
`IBM
`Dean Throop, Data General
`Unni Warrier, Unisys
`
`Rose & Mccloghrie
`
`[Page 20]
`
`1238
`
`1238
`
`

`
`RFC 1155
`
`8. References
`
`SMI
`
`May 1990
`
`[1]
`
`[2]
`
`[3]
`
`[4]
`
`[5]
`
`[6]
`
`[7]
`
`Information processing systems - Open systems Interconnection,
`“specification of Abstract Syntax Notation One
`(ASN.1)",
`International Organization for Standardization, International
`Standard 8824, December 1987.
`
`"Management Information Base for
`Mccloghrie K., and M. Rose,
`Network Management of TCP/IP-based Internets", RFC 1156,
`Performance Systems International and Hughes LAN Systems, May
`1990.
`
`Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
`Network Management Protocol", RFC 1157, University of Tennessee
`at Knoxville, Performance Systems International, Performance
`Systems International, and the MIT Laboratory for Computer
`Science, May 1990.
`
`LaBarre, L.,
`"Structure and Identification of Management
`Information for the Internet",
`Internet Engineering Task Force
`SRI International,
`working note, Network Information Center,
`Menlo Park, California, April 1988.
`
`Cerf, V.,
`"IAB Recommendations for the Development of Internet
`Network Management Standards", RFC 1052,
`IAB, April 1988.
`
`Cerf, V.,
`"Report of the Second Ad Hoc Network Management Review
`Group", RFC 1109,
`IAB, August 1989.
`
`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.
`
`Security Considerations
`
`Security issues are not discussed in this memo.
`
`Rose & Mccloghrie
`
`[Page 21]
`
`1239
`
`1239
`
`

`
`RFC 1155
`
`SMI
`
`May 1990
`
`Authors’ Addresses
`
`Marshall T. Rose
`PSI,
`Inc.
`PSI California Office
`P.O. Box 391776
`Mountain View, CA 94039
`
`Phone:
`
`(415) 961-3380
`
`EMai1: mrose@PSI.COM
`
`Keith McCloghrie
`The Wollongong Group
`1129 San Antonio Road
`Palo Alto, CA 04303
`
`Phone:
`
`(415) 962-7160
`
`EMai1:
`
`sytek!kzm@HPLABS.HP.COM
`
`Rose & Mccloghrie
`
`[Page 22]
`
`1240
`
`1240
`
`

`
`Network Working Group
`Request for Comments:
`RFC 1098
`Obsoletes:
`
`1157
`
`J. Case
`SNMP Research
`M. Fedor
`
`Performance Systems International
`M. Schoffstall
`
`Performance Systems International
`J. Davin
`MIT Laboratory for Computer Science
`May 1990
`
`A simple Network Management Protocol
`
`(SNMP)
`
`Table of Contents
`
`CO\lO\O\UIU'lU1t\)l\)
`
`Status of this Memo
`Introduction
`The SNMP Architecture
`Goals of the Architecture
`Elements of the Architecture
`.1
`Scope of Management Information
`. ..
`.
`.
`.
`.
`.
`.
`.
`Representation of Management Information .
`Operations Supported on Management Information .....
`Form and Meaning of Protocol Exchanges .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. ..
`Definition of Administrative Relationships .
`.
`.
`.
`.
`.
`. ..
`Form and Meaning of References to Managed Objects
`.I Resolution of Ambiguous MIB References .
`.
`.
`.
`.
`.
`.
`.
`.2 Resolution of References across MIB Versions .
`.
`.
`.3
`Identification of Object Instances
`.1 ifTable Object Type Names
`.
`.
`.
`.
`.
`.
`atTable Object Type Names
`.
`.
`.
`.
`.
`.
`ipAddrTable Object Type Names
`.
`.
`ipRoutingTable Object Type Names
`tcpConnTable Object Type Names
`6
`3
`egpNeighTable Object Type Names
`Proto
`col Specification .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Elements of Procedure
`.1
`Common Constructs
`
`. ..
`. ..
`
`. ..
`. ..
`. ..
`. ..
`
`. ..
`
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`O'\O\O'\O\O\0'\O'\O\0\U'Ivl>LaJl\)
`
`wwwww
`
`0'\U'|n¥>UJI\)
`
`»¥>obo#r¥>>¥>v#oJ>ol>»#o¥>>¥>r§>J>uJkAJUJUJkAJuJl»J(AJhJLAJu!l»Jl»JUJUJUJUJk»Jl\JH
`
`
`
`I-‘!—‘|-‘I-‘I-‘I-‘I-‘F-‘I-‘I-‘I-‘I-‘I\)t\)t\Jt\)t\)t\)[\Jt\Jt\)t\.)t\)l\J[\)l\)l\)K\)l—‘
`
`.
`.
`.
`.
`.
`.
`.
`.
`The GetRequest-PDU .
`.
`.
`.
`.
`The GetNextRequest-PDU .
`.1 Example of Table Traversal
`The GetResponse-PDU .
`.
`.
`.
`.
`.
`.
`.
`The SetRequest-PDU .
`.
`.
`.
`.
`.
`.
`.
`.
`The Trap—PDU .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.1
`The coldstart Trap .
`.
`.
`.
`.
`.
`.
`The warmstart Trap .
`.
`.
`.
`.
`.
`.
`The 1inkDown Trap .
`.
`.
`.
`.
`.
`.
`.
`The linkUp Trap .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`ol>lIJN
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`O\O\O\O\O\U1s§U)LAJt\)
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`. ..
`. ..
`. ..
`. ..
`. ..
`. ..
`. ..
`. ..
`. ..
`. ..
`
`Case,
`
`Fedor, Schoffstall, & Davin
`
`[Page 1]
`
`1241
`
`1241
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`4.1.6.5 The authenticationFailure Trap .
`4.1.6.6 The egpNeighborLoss Trap .
`.
`.
`.
`.
`.
`.
`4.1.6.7 The enterprisespecific Trap .
`.
`.
`.
`5. Definitions .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`6. Acknowledgements .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`7. References .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`8. Security Considerations .
`9. Authors’ Addresses .
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`. ..
`. ..
`. ..
`. ..
`. ..
`. ..
`
`. ..
`. ..
`
`28
`28
`29
`30
`33
`34
`
`35
`35
`
`1. Status of this Memo
`
`This RFC is a re-release of RFC 1098, with a changed "Status of this
`Memo" section plus a few minor typographical corrections. This memo
`defines a simple protocol by which management
`information for a
`network element may be inspected or altered by logically remote
`users.
`In particular,
`together with its companion memos which
`describe the structure of management information along with the
`management information base,
`these documents provide a simple,
`workable architecture and system for managing TCP/IP-based internets
`and in particular the Internet.
`
`The Internet Activities Board recommends that all IP and TCP
`
`implementations be network manageable. This implies implementation
`of the Internet MIB (RFC-1156) and at least one of the two
`recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
`It should be noted that, at this time, SNMP is a full Internet
`standard and CMOT is a draft standard.
`See also the Host and Gateway
`Requirements RFCs for more specific information on the applicability
`of this standard.
`
`Please refer to the latest edition of the "IAB Official Protocol
`Standards" RFC for current information on the state and status of
`standard Internet protocols.
`
`Distribution of this memo is unlimited.
`
`2.
`
`Introduction
`
`IAB Recommendations for the Development of
`As reported in RFC 1052,
`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) was to be
`used to manage nodes in the Internet community.
`In the long—term,
`the use of the OSI network management framework was to be examined.
`Two documents were produced to define the management information: RFC
`1065, which defined the Structure of Management Information (SMI)
`[2], and RFC 1066, which defined the Management Information Base
`(MIB)
`[3]. Both of these documents were designed so as to be
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 2]
`
`1242
`
`1242
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`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 [4],
`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,
`the SNMP,
`to respond to new operational
`needs in the Internet community by producing documents defining new
`MIB items.
`
`The IAB has designated the SNMP, SMI, and the initial Internet MIB to
`be full "Standard Protocols" with "Recommended" status.
`By this
`action,
`the IAB recommends that all IP and TCP implementations be
`network manageable and that the implementations that are network
`manageable are expected to adopt and implement
`the SMI, MIB, and
`SNMP.
`
`the current network management framework for TCP/IP— based
`As such,
`internets consists of: Structure and Identification of Management
`Information for TCP/IP-based Internets, which describes how managed
`objects contained in the MIB are defined as set forth in RFC 1155
`[S]; Management Information Base for Network Management of TCP/IP-
`based Internets, which describes the managed objects contained in the
`MIB as set forth in RFC 1156 [6]; and,
`the Simple Network Management
`Protocol, which defines the protocol used to manage these objects, as
`set forth in this memo.
`
`IAB Recommendations for the Development of
`As reported in RFC 1052,
`Internet Network Management Standards [1],
`the Internet Activities
`Board has directed the Internet Engineering Task Force (IETF)
`to
`create two new working groups in the area of network management. One
`group was charged with the further specification and definition of
`elements to be included in the Management Information Base (MIB).
`The other was charged with defining the modifications to the Simple
`Network Management Protocol
`(SNMP)
`to accommodate the short-term
`needs of the network vendor and operations communities, and to align
`with the output of the MIB working group.
`
`The MIB working group produced two memos, one which defines a
`Structure for Management Information (SMI)
`[2]
`for use by the managed
`
`case, Fedor, Schoffstall, & Davin
`
`[Page 3]
`
`1243
`
`1243
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`objects contained in the MIB.
`managed objects.
`
`A second memo
`
`[3] defines the list of
`
`The output of the SNMP Extensions working group is this memo, which
`incorporates changes to the initial SNMP definition [7] required to
`attain alignment with the output of the MIB working group.
`The
`changes should be minimal
`in order to be consistent with the IAB's
`directive that the working groups be "extremely sensitive to the need
`to keep the SNMP simple." Although considerable care and debate has
`gone into the changes to the SNMP which are reflected in this memo,
`the resulting protocol is not backwardly—compatible with its
`predecessor,
`the Simple Gateway Monitoring Protocol
`(SGMP)
`[8].
`Although the syntax of the protocol has been altered,
`the original
`philosophy, design decisions, and architecture remain intact.
`In
`order to avoid confusion, new UDP ports have been allocated for use
`by the protocol described in this memo.
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 4]
`
`1244
`
`1244
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`3.
`
`The SNMP Architecture
`
`Implicit in the SNMP architectural model is a collection of network
`management stations and network elements. Network management
`stations execute management applications which monitor and control
`network elements. Network elements are devices such as hosts,
`gateways,
`terminal servers, and the like, which have management
`agents responsible for performing the network management functions
`requested by the network management stations.
`The Simple Network
`Management Protocol
`(SNMP)
`is used to communicate management
`information between the network management stations and the agents in
`the network elements.
`
`3.1. Goals of the Architecture
`
`The SNMP explicitly minimizes the number and complexity of management
`functions realized by the management agent itself. This goal is
`attractive in at least four respects:
`
`(1)
`
`(2)
`
`(3)
`
`The development cost for management agent software
`necessary to support
`the protocol is accordingly reduced.
`
`The degree of management function that is remotely
`supported is accordingly increased,
`thereby admitting
`fullest use of internet resources in the management task.
`
`The degree of management function that is remotely
`supported is accordingly increased,
`thereby imposing the
`fewest possible restrictions on the form and
`sophistication of management tools.
`
`(4) Simplified sets of management functions are easily
`understood and used by developers of network management
`tools.
`
`A second goal of the protocol is that the functional paradigm for
`monitoring and control be sufficiently extensible to accommodate
`additional, possibly unanticipated aspects of network operation and
`management.
`
`A third goal is that the architecture be, as much as possible,
`independent of the architecture and mechanisms of particular hosts or
`particular gateways.
`
`3.2. Elements of the Architecture
`
`The SNMP architecture articulates a solution to the network
`management problem in terms of:
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 5]
`
`1245
`
`1245
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`(1)
`
`(2)
`
`(3)
`
`(4)
`
`(5)
`
`(6)
`
`the scope of the management
`the protocol,
`
`information communicated by
`
`the representation of the management information
`communicated by the protocol,
`
`operations on management information supported by the
`protocol,
`
`the form and meaning of exchanges among management
`entities,
`
`the definition of administrative relationships among
`management entities, and
`
`the form and meaning of references to management
`information.
`
`3.
`
`3.
`
`2.1.
`
`Scope of Management Information
`
`information communicated by operation of
`The scope of the management
`the SNMP is exactly that represented by instances of all non-
`aggregate object types either defined in Internet-standard MIB or
`defined elsewhere according to the conventions set forth in
`Internet-standard SMI
`[5].
`
`Support for aggregate object types in the MIB is neither required for
`conformance with the SMI nor realized by the SNMP.
`
`2.2. Representation of Management Information
`
`Management information communicated by operation of the SNMP is
`represented according to the subset of the ASN.1 language [9]
`that is
`specified for the definition of non-aggregate types in the SMI.
`
`The SGMP adopted the convention of using a well-defined subset of the
`ASN.1 language [9].
`The SNMP continues and extends this tradition by
`utilizing a moderately more complex subset of ASN.1 for describing
`managed objects and for describing the protocol data units used for
`managing those objects.
`In addition,
`the desire to ease eventual
`transition to OSI—based network management protocols led to the
`definition in the ASN.1 language of an Internet-standard Structure of
`Management Information (SMI)
`[5] and Management Information Base
`(MIB)
`[6].
`The use of the ASN.1 language, was,
`in part, encouraged
`by the successful use of ASN.1 in earlier efforts,
`in particular,
`the
`SGMP.
`The restrictions on the use of ASN.1 that are part of the SMI
`contribute to the simplicity espoused and validated by experience
`with the SGMP.
`
`Case,
`
`Fedor, Schoffstall, & Davin
`
`[Page 6]
`
`1246
`
`1246
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`the SNMP uses only a subset of the
`Also for the sake of simplicity,
`basic encoding rules of ASN.1 [10]. Namely, all encodings use the
`definite—length form. Further, whenever permissible, non-constructor
`encodings are used rather than constructor encodings. This
`restriction applies to all aspects of ASN.1 encoding, both for the
`top—level protocol data units and the data objects they contain.
`
`3.2.3. Operations Supported on Management Information
`
`The SNMP models all management agent functions as alterations or
`inspections of variables. Thus, a protocol entity on a logically
`remote host
`(possibly the network element itself) interacts with the
`management agent resident on the network element in order to retrieve
`(get) or alter (set) variables. This strategy has at least two
`positive consequences:
`
`(1)
`
`(2)
`
`It has the effect of limiting the number of essential
`management functions realized by the management agent to
`two:
`one operation to assign a value to a specified
`configuration or other parameter and another to retrieve
`such a value.
`
`A second effect of this decision is to avoid introducing
`into the protocol definition support for imperative
`management commands:
`the number of such commands is in
`practice ever-increasing, and the semantics of such
`commands are in general arbitrarily complex.
`
`The strategy implicit in the SNMP is that the monitoring of network
`state at any significant level of detail is accomplished primarily by
`polling for appropriate information on the part of the monitoring
`center(s).
`A limited number of unsolicited messages (traps) guide
`the timing and focus of the polling. Limiting the number of
`unsolicited messages is consistent with the goal of simplicity and
`minimizing the amount of traffic generated by the network management
`function.
`
`The exclusion of imperative commands from the set of explicitly
`supported management functions is unlikely to preclude any desirable
`management agent operation. Currently, most commands are requests
`either to set the value of some parameter or to retrieve such a
`value, and the function of the few imperative commands currently
`supported is easily accommodated in an asynchronous mode by this
`management model.
`In this scheme, an imperative command might be
`realized as the setting of a parameter value that subsequently
`triggers the desired action.
`For example, rather than implementing a
`"reboot command," this action might be invoked by simply setting a
`parameter indicating the number of seconds until system reboot.
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 7]
`
`1247
`
`1247
`
`

`
`RFC ll57
`
`SNMP
`
`May 1990
`
`3.2.4.
`
`Form and Meaning of Protocol Exchanges
`
`The communication of management information among management entities
`is realized in the SNMP through the exchange of protocol messages.
`The form and meaning of those messages is defined below in Section 4.
`
`Consistent with the goal of minimizing complexity of the management
`agent,
`the exchange of SNMP messages requires only an unreliable
`datagram service, and every message is entirely and independently
`represented by a single transport datagram. While this document
`specifies the exchange of messages via the UDP protocol
`[11],
`the
`mechanisms of the SNMP are generally suitable for use with a wide
`variety of transport services.
`
`3.2.5. Definition of Administrative Relationships
`
`The SNMP architecture admits a variety of administrative
`The
`relationships among entities that participate in the protocol.
`entities residing at management stations and network elements which
`communicate with one another using the SNMP are termed SNMP
`application entities.
`The peer processes which implement the SNMP,
`and thus support
`the SNMP application entities, are termed protocol
`entities.
`
`A pairing of an SNMP agent with some arbitrary set of SNMP
`application entities is called an SNMP community.
`Each SNMP
`community is named by a string of octets,
`that is called the
`community name for said community.
`
`An SNMP message originated by an SNMP application entity that in fact
`belongs to the SNMP community named by the community component of
`said message is called an authentic SNMP message.
`The set of rules
`by which an SNMP message is identified as an authentic SNMP message
`for a particular SNMP community is called an authentication scheme.
`An implementation of a function that identifies authentic SNMP
`messages according to one or more authentication schemes is called an
`authentication service.
`
`Clearly, effective management of administrative relationships among
`SNMP application entities requires authentication services that
`(by
`the use of encryption or other techniques) are able to identify
`authentic SNMP messages with a high degree of certainty.
`Some SNMP
`implementations may wish to support only a trivial authentication
`service that identifies all SNMP messages as authentic SNMP messages.
`
`For any network element, a subset of objects in the MIB that pertain
`to that element is called a SNMP MIB view. Note that the names of
`the object types represented in a SNMP MIB view need not belong to a
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 8]
`
`1248
`
`1248
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`single sub-tree of the object type name space.
`
`An element of the set
`access mode.
`
`{ READ-ONLY, READ-WRITE }
`
`is called an SNMP
`
`A pairing of a SNMP access mode with a SNMP MIB view is called an
`SNMP community profile.
`A SNMP community profile represents
`specified access privileges to variables in a specified MIB view. For
`every variable in the MIB view in a given SNMP community profile,
`access to that variable is represented by the profile according to
`the following conventions:
`
`(1)
`
`(2)
`
`(3)
`
`(4)
`
`if said variable is defined in the MIB with "Access:" of
`"none," it is unavailable as an operand for any operator;
`
`if said variable is defined in the MIB with "Access:" of
`"read-write" or "write—only" and the access mode of the
`given profile is READ—WRITE,
`that variable is available
`as an operand for the get, set, and trap operations;
`
`the variable is available as an operand for
`otherwise,
`the get and trap operations.
`
`In those cases where a "write—only" variable is an
`operand used for the get or trap operations,
`the value
`given for the variable is implementation—specific.
`
`A pairing of a SNMP community with a SNMP community profile is called
`a SNMP access policy. An access policy represents a specified
`community profile afforded by the SNMP agent of a specified SNMP
`community to other members of that community. All administrative
`relationships among SNMP application entities are architecturally
`defined in terms of SNMP access policies.
`
`For every SNMP access policy, if the network element on which the
`SNMP agent for the specified SNMP community resides is not that to
`which the MIB view for the specified profile pertains,
`then that
`policy is called a SNMP proxy access policy. The SNMP agent
`associated with a proxy access policy is called a SNMP proxy agent.
`While careless definition of proxy access policies can result in
`management
`loops, prudent definition of proxy policies is useful
`at least two ways:
`
`in
`
`(1)
`
`It permits the monitoring and control of network elements
`which are otherwise not addressable using the management
`protocol and the transport protocol. That is, a proxy
`agent may provide a protocol conversion function allowing
`a management station to apply a consistent management
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 9]
`
`1249
`
`1249
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`including devices such
`framework to all network elements,
`as modems, multiplexors, and other devices which support
`different management frameworks.
`
`(2)
`
`It potentially shields network elements from elaborate
`access control policies.
`For example, a proxy agent may
`implement sophisticated access control whereby diverse
`subsets of variables within the MIB are made accessible
`
`to different management stations without increasing the
`complexity of the network element.
`
`By way of example, Figure 1 illustrates the relationship between
`management stations, proxy agents, and management agents.
`In this
`example,
`the proxy agent is envisioned to be a normal Internet
`Network Operations Center
`(INOC) of some administrative domain which
`has a standard managerial relationship with a set of management
`agents.
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 10]
`
`1250
`
`1250
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`|
`|Region #2 INOC
`|
`I
`|Domain=Region #2]
`|CPU=super—mini—1]
`|PCommunity=pub
`I
`
`|PC in Region #3 |
`|
`|
`|Domain=Region #3]
`|CPU=C1one-1
`|
`|PCommunity=s1ate|
`
`I I
`
`| I I I
`
`Region #1 INOC
`
`|Domain=Region #1
`|CPU=super—mini—1
`|PCommunity=pub
`
`I I
`
`|Domain=Region #3 |
`|CPU=super-mini-2 |
`|PCommunity=pub,
`|
`|
`slate
`|
`|DCommunity=secret|
`I
`
`|
`|Domain=Region#3
`|
`|CPU=router-1
`|DCommunity=secret|
`+ - — — - - - - - - — — - - - - —-+
`
`I
`|Domain=Region#3
`|
`|CPU=mainframe—1
`|DCommunity=secret|
`
`|
`|Domain=Region#3
`|
`|CPU=modem-1
`|DCommunity=secret|
`
`Domain:
`
`the administrative domain of the element
`Pcommunityz
`the name of a community utilizing a proxy agent
`Dcommunityz
`the name of a direct community
`
`Figure 1
`Example Network Management Configuration
`
`Case, Fedor, Schoffstall, & Davin
`
`[Page 11]
`
`1251
`
`1251
`
`

`
`RFC 1157
`
`SNMP
`
`May 1990
`
`3.2.6.
`
`Form and Meaning of References to Managed Objects
`
`The SMI requires that the definition of a conformant management
`protocol address:
`
`(1)
`
`the resolution of ambiguous MIB references,
`
`(2)
`
`(3)
`
`the resolution of MIB references in the presence multiple
`MIB versions, and
`
`the identification of particular instances of object
`types defined in the MIB.
`
`3.2.6.1. Resolution of Ambiguous MIB References
`
`Because the scope of any SNMP operation is conceptually confined to
`objects relevant to a single network element, and because all SNMP
`references to MIB objects are (implicitly or explicitly) by unique
`variable names