From 39c5b26159670964242823ceffd3d3b7eb3a4ea8 Mon Sep 17 00:00:00 2001 From: amosjeffries <> Date: Tue, 30 Oct 2007 12:46:24 +0000 Subject: [PATCH] RFC bits omitted earlier. --- doc/rfc/1-index.txt | 5 + doc/rfc/rfc1902.txt | 2243 +++++++++++++++++++++++++++++++++++++++++++ doc/rfc/rfc1905.txt | 1347 ++++++++++++++++++++++++++ 3 files changed, 3595 insertions(+) create mode 100644 doc/rfc/rfc1902.txt create mode 100644 doc/rfc/rfc1905.txt diff --git a/doc/rfc/1-index.txt b/doc/rfc/1-index.txt index a74d5ee9ae..a07e89558f 100644 --- a/doc/rfc/1-index.txt +++ b/doc/rfc/1-index.txt @@ -90,6 +90,11 @@ rfc2965.txt HTTP State Management Mechanism Cookies +rfc3162.txt + RADIUS and IPv6 + Documents the method of authentication for RADIUS when IPv6 addresses + may be involved. Squid bundles a RADIUS auth helper. + rfc3226.txt DNSSEC and IPv6 A6 aware server/resolver message size requirements Documents resolver requirements for IPv6 DNS structures and handling diff --git a/doc/rfc/rfc1902.txt b/doc/rfc/rfc1902.txt new file mode 100644 index 0000000000..d6ff64171e --- /dev/null +++ b/doc/rfc/rfc1902.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group SNMPv2 Working Group +Request for Comments: 1902 J. Case +Obsoletes: 1442 SNMP Research, Inc. +Category: Standards Track K. McCloghrie + Cisco Systems, Inc. + M. Rose + Dover Beach Consulting, Inc. + S. Waldbusser + International Network Services + January 1996 + + + Structure of Management Information + for Version 2 of the + Simple Network Management Protocol (SNMPv2) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Introduction + + A 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 + authentication, authorization, access control, and privacy policies. + + Management stations execute management applications which monitor and + control managed elements. Managed elements are devices such as + hosts, routers, terminal servers, etc., which are monitored and + controlled via access to their 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 an adapted subset of + OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of + this document, the Structure of Management Information (SMI), to + define that adapted subset, and to assign a set of associated + administrative values. + + + + +SNMPv2 Working Group Standards Track [Page 1] + +RFC 1902 SMI for SNMPv2 January 1996 + + + The SMI is divided into three parts: module definitions, object + definitions, and, notification 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. + +1.1. A Note on Terminology + + For the purpose of exposition, the original Internet-standard Network + Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD + 15), and 1212 (STD 16), is termed the SNMP version 1 framework + (SNMPv1). The current framework is termed the SNMP version 2 + framework (SNMPv2). + +2. Definitions + +SNMPv2-SMI DEFINITIONS ::= BEGIN + + +-- the path to the root + +org OBJECT IDENTIFIER ::= { iso 3 } +dod OBJECT IDENTIFIER ::= { org 6 } +internet OBJECT IDENTIFIER ::= { dod 1 } + +directory OBJECT IDENTIFIER ::= { internet 1 } + +mgmt OBJECT IDENTIFIER ::= { internet 2 } +mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } +transmission OBJECT IDENTIFIER ::= { mib-2 10 } + +experimental OBJECT IDENTIFIER ::= { internet 3 } + +private OBJECT IDENTIFIER ::= { internet 4 } +enterprises OBJECT IDENTIFIER ::= { private 1 } + +security OBJECT IDENTIFIER ::= { internet 5 } + + + + +SNMPv2 Working Group Standards Track [Page 2] + +RFC 1902 SMI for SNMPv2 January 1996 + + +snmpV2 OBJECT IDENTIFIER ::= { internet 6 } + +-- transport domains +snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } + +-- transport proxies +snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } + +-- module identities +snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } + + +-- definitions for information modules + +MODULE-IDENTITY MACRO ::= +BEGIN + TYPE NOTATION ::= + "LAST-UPDATED" value(Update UTCTime) + "ORGANIZATION" Text + "CONTACT-INFO" Text + "DESCRIPTION" Text + RevisionPart + + VALUE NOTATION ::= + value(VALUE OBJECT IDENTIFIER) + + RevisionPart ::= + Revisions + | empty + Revisions ::= + Revision + | Revisions Revision + Revision ::= + "REVISION" value(Update UTCTime) + "DESCRIPTION" Text + + -- uses the NVT ASCII character set + Text ::= """" string """" +END + + +OBJECT-IDENTITY MACRO ::= +BEGIN + TYPE NOTATION ::= + "STATUS" Status + "DESCRIPTION" Text + ReferPart + + + + +SNMPv2 Working Group Standards Track [Page 3] + +RFC 1902 SMI for SNMPv2 January 1996 + + + VALUE NOTATION ::= + value(VALUE OBJECT IDENTIFIER) + + Status ::= + "current" + | "deprecated" + | "obsolete" + + ReferPart ::= + "REFERENCE" Text + | empty + + Text ::= """" string """" +END + + +-- names of objects + +ObjectName ::= + OBJECT IDENTIFIER + +NotificationName ::= + OBJECT IDENTIFIER + +-- syntax of objects + +ObjectSyntax ::= + CHOICE { + simple + SimpleSyntax, + + -- note that SEQUENCEs for conceptual tables and + -- rows are not mentioned here... + + application-wide + ApplicationSyntax + } + + +-- built-in ASN.1 types + +SimpleSyntax ::= + CHOICE { + -- INTEGERs with a more restrictive range + -- may also be used + integer-value -- includes Integer32 + INTEGER (-2147483648..2147483647), + + + + +SNMPv2 Working Group Standards Track [Page 4] + +RFC 1902 SMI for SNMPv2 January 1996 + + + -- OCTET STRINGs with a more restrictive size + -- may also be used + string-value + OCTET STRING (SIZE (0..65535)), + + objectID-value + OBJECT IDENTIFIER + } + + +-- indistinguishable from INTEGER, but never needs more than +-- 32-bits for a two's complement representation +Integer32 ::= + [UNIVERSAL 2] + IMPLICIT INTEGER (-2147483648..2147483647) + + +-- application-wide types + +ApplicationSyntax ::= + CHOICE { + ipAddress-value + IpAddress, + + counter-value + Counter32, + + timeticks-value + TimeTicks, + + arbitrary-value + Opaque, + + big-counter-value + Counter64, + + unsigned-integer-value -- includes Gauge32 + Unsigned32 + } + +-- in network-byte order +-- (this is a tagged type for historical reasons) +IpAddress ::= + [APPLICATION 0] + IMPLICIT OCTET STRING (SIZE (4)) + +-- this wraps +Counter32 ::= + + + +SNMPv2 Working Group Standards Track [Page 5] + +RFC 1902 SMI for SNMPv2 January 1996 + + + [APPLICATION 1] + IMPLICIT INTEGER (0..4294967295) + +-- this doesn't wrap +Gauge32 ::= + [APPLICATION 2] + IMPLICIT INTEGER (0..4294967295) + +-- an unsigned 32-bit quantity +-- indistinguishable from Gauge32 +Unsigned32 ::= + [APPLICATION 2] + IMPLICIT INTEGER (0..4294967295) + +-- hundredths of seconds since an epoch +TimeTicks ::= + [APPLICATION 3] + IMPLICIT INTEGER (0..4294967295) + +-- for backward-compatibility only +Opaque ::= + [APPLICATION 4] + IMPLICIT OCTET STRING + +-- for counters that wrap in less than one hour with only 32 bits +Counter64 ::= + [APPLICATION 6] + IMPLICIT INTEGER (0..18446744073709551615) + + +-- definition for objects + +OBJECT-TYPE MACRO ::= +BEGIN + TYPE NOTATION ::= + "SYNTAX" Syntax + UnitsPart + "MAX-ACCESS" Access + "STATUS" Status + "DESCRIPTION" Text + ReferPart + IndexPart + DefValPart + + VALUE NOTATION ::= + value(VALUE ObjectName) + + Syntax ::= + + + +SNMPv2 Working Group Standards Track [Page 6] + +RFC 1902 SMI for SNMPv2 January 1996 + + + type(ObjectSyntax) + | "BITS" "{" Kibbles "}" + Kibbles ::= + Kibble + | Kibbles "," Kibble + Kibble ::= + identifier "(" nonNegativeNumber ")" + + UnitsPart ::= + "UNITS" Text + | empty + + Access ::= + "not-accessible" + | "accessible-for-notify" + | "read-only" + | "read-write" + | "read-create" + + Status ::= + "current" + | "deprecated" + | "obsolete" + + ReferPart ::= + "REFERENCE" Text + | empty + + IndexPart ::= + "INDEX" "{" IndexTypes "}" + | "AUGMENTS" "{" Entry "}" + | empty + IndexTypes ::= + IndexType + | IndexTypes "," IndexType + IndexType ::= + "IMPLIED" Index + | Index + Index ::= + -- use the SYNTAX value of the + -- correspondent OBJECT-TYPE invocation + value(Indexobject ObjectName) + Entry ::= + -- use the INDEX value of the + -- correspondent OBJECT-TYPE invocation + value(Entryobject ObjectName) + + DefValPart ::= + + + +SNMPv2 Working Group Standards Track [Page 7] + +RFC 1902 SMI for SNMPv2 January 1996 + + + "DEFVAL" "{" value(Defval Syntax) "}" + | empty + + -- uses the NVT ASCII character set + Text ::= """" string """" +END + + +-- definitions for notifications + +NOTIFICATION-TYPE MACRO ::= +BEGIN + TYPE NOTATION ::= + ObjectsPart + "STATUS" Status + "DESCRIPTION" Text + ReferPart + + VALUE NOTATION ::= + value(VALUE NotificationName) + + ObjectsPart ::= + "OBJECTS" "{" Objects "}" + | empty + Objects ::= + Object + | Objects "," Object + Object ::= + value(Name ObjectName) + + Status ::= + "current" + | "deprecated" + | "obsolete" + + ReferPart ::= + "REFERENCE" Text + | empty + + -- uses the NVT ASCII character set + Text ::= """" string """" +END + +-- definitions of administrative identifiers + +zeroDotZero OBJECT-IDENTITY + STATUS current + DESCRIPTION + + + +SNMPv2 Working Group Standards Track [Page 8] + +RFC 1902 SMI for SNMPv2 January 1996 + + + "A value used for null identifiers." + ::= { 0 0 } + +END + +3. Information Modules + + An "information module" is an ASN.1 module defining information + relating to network management. + + The SMI describes how to use a subset of ASN.1 to define an + information module. Further, additional restrictions are placed on + "standard" information modules. It is strongly recommended that + "enterprise-specific" information modules also adhere to these + restrictions. + + Typically, there are three kinds of information modules: + +(1) MIB modules, which contain definitions of inter-related managed + objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros; + +(2) compliance statements for MIB modules, which make use of the + MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and, + +(3) capability statements for agent implementations which make use of + the AGENT-CAPABILITIES macros [2]. + + This classification scheme does not imply a rigid taxonomy. For + example, a "standard" information module will normally include + definitions of managed objects and a compliance statement. + Similarly, an "enterprise-specific" information module might include + definitions of managed objects and a capability statement. Of + course, a "standard" information module may not contain capability + statements. + + The constructs of ASN.1 allowed in SNMPv2 information modules + include: the IMPORTS clause, value definitions for OBJECT + IDENTIFIERs, type definitions for SEQUENCEs (with restrictions), + ASN.1 type assignments of the restricted ASN.1 types allowed in + SNMPv2, and instances of ASN.1 macros defined in this document and in + other documents [2, 3] of the SNMPv2 framework. Additional ASN.1 + macros may not be defined in SNMPv2 information modules. + + The names of all standard information modules must be unique (but + different versions of the same information module should have the + same name). Developers of enterprise information modules are + encouraged to choose names for their information modules that will + have a low probability of colliding with standard or other enterprise + + + +SNMPv2 Working Group Standards Track [Page 9] + +RFC 1902 SMI for SNMPv2 January 1996 + + + information modules. An information module may not use the ASN.1 + construct of placing an object identifier value between the module + name and the "DEFINITIONS" keyword. + + All information modules start with exactly one invocation of the + MODULE-IDENTITY macro, which provides contact information as well as + revision history to distinguish between versions of the same + information module. This invocation must appear immediately after + any IMPORTs statements. + +3.1. Macro Invocation + + Within an information module, each macro invocation appears as: + + ::= + + where corresponds to an ASN.1 identifier, names + the macro being invoked, and and depend on the + definition of the macro. (Note that this definition of a descriptor + applies to all macros defined in this memo and in [2].) + + For the purposes of this specification, an ASN.1 identifier consists + of one or more letters or digits, and its initial character must be a + lower-case letter. (Note that hyphens are not allowed by this + specification, even though hyphen is allowed by [1]. This + restriction enables arithmetic expressions in languages which use the + minus sign to reference these descriptors without ambiguity.) + + For all descriptors appearing in an information module, the + descriptor shall be unique and mnemonic, and shall not exceed 64 + characters in length. (However, descriptors longer than 32 + characters are not recommended.) This promotes a common language for + humans to use when discussing the information module and also + facilitates simple table mappings for user-interfaces. + + The set of descriptors defined in all "standard" information modules + shall be unique. + + Finally, by convention, if the descriptor refers to an object with a + SYNTAX clause value of either Counter32 or Counter64, then the + descriptor used for the object should denote plurality. + +3.1.1. Textual Clauses + + Some clauses in a macro invocation may take a textual value (e.g., + the DESCRIPTION clause). Note that, in order to conform to the ASN.1 + syntax, the entire value of these clauses must be enclosed in double + quotation marks, and therefore cannot itself contain double quotation + + + +SNMPv2 Working Group Standards Track [Page 10] + +RFC 1902 SMI for SNMPv2 January 1996 + + + marks, although the value may be multi-line. + +3.2. IMPORTing Symbols + + To reference an external object, the IMPORTS statement must be used + to identify both the descriptor and the module in which the + descriptor is defined, where the module is identified by its ASN.1 + module name. + + Note that when symbols from "enterprise-specific" information modules + are referenced (e.g., a descriptor), there is the possibility of + collision. As such, if different objects with the same descriptor + are IMPORTed, then this ambiguity is resolved by prefixing the + descriptor with the name of the information module and a dot ("."), + i.e., + + "module.descriptor" + + (All descriptors must be unique within any information module.) + + Of course, this notation can be used even when there is no collision + when IMPORTing symbols. + + Finally, the IMPORTS statement may not be used to import an ASN.1 + named type which corresponds to either the SEQUENCE or SEQUENCE OF + type. + +3.3. Exporting Symbols + + The ASN.1 EXPORTS statement is not allowed in SNMPv2 information + modules. All items defined in an information module are + automatically exported. + +3.4. ASN.1 Comments + + Comments in ASN.1 commence with a pair of adjacent hyphens and end + with the next pair of adjacent hyphens or at the end of the line, + whichever occurs first. + +3.5. OBJECT IDENTIFIER values + + An OBJECT IDENTIFIER value is an ordered list of non-negative + numbers. For the SNMPv2 framework, each number in the list is + referred to as a sub-identifier, there are at most 128 sub- + identifiers in a value, and each sub-identifier has a maximum value + of 2^32-1 (4294967295 decimal). All OBJECT IDENTIFIER values have at + least two sub-identifiers, where the value of the first sub- + identifier is one of the following well-known names: + + + +SNMPv2 Working Group Standards Track [Page 11] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Value Name + 0 ccitt + 1 iso + 2 joint-iso-ccitt + +4. Naming Hierarchy + + The root of the subtree administered by the Internet Assigned Numbers + Authority (IANA) for the Internet is: + + internet OBJECT IDENTIFIER ::= { iso 3 6 1 } + + That is, the Internet subtree of OBJECT IDENTIFIERs starts with the + prefix: + + 1.3.6.1. + + Several branches underneath this subtree are used for network + management: + + mgmt OBJECT IDENTIFIER ::= { internet 2 } + experimental OBJECT IDENTIFIER ::= { internet 3 } + private OBJECT IDENTIFIER ::= { internet 4 } + enterprises OBJECT IDENTIFIER ::= { private 1 } + + However, the SMI does not prohibit the definition of objects in other + portions of the object tree. + + The mgmt(2) subtree is used to identify "standard" objects. + + The experimental(3) subtree is used to identify objects being + designed by working groups of the IETF. If an information module + produced by a working group becomes a "standard" information module, + then at the very beginning of its entry onto the Internet standards + track, the objects are moved under the mgmt(2) subtree. + + The private(4) subtree is used to identify objects defined + unilaterally. The enterprises(1) subtree beneath private is used, + among other things, to permit providers of networking subsystems to + register models of their products. + +5. Mapping of the MODULE-IDENTITY macro + + The MODULE-IDENTITY macro is used to provide contact and revision + history for each information module. It must appear exactly once in + every information module. It should be noted that the expansion of + the MODULE-IDENTITY macro is something which conceptually happens + during implementation and not during run-time. + + + +SNMPv2 Working Group Standards Track [Page 12] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Note that reference in an IMPORTS clause or in clauses of SNMPv2 + macros to an information module is NOT through the use of the + 'descriptor' of a MODULE-IDENTITY macro; rather, an information + module is referenced through specifying its module name. + +5.1. Mapping of the LAST-UPDATED clause + + The LAST-UPDATED clause, which must be present, contains the date and + time that this information module was last edited. The date and time + are represented in UTC Time format (see Appendix B). + +5.2. Mapping of the ORGANIZATION clause + + The ORGANIZATION clause, which must be present, contains a textual + description of the organization under whose auspices this information + module was developed. + +5.3. Mapping of the CONTACT-INFO clause + + The CONTACT-INFO clause, which must be present, contains the name, + postal address, telephone number, and electronic mail address of the + person to whom technical queries concerning this information module + should be sent. + +5.4. Mapping of the DESCRIPTION clause + + The DESCRIPTION clause, which must be present, contains a high-level + textual description of the contents of this information module. + +5.5. Mapping of the REVISION clause + + The REVISION clause, which need not be present, is repeatedly used to + describe the revisions (including the initial version) made to this + information module, in reverse chronological order (i.e., most recent + first). Each instance of this clause contains the date and time of + the revision. The date and time are represented in UTC Time format + (see Appendix B). + +5.5.1. Mapping of the DESCRIPTION sub-clause + + The DESCRIPTION clause, which must be present for each REVISION + clause, contains a high-level textual description of the revision + identified in that REVISION clause. + +5.6. Mapping of the MODULE-IDENTITY value + + The value of an invocation of the MODULE-IDENTITY macro is an OBJECT + IDENTIFIER. As such, this value may be authoritatively used when + + + +SNMPv2 Working Group Standards Track [Page 13] + +RFC 1902 SMI for SNMPv2 January 1996 + + + specifying an OBJECT IDENTIFIER value to refer to the information + module containing the invocation. + +5.7. Usage Example + + Consider how a skeletal MIB module might be constructed: e.g., + +FIZBIN-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, experimental + FROM SNMPv2-SMI; + + +fizbin MODULE-IDENTITY + LAST-UPDATED "9505241811Z" + ORGANIZATION "IETF SNMPv2 Working Group" + CONTACT-INFO + " Marshall T. Rose + + Postal: Dover Beach Consulting, Inc. + 420 Whisman Court + Mountain View, CA 94043-2186 + US + + Tel: +1 415 968 1052 + Fax: +1 415 968 2510 + + E-mail: mrose@dbc.mtview.ca.us" + DESCRIPTION + "The MIB module for entities implementing the xxxx + protocol." + REVISION "9505241811Z" + DESCRIPTION + "The latest version of this MIB module." + REVISION "9210070433Z" + DESCRIPTION + "The initial version of this MIB module." +-- contact IANA for actual number + ::= { experimental xx } + + +END + + + + + + + + +SNMPv2 Working Group Standards Track [Page 14] + +RFC 1902 SMI for SNMPv2 January 1996 + + +6. Mapping of the OBJECT-IDENTITY macro + + The OBJECT-IDENTITY macro is used to define information about an + OBJECT IDENTIFIER assignment. All administrative OBJECT IDENTIFIER + assignments which define a type identification value (see + AutonomousType, a textual convention defined in [3]) should be + defined via the OBJECT-IDENTITY macro. It should be noted that the + expansion of the OBJECT-IDENTITY macro is something which + conceptually happens during implementation and not during run-time. + +6.1. Mapping of the STATUS clause + + The STATUS clause, which must be present, indicates whether this + definition is current or historic. + + The values "current", and "obsolete" are self-explanatory. The + "deprecated" value indicates that the definition is obsolete, but + that an implementor may wish to support it to foster interoperability + with older implementations. + +6.2. Mapping of the DESCRIPTION clause + + The DESCRIPTION clause, which must be present, contains a textual + description of the object assignment. + +6.3. Mapping of the REFERENCE clause + + The REFERENCE clause, which need not be present, contains a textual + cross-reference to an object assignment defined in some other + information module. + +6.4. Mapping of the OBJECT-IDENTITY value + + The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT + IDENTIFIER. + +6.5. Usage Example + + Consider how an OBJECT IDENTIFIER assignment might be made: e.g., + +fizbin69 OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identity of the Fizbin 69 chipset." + ::= { fizbinChipSets 1 } + + + + + + +SNMPv2 Working Group Standards Track [Page 15] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7. Mapping of the OBJECT-TYPE macro + + The OBJECT-TYPE macro is used to define a type of managed object. It + should be noted that the expansion of the OBJECT-TYPE macro is + something which conceptually happens during implementation and not + during run-time. + + For leaf objects which are not columnar objects (i.e., not contained + within a conceptual table), instances of the object are identified by + appending a sub-identifier of zero to the name of that object. + Otherwise, the INDEX clause of the conceptual row object superior to + a columnar object defines instance identification information. + +7.1. Mapping of the SYNTAX clause + + The SYNTAX clause, which must be present, defines the abstract data + structure corresponding to that object. The data structure must be + one of the following: a base type, the BITS construct, or a textual + convention. (SEQUENCE OF and SEQUENCE are also possible for + conceptual tables, see section 7.1.12). The base types are those + defined in the ObjectSyntax CHOICE. A textual convention is a + newly-defined type defined as a sub-type of a base type [3]. + + A extended subset of the full capabilities of ASN.1 sub-typing is + allowed, as appropriate to the underingly ASN.1 type. Any such + restriction on size, range, enumerations or repertoire specified in + this clause represents the maximal level of support which makes + "protocol sense". Restrictions on sub-typing are specified in detail + in Section 9 and Appendix C of this memo. + + The semantics of ObjectSyntax are now described. + +7.1.1. Integer32 and INTEGER + + The Integer32 type represents integer-valued information between + -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This + type is indistinguishable from the INTEGER type. Both the INTEGER + and Integer32 types may be sub-typed to be more constrained than the + Integer32 type. + + The INTEGER type may also be used to represent integer-valued + information as named-number enumerations. In this case, only those + named-numbers so enumerated may be present as a value. Note that + although it is recommended that enumerated values start at 1 and be + numbered contiguously, any valid value for Integer32 is allowed for + an enumerated value and, further, enumerated values needn't be + contiguously assigned. + + + + +SNMPv2 Working Group Standards Track [Page 16] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Finally, a label for a named-number enumeration must consist of one + or more letters or digits (no hyphens), up to a maximum of 64 + characters, and the initial character must be a lower-case letter. + (However, labels longer than 32 characters are not recommended.) + +7.1.2. OCTET STRING + + The OCTET STRING type represents arbitrary binary or textual data. + Although there is no SMI-specified size limitation for this type, MIB + designers should realize that there may be implementation and + interoperability limitations for sizes in excess of 255 octets. + +7.1.3. OBJECT IDENTIFIER + + The OBJECT IDENTIFIER type represents administratively assigned + names. Any instance of this type may have at most 128 sub- + identifiers. Further, each sub-identifier must not exceed the value + 2^32-1 (4294967295 decimal). + +7.1.4. The BITS construct + + The BITS construct represents an enumeration of named bits. This + collection is assigned non-negative, contiguous values, starting at + zero. Only those named-bits so enumerated may be present in a value. + (Thus, enumerations must be assigned to consecutive bits; however, + see Section 9 for refinements of an object with this syntax.) + + Although there is no SMI-specified limitation on the number of + enumerations (and therefore on the length of a value), MIB designers + should realize that there may be implementation and interoperability + limitations for sizes in excess of 128 bits. + + Finally, a label for a named-number enumeration must consist of one + or more letters or digits (no hyphens), up to a maximum of 64 + characters, and the initial character must be a lower-case letter. + (However, labels longer than 32 characters are not recommended.) + +7.1.5. IpAddress + + The IpAddress type represents a 32-bit internet address. It is + represented as an OCTET STRING of length 4, in network byte-order. + + Note that the IpAddress type is a tagged type for historical reasons. + Network addresses should be represented using an invocation of the + TEXTUAL-CONVENTION macro [3]. + + + + + + +SNMPv2 Working Group Standards Track [Page 17] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7.1.6. Counter32 + + The Counter32 type represents a non-negative integer which + monotonically increases until it reaches a maximum value of 2^32-1 + (4294967295 decimal), when it wraps around and starts increasing + again from zero. + + Counters have no defined "initial" value, and thus, a single value of + a Counter has (in general) no information content. Discontinuities + in the monotonically increasing value normally occur at re- + initialization of the management system, and at other times as + specified in the description of an object-type using this ASN.1 type. + If such other times can occur, for example, the creation of an object + instance at times other than re-initialization, then a corresponding + object should be defined with a SYNTAX clause value of TimeStamp (a + textual convention defined in [3]) indicating the time of the last + discontinuity. + + The value of the MAX-ACCESS clause for objects with a SYNTAX clause + value of Counter32 is either "read-only" or "accessible-for-notify". + + A DEFVAL clause is not allowed for objects with a SYNTAX clause value + of Counter32. + +7.1.7. Gauge32 + + The Gauge32 type represents a non-negative integer, which may + increase or decrease, but shall never exceed a maximum value. The + maximum value can not be greater than 2^32-1 (4294967295 decimal). + The value of a Gauge has its maximum value whenever the information + being modeled is greater or equal to that maximum value; if the + information being modeled subsequently decreases below the maximum + value, the Gauge also decreases. + +7.1.8. TimeTicks + + The TimeTicks type represents a non-negative integer which represents + the time, modulo 2^32 (4294967296 decimal), in hundredths of a second + between two epochs. When objects are defined which use this ASN.1 + type, the description of the object identifies both of the reference + epochs. + + For example, [3] defines the TimeStamp textual convention which is + based on the TimeTicks type. With a TimeStamp, the first reference + epoch is defined as the time when sysUpTime [5] was zero, and the + second reference epoch is defined as the current value of sysUpTime. + + The TimeTicks type may not be sub-typed. + + + +SNMPv2 Working Group Standards Track [Page 18] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7.1.9. Opaque + + The Opaque type is provided solely for backward-compatibility, and + shall not be used for newly-defined object types. + + The Opaque type supports the capability to pass arbitrary ASN.1 + syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4] + into a string of octets. This, in turn, is encoded as an OCTET + STRING, in effect "double-wrapping" the original ASN.1 value. + + Note that a conforming implementation need only be able to accept and + recognize opaquely-encoded data. It need not be able to unwrap the + data and then interpret its contents. + + A requirement on "standard" MIB modules is that no object may have a + SYNTAX clause value of Opaque. + +7.1.10. Counter64 + + The Counter64 type represents a non-negative integer which + monotonically increases until it reaches a maximum value of 2^64-1 + (18446744073709551615 decimal), when it wraps around and starts + increasing again from zero. + + Counters have no defined "initial" value, and thus, a single value of + a Counter has (in general) no information content. Discontinuities + in the monotonically increasing value normally occur at re- + initialization of the management system, and at other times as + specified in the description of an object-type using this ASN.1 type. + If such other times can occur, for example, the creation of an object + instance at times other than re-initialization, then a corresponding + object should be defined with a SYNTAX clause value of TimeStamp (a + textual convention defined in [3]) indicating the time of the last + discontinuity. + + The value of the MAX-ACCESS clause for objects with a SYNTAX clause + value of Counter64 is either "read-only" or "accessible-for-notify". + + A requirement on "standard" MIB modules is that the Counter64 type + may be used only if the information being modeled would wrap in less + than one hour if the Counter32 type was used instead. + + A DEFVAL clause is not allowed for objects with a SYNTAX clause value + of Counter64. + + + + + + + +SNMPv2 Working Group Standards Track [Page 19] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7.1.11. Unsigned32 + + The Unsigned32 type represents integer-valued information between 0 + and 2^32-1 inclusive (0 to 4294967295 decimal). + +7.1.12. Conceptual Tables + + Management operations apply exclusively to scalar objects. However, + it is sometimes convenient for developers of management applications + to impose an imaginary, tabular structure on an ordered collection of + objects within the MIB. Each such conceptual table contains zero or + more rows, and each row may contain one or more scalar objects, + termed columnar objects. This conceptualization is formalized by + using the OBJECT-TYPE macro to define both an object which + corresponds to a table and an object which corresponds to a row in + that table. A conceptual table has SYNTAX of the form: + + SEQUENCE OF + + where refers to the SEQUENCE type of its subordinate + conceptual row. A conceptual row has SYNTAX of the form: + + + + where is a SEQUENCE type defined as follows: + + ::= SEQUENCE { , ... , } + + where there is one for each subordinate object, and each + is of the form: + + + + where is the descriptor naming a subordinate object, and + has the value of that subordinate object's SYNTAX clause, + normally omitting the sub-typing information. Further, these ASN.1 + types are always present (the DEFAULT and OPTIONAL clauses are + disallowed in the SEQUENCE definition). The MAX-ACCESS clause for + conceptual tables and rows is "not-accessible". + +7.1.12.1. Creation and Deletion of Conceptual Rows + + For newly-defined conceptual rows which allow the creation of new + object instances and/or the deletion of existing object instances, + there should be one columnar object with a SYNTAX clause value of + RowStatus (a textual convention defined in [3]) and a MAX-ACCESS + clause value of read-create. By convention, this is termed the + status column for the conceptual row. + + + +SNMPv2 Working Group Standards Track [Page 20] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7.2. Mapping of the UNITS clause + + This UNITS clause, which need not be present, contains a textual + definition of the units associated with that object. + +7.3. Mapping of the MAX-ACCESS clause + + The MAX-ACCESS clause, which must be present, defines whether it + makes "protocol sense" to read, write and/or create an instance of + the object, or to include its value in a notification. This is the + maximal level of access for the object. (This maximal level of + access is independent of any administrative authorization policy.) + + The value "read-write" indicates that read and write access make + "protocol sense", but create does not. The value "read-create" + indicates that read, write and create access make "protocol sense". + The value "not-accessible" indicates an auxiliary object (see Section + 7.7). The value "accessible-for-notify" indicates an object which is + accessible only via a notification (e.g., snmpTrapOID [5]). + + These values are ordered, from least to greatest: "not-accessible", + "accessible-for-notify", "read-only", "read-write", "read-create". + + If any columnar object in a conceptual row has "read-create" as its + maximal level of access, then no other columnar object of the same + conceptual row may have a maximal access of "read-write". (Note that + "read-create" is a superset of "read-write".) + +7.4. Mapping of the STATUS clause + + The STATUS clause, which must be present, indicates whether this + definition is current or historic. + + The values "current", and "obsolete" are self-explanatory. The + "deprecated" value indicates that the definition is obsolete, but + that an implementor may wish to support that object to foster + interoperability with older implementations. + +7.5. Mapping of the DESCRIPTION clause + + The DESCRIPTION clause, which must be present, contains a textual + definition of that object which provides all semantic definitions + necessary for implementation, and should embody any information which + would otherwise be communicated in any ASN.1 commentary annotations + associated with the object. + + + + + + +SNMPv2 Working Group Standards Track [Page 21] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7.6. Mapping of the REFERENCE clause + + The REFERENCE clause, which need not be present, contains a textual + cross-reference to an object defined in some other information + module. This is useful when de-osifying a MIB module produced by + some other organization. + +7.7. Mapping of the INDEX clause + + The INDEX clause, which must be present if that object corresponds to + a conceptual row (unless an AUGMENTS clause is present instead), and + must be absent otherwise, defines instance identification information + for the columnar objects subordinate to that object. + + The instance identification information in an INDEX clause must + specify object(s) such that value(s) of those object(s) will + unambiguously distinguish a conceptual row. The syntax of those + objects indicate how to form the instance-identifier: + +(1) integer-valued: a single sub-identifier taking the integer value + (this works only for non-negative integers); + +(2) string-valued, fixed-length strings (or variable-length preceded by + the IMPLIED keyword): `n' sub-identifiers, where `n' is the length + of the string (each octet of the string is encoded in a separate + sub-identifier); + +(3) string-valued, variable-length strings (not preceded by the IMPLIED + keyword): `n+1' sub-identifiers, where `n' is the length of the + string (the first sub-identifier is `n' itself, following this, + each octet of the string is encoded in a separate sub-identifier); + +(4) object identifier-valued (when preceded by the IMPLIED keyword): + `n' sub-identifiers, where `n' is the number of sub-identifiers in + the value (each sub-identifier of the value is copied into a + separate sub-identifier); + +(5) object identifier-valued (when not preceded by the IMPLIED + keyword): `n+1' sub-identifiers, where `n' is the number of sub- + identifiers in the value (the first sub-identifier is `n' itself, + following this, each sub-identifier in the value is copied); + +(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d + notation. + + Note that the IMPLIED keyword can only be present for an object + having a variable-length syntax (e.g., variable-length strings or + object identifier-valued objects), Further, the IMPLIED keyword can + + + +SNMPv2 Working Group Standards Track [Page 22] + +RFC 1902 SMI for SNMPv2 January 1996 + + + only be associated with the last object in the INDEX clause. + Finally, the IMPLIED keyword may not be used on a variable-length + string object if that string might have a value of zero-length. + + Instances identified by use of integer-valued objects should be + numbered starting from one (i.e., not from zero). The use of zero as + a value for an integer-valued index object should be avoided, except + in special cases. + + Objects which are both specified in the INDEX clause of a conceptual + row and also columnar objects of the same conceptual row are termed + auxiliary objects. The MAX-ACCESS clause for auxiliary objects is + "not-accessible", except in the following circumstances: + +(1) within a MIB module originally written to conform to the SNMPv1 + framework, and later converted to conform to the SNMPv2 framework; + or + +(2) a conceptual row must contain at least one columnar object which is + not an auxiliary object. In the event that all of a conceptual + row's columnar objects are also specified in its INDEX clause, then + one of them must be accessible, i.e., have a MAX-ACCESS clause of + "read-only". (Note that this situation does not arise for a + conceptual row allowing create access, since such a row will have a + status column which will not be an auxiliary object.) + + Note that objects specified in a conceptual row's INDEX clause need + not be columnar objects of that conceptual row. In this situation, + the DESCRIPTION clause of the conceptual row must include a textual + explanation of how the objects which are included in the INDEX clause + but not columnar objects of that conceptual row, are used in uniquely + identifying instances of the conceptual row's columnar objects. + +7.8. Mapping of the AUGMENTS clause + + The AUGMENTS clause, which must not be present unless the object + corresponds to a conceptual row, is an alternative to the INDEX + clause. Every object corresponding to a conceptual row has either an + INDEX clause or an AUGMENTS clause. + + If an object corresponding to a conceptual row has an INDEX clause, + that row is termed a base conceptual row; alternatively, if the + object has an AUGMENTS clause, the row is said to be a conceptual row + augmentation, where the AUGMENTS clause names the object + corresponding to the base conceptual row which is augmented by this + conceptual row augmentation. (Thus, a conceptual row augmentation + cannot itself be augmented.) Instances of subordinate columnar + objects of a conceptual row augmentation are identified according to + + + +SNMPv2 Working Group Standards Track [Page 23] + +RFC 1902 SMI for SNMPv2 January 1996 + + + the INDEX clause of the base conceptual row corresponding to the + object named in the AUGMENTS clause. Further, instances of + subordinate columnar objects of a conceptual row augmentation exist + according to the same semantics as instances of subordinate columnar + objects of the base conceptual row being augmented. As such, note + that creation of a base conceptual row implies the correspondent + creation of any conceptual row augmentations. + + For example, a MIB designer might wish to define additional columns + in an "enterprise-specific" MIB which logically extend a conceptual + row in a "standard" MIB. The "standard" MIB definition of the + conceptual row would include the INDEX clause and the "enterprise- + specific" MIB would contain the definition of a conceptual row using + the AUGMENTS clause. On the other hand, it would be incorrect to use + the AUGMENTS clause for the relationship between RFC 1573's ifTable + and the many media-specific MIBs which extend it for specific media + (e.g., the dot3Table in RFC 1650), since not all interfaces are of + the same media. + + Note that a base conceptual row may be augmented by multiple + conceptual row augmentations. + +7.8.1. Relation between INDEX and AUGMENTS clauses + + When defining instance identification information for a conceptual + table: + +(1) If there is a one-to-one correspondence between the conceptual rows + of this table and an existing table, then the AUGMENTS clause + should be used. + +(2) Otherwise, if there is a sparse relationship between the conceptual + rows of this table and an existing table, then an INDEX clause + should be used which is identical to that in the existing table. + For example, the relationship between RFC 1573's ifTable and a + media-specific MIB which extends the ifTable for a specific media + (e.g., the dot3Table in RFC 1650), is a sparse relationship. + +(3) Otherwise, if no existing objects have the required syntax and + semantics, then auxiliary objects should be defined within the + conceptual row for the new table, and those objects should be used + within the INDEX clause for the conceptual row. + +7.9. Mapping of the DEFVAL clause + + The DEFVAL clause, which need not be present, defines an acceptable + default value which may be used at the discretion of a SNMPv2 entity + acting in an agent role when an object instance is created. + + + +SNMPv2 Working Group Standards Track [Page 24] + +RFC 1902 SMI for SNMPv2 January 1996 + + + During conceptual row creation, if an instance of a columnar object + is not present as one of the operands in the correspondent management + protocol set operation, then the value of the DEFVAL clause, if + present, indicates an acceptable default value that a SNMPv2 entity + acting in an agent role might use. + + The value of the DEFVAL clause must, of course, correspond to the + SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER, + then it must be expressed as a single ASN.1 identifier, and not as a + collection of sub-identifiers. + + Note that if an operand to the management protocol set operation is + an instance of a read-only object, then the error `notWritable' [6] + will be returned. As such, the DEFVAL clause can be used to provide + an acceptable default value that a SNMPv2 entity acting in an agent + role might use. + + By way of example, consider the following possible DEFVAL clauses: + + ObjectSyntax DEFVAL clause + ---------------- ------------ + Integer32 DEFVAL { 1 } + -- same for Gauge32, TimeTicks, Unsigned32 + INTEGER DEFVAL { valid } -- enumerated value + OCTET STRING DEFVAL { 'ffffffffffff'H } + OBJECT IDENTIFIER DEFVAL { sysDescr } + BITS DEFVAL { { primary, secondary } } + -- enumerated values that are set + IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21 + + Object types with SYNTAX of Counter32 and Counter64 may not have + DEFVAL clauses, since they do not have defined initial values. + However, it is recommended that they be initialized to zero. + +7.10. Mapping of the OBJECT-TYPE value + + The value of an invocation of the OBJECT-TYPE macro is the name of + the object, which is an OBJECT IDENTIFIER, an administratively + assigned name. + + When an OBJECT IDENTIFIER is assigned to an object: + +(1) If the object corresponds to a conceptual table, then only a single + assignment, that for a conceptual row, is present immediately + beneath that object. The administratively assigned name for the + conceptual row object is derived by appending a sub-identifier of + "1" to the administratively assigned name for the conceptual table. + + + + +SNMPv2 Working Group Standards Track [Page 25] + +RFC 1902 SMI for SNMPv2 January 1996 + + +(2) If the object corresponds to a conceptual row, then at least one + assignment, one for each column in the conceptual row, is present + beneath that object. The administratively assigned name for each + column is derived by appending a unique, positive sub-identifier to + the administratively assigned name for the conceptual row. + +(3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the + object may be assigned. + + Note that the final sub-identifier of any administratively assigned + name for an object shall be positive. A zero-valued final sub- + identifier is reserved for future use. + + Further note that although conceptual tables and rows are given + administratively assigned names, these conceptual objects may not be + manipulated in aggregate form by the management protocol. + +7.11. Usage Example + + Consider how one might define a conceptual table and its + subordinates. (This example uses the RowStatus textual convention + defined in [3].) + +evalSlot OBJECT-TYPE + SYNTAX INTEGER + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The index number of the first unassigned entry in the + evaluation table. + + A management station should create new entries in the + evaluation table using this algorithm: first, issue a + management protocol retrieval operation to determine the + value of evalSlot; and, second, issue a management protocol + set operation to create an instance of the evalStatus object + setting its value to createAndGo(4) or createAndWait(5). If + this latter operation succeeds, then the management station + may continue modifying the instances corresponding to the + newly created conceptual row, without fear of collision with + other management stations." + ::= { eval 1 } + +evalTable OBJECT-TYPE + SYNTAX SEQUENCE OF EvalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + + + +SNMPv2 Working Group Standards Track [Page 26] + +RFC 1902 SMI for SNMPv2 January 1996 + + + "The (conceptual) evaluation table." + ::= { eval 2 } + +evalEntry OBJECT-TYPE + SYNTAX EvalEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the evaluation table." + INDEX { evalIndex } + ::= { evalTable 1 } + +EvalEntry ::= + SEQUENCE { + evalIndex Integer32, + evalString DisplayString, + evalValue Integer32, + evalStatus RowStatus + } + +evalIndex OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The auxiliary variable used for identifying instances of + the columnar objects in the evaluation table." + ::= { evalEntry 1 } + +evalString OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The string to evaluate." + ::= { evalEntry 2 } + +evalValue OBJECT-TYPE + SYNTAX Integer32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value when evalString was last executed." + DEFVAL { 0 } + ::= { evalEntry 3 } + +evalStatus OBJECT-TYPE + SYNTAX RowStatus + + + +SNMPv2 Working Group Standards Track [Page 27] + +RFC 1902 SMI for SNMPv2 January 1996 + + + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The status column used for creating, modifying, and + deleting instances of the columnar objects in the evaluation + table." + DEFVAL { active } + ::= { evalEntry 4 } + +8. Mapping of the NOTIFICATION-TYPE macro + + The NOTIFICATION-TYPE macro is used to define the information + contained within an unsolicited transmission of management + information (i.e., within either a SNMPv2-Trap-PDU or InformRequest- + PDU). It should be noted that the expansion of the NOTIFICATION-TYPE + macro is something which conceptually happens during implementation + and not during run-time. + +8.1. Mapping of the OBJECTS clause + + The OBJECTS clause, which need not be present, defines the ordered + sequence of MIB object types which are contained within every + instance of the notification. An object type specified in this + clause may not have an MAX-ACCESS clause of "not-accessible". + +8.2. Mapping of the STATUS clause + + The STATUS clause, which must be present, indicates whether this + definition is current or historic. + + The values "current", and "obsolete" are self-explanatory. The + "deprecated" value indicates that the definition is obsolete, but + that an implementor may wish to support the notification to foster + interoperability with older implementations. + +8.3. Mapping of the DESCRIPTION clause + + The DESCRIPTION clause, which must be present, contains a textual + definition of the notification which provides all semantic + definitions necessary for implementation, and should embody any + information which would otherwise be communicated in any ASN.1 + commentary annotations associated with the notification. In + particular, the DESCRIPTION clause should document which instances of + the objects mentioned in the OBJECTS clause should be contained + within notifications of this type. + + + + + + +SNMPv2 Working Group Standards Track [Page 28] + +RFC 1902 SMI for SNMPv2 January 1996 + + +8.4. Mapping of the REFERENCE clause + + The REFERENCE clause, which need not be present, contains a textual + cross-reference to a notification defined in some other information + module. This is useful when de-osifying a MIB module produced by + some other organization. + +8.5. Mapping of the NOTIFICATION-TYPE value + + The value of an invocation of the NOTIFICATION-TYPE macro is the name + of the notification, which is an OBJECT IDENTIFIER, an + administratively assigned name. In order to achieve compatibility + with the procedures employed by proxy agents (see Section 3.1.2 of + [7]), the next to last sub-identifier in the name of any newly- + defined notification must have the value zero. + + Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE + macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU, + respectively. + +8.6. Usage Example + + Consider how a linkUp trap might be described: + +linkUp NOTIFICATION-TYPE + OBJECTS { ifIndex } + STATUS current + DESCRIPTION + "A linkUp trap signifies that the SNMPv2 entity, acting in + an agent role, recognizes that one of the communication + links represented in its configuration has come up." + ::= { snmpTraps 4 } + +According to this invocation, the trap authoritatively identified as + + { snmpTraps 4 } + +is used to report a link coming up. + +9. Refined Syntax + + Some macros have clauses which allows syntax to be refined, + specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the + SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT- + CAPABILITIES macros [2]. However, not all refinements of syntax are + appropriate. In particular, the object's primitive or application + type must not be changed. + + + + +SNMPv2 Working Group Standards Track [Page 29] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Further, the following restrictions apply: + + Restrictions to Refinement on + object syntax range enumeration size repertoire + ----------------- ----- ----------- ---- ---------- + INTEGER (1) (2) - - + Integer32 (1) - - - + Unsigned32 (1) - - - + OCTET STRING - - (3) (4) + OBJECT IDENTIFIER - - - - + BITS - (2) - - + IpAddress - - - - + Counter32 - - - - + Counter64 - - - - + Gauge32 (1) - - - + TimeTicks - - - - + +where: + +(1) the range of permitted values may be refined by raising the lower- + bounds, by reducing the upper-bounds, and/or by reducing the + alternative value/range choices; + +(2) the enumeration of named-values may be refined by removing one or + more named-values (note that for BITS, a refinement may cause the + enumerations to no longer be contiguous); + +(3) the size in characters of the value may be refined by raising the + lower-bounds, by reducing the upper-bounds, and/or by reducing the + alternative size choices; or, + +(4) the repertoire of characters in the value may be reduced by further + sub-typing. + + Otherwise no refinements are possible. Further details on sub-typing + are provided in Appendix C. + +10. Extending an Information Module + + As experience is gained with a published information module, it may + be desirable to revise that information module. + + To begin, the invocation of the MODULE-IDENTITY macro should be + updated to include information about the revision. Usually, this + consists of updating the LAST-UPDATED clause and adding a pair of + REVISION and DESCRIPTION clauses. However, other existing clauses in + the invocation may be updated. + + + + +SNMPv2 Working Group Standards Track [Page 30] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Note that the module's label (e.g., "FIZBIN-MIB" from the example in + Section 5.8), is not changed when the information module is revised. + +10.1. Object Assignments + + If any non-editorial change is made to any clause of a object + assignment, then the OBJECT IDENTIFIER value associated with that + object assignment must also be changed, along with its associated + descriptor. + +10.2. Object Definitions + + An object definition may be revised in any of the following ways: + +(1) A SYNTAX clause containing an enumerated INTEGER may have new + enumerations added or existing labels changed. + +(2) A STATUS clause value of "current" may be revised as "deprecated" + or "obsolete". Similarly, a STATUS clause value of "deprecated" + may be revised as "obsolete". + +(3) A DEFVAL clause may be added or updated. + +(4) A REFERENCE clause may be added or updated. + +(5) A UNITS clause may be added. + +(6) A conceptual row may be augmented by adding new columnar objects at + the end of the row. + +(7) Entirely new objects may be defined, named with previously + unassigned OBJECT IDENTIFIER values. + + Otherwise, if the semantics of any previously defined object are + changed (i.e., if a non-editorial change is made to any clause other + those specifically allowed above), then the OBJECT IDENTIFIER value + associated with that object must also be changed. + + Note that changing the descriptor associated with an existing object + is considered a semantic change, as these strings may be used in an + IMPORTS statement. + + Finally, note that if an object has the value of its STATUS clause + changed, then the value of its DESCRIPTION clause should be updated + accordingly. + + + + + + +SNMPv2 Working Group Standards Track [Page 31] + +RFC 1902 SMI for SNMPv2 January 1996 + + +10.3. Notification Definitions + + A notification definition may be revised in any of the following + ways: + + (1) A REFERENCE clause may be added or updated. + + Otherwise, if the semantics of any previously defined notification + are changed (i.e., if a non-editorial change is made to any clause + other those specifically allowed above), then the OBJECT IDENTIFIER + value associated with that notification must also be changed. + + Note that changing the descriptor associated with an existing + notification is considered a semantic change, as these strings may be + used in an IMPORTS statement. + + Finally, note that if an object has the value of its STATUS clause + changed, then the value of its DESCRIPTION clause should be updated + accordingly. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 32] + +RFC 1902 SMI for SNMPv2 January 1996 + + +11. Appendix A: de-OSIfying a MIB module + + There has been an increasing amount of work recently on taking MIBs + defined by other organizations (e.g., the IEEE) and de-osifying them + for use with the Internet-standard network management framework. The + steps to achieve this are straight-forward, though tedious. Of + course, it is helpful to already be experienced in writing MIB + modules for use with the Internet-standard network management + framework. + + The first step is to construct a skeletal MIB module, as shown + earlier in Section 5.8. The next step is to categorize the objects + into groups. Optional objects are not permitted. Thus, when a MIB + module is created, optional objects must be placed in a additional + groups, which, if implemented, all objects in the group must be + implemented. For the first pass, it is wisest to simply ignore any + optional objects in the original MIB: experience shows it is better + to define a core MIB module first, containing only essential objects; + later, if experience demands, other objects can be added. + +11.1. Managed Object Mapping + + Next for each managed object class, determine whether there can exist + multiple instances of that managed object class. If not, then for + each of its attributes, use the OBJECT-TYPE macro to make an + equivalent definition. + + Otherwise, if multiple instances of the managed object class can + exist, then define a conceptual table having conceptual rows each + containing a columnar object for each of the managed object class's + attributes. If the managed object class is contained within the + containment tree of another managed object class, then the assignment + of an object is normally required for each of the "distinguished + attributes" of the containing managed object class. If they do not + already exist within the MIB module, then they can be added via the + definition of additional columnar objects in the conceptual row + corresponding to the contained managed object class. + + In defining a conceptual row, it is useful to consider the + optimization of network management operations which will act upon its + columnar objects. In particular, it is wisest to avoid defining more + columnar objects within a conceptual row, than can fit in a single + PDU. As a rule of thumb, a conceptual row should contain no more + than approximately 20 objects. Similarly, or as a way to abide by + the "20 object guideline", columnar objects should be grouped into + tables according to the expected grouping of network management + operations upon them. As such, the content of conceptual rows should + reflect typical access scenarios, e.g., they should be organized + + + +SNMPv2 Working Group Standards Track [Page 33] + +RFC 1902 SMI for SNMPv2 January 1996 + + + along functional lines such as one row for statistics and another row + for parameters, or along usage lines such as commonly-needed objects + versus rarely-needed objects. + + On the other hand, the definition of conceptual rows where the number + of columnar objects used as indexes outnumbers the number used to + hold information, should also be avoided. In particular, the + splitting of a managed object class's attributes into many conceptual + tables should not be used as a way to obtain the same degree of + flexibility/complexity as is often found in MIBs with a myriad of + optionals. + +11.1.1. Mapping to the SYNTAX clause + + When mapping to the SYNTAX clause of the OBJECT-TYPE macro: + +(1) An object with BOOLEAN syntax becomes a TruthValue [3]. + +(2) An object with INTEGER syntax becomes an Integer32. + +(3) An object with ENUMERATED syntax becomes an INTEGER with + enumerations, taking any of the values given which can be + represented with an Integer32. + +(4) An object with BIT STRING syntax having enumerations becomes a BITS + construct. + +(5) An object with BIT STRING syntax but no enumerations becomes an + OCTET STRING. + +(6) An object with a character string syntax becomes either an OCTET + STRING, or a DisplayString [3], depending on the repertoire of the + character string. + +(7) A non-tabular object with a complex syntax, such as REAL or + EXTERNAL, must be decomposed, usually into an OCTET STRING (if + sensible). As a rule, any object with a complicated syntax should + be avoided. + +(8) Tabular objects must be decomposed into rows of columnar objects. + +11.1.2. Mapping to the UNITS clause + + If the description of this managed object defines a unit-basis, then + mapping to this clause is straight-forward. + + + + + + +SNMPv2 Working Group Standards Track [Page 34] + +RFC 1902 SMI for SNMPv2 January 1996 + + +11.1.3. Mapping to the MAX-ACCESS clause + + This is straight-forward. + +11.1.4. Mapping to the STATUS clause + + This is straight-forward. + +11.1.5. Mapping to the DESCRIPTION clause + + This is straight-forward: simply copy the text, making sure that any + embedded double quotation marks are sanitized (i.e., replaced with + single-quotes or removed). + +11.1.6. Mapping to the REFERENCE clause + + This is straight-forward: simply include a textual reference to the + object being mapped, the document which defines the object, and + perhaps a page number in the document. + +11.1.7. Mapping to the INDEX clause + + If necessary, decide how instance-identifiers for columnar objects + are to be formed and define this clause accordingly. + +11.1.8. Mapping to the DEFVAL clause + + Decide if a meaningful default value can be assigned to the object + being mapped, and if so, define the DEFVAL clause accordingly. + +11.2. Action Mapping + + Actions are modeled as read-write objects, in which writing a + particular value results in a state change. (Usually, as a part of + this state change, some action might take place.) + +11.2.1. Mapping to the SYNTAX clause + + Usually the Integer32 syntax is used with a distinguished value + provided for each action that the object provides access to. In + addition, there is usually one other distinguished value, which is + the one returned when the object is read. + +11.2.2. Mapping to the MAX-ACCESS clause + + Always use read-write or read-create. + + + + + +SNMPv2 Working Group Standards Track [Page 35] + +RFC 1902 SMI for SNMPv2 January 1996 + + +11.2.3. Mapping to the STATUS clause + + This is straight-forward. + +11.2.4. Mapping to the DESCRIPTION clause + + This is straight-forward: simply copy the text, making sure that any + embedded double quotation marks are sanitized (i.e., replaced with + single-quotes or removed). + +11.2.5. Mapping to the REFERENCE clause + + This is straight-forward: simply include a textual reference to the + action being mapped, the document which defines the action, and + perhaps a page number in the document. + +11.3. Event Mapping + + Events are modeled as SNMPv2 notifications using NOTIFICATION-TYPE + macro. However, recall that SNMPv2 emphasizes trap-directed polling. + As such, few, and usually no, notifications, need be defined for any + MIB module. + +11.3.1. Mapping to the STATUS clause + + This is straight-forward. + +11.3.2. Mapping to the DESCRIPTION clause + + This is straight-forward: simply copy the text, making sure that any + embedded double quotation marks are sanitized (i.e., replaced with + single-quotes or removed). + +11.3.3. Mapping to the REFERENCE clause + + This is straight-forward: simply include a textual reference to the + notification being mapped, the document which defines the + notification, and perhaps a page number in the document. + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 36] + +RFC 1902 SMI for SNMPv2 January 1996 + + +12. Appendix B: UTC Time Format + + Several clauses defined in this document use the UTC Time format: + + YYMMDDHHMMZ + + where: YY - last two digits of year + MM - month (01 through 12) + DD - day of month (01 through 31) + HH - hours (00 through 23) + MM - minutes (00 through 59) + Z - the character "Z" denotes Greenwich Mean Time (GMT). + + For example, "9502192015Z" represents 8:15pm GMT on 19 February 1995. + +13. Appendix C: Detailed Sub-typing Rules + +13.1. Syntax Rules + + The syntax rules for sub-typing are given below. Note that while + this syntax is based on ASN.1, it includes some extensions beyond + what is allowed in ASN.1, and a number of ASN.1 constructs are not + allowed by this syntax. + + + ::= + | "(" ["|" ]... ")" + + + ::= + | "(" "SIZE" "(" ["|" ]... ")" ")" + + + ::= + | ".." + + + ::= "-" + | + | + | + + where: + is the empty string + is a non-negative integer + is a hexadecimal string (i.e. 'xxxx'H) + is a binary string (i.e. 'xxxx'B) + + + + +SNMPv2 Working Group Standards Track [Page 37] + +RFC 1902 SMI for SNMPv2 January 1996 + + + is further restricted as follows: + - any used in a SIZE clause must be non-negative. + - when a pair of values is specified, the first value + must be less than the second value. + - when multiple ranges are specified, the ranges may + not overlap but may touch. For example, (1..4 | 4..9) + is invalid, and (1..4 | 5..9) is valid. + - the ranges must be a subset of the maximum range of the + base type. + +13.2. Examples + +Some examples of legal sub-typing: + + Integer32 (-20..100) + Integer32 (0..100 | 300..500) + Integer32 (300..500 | 0..100) + Integer32 (0 | 2 | 4 | 6 | 8 | 10) + OCTET STRING (SIZE(0..100)) + OCTET STRING (SIZE(0..100 | 300..500)) + OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10)) + +Some examples of illegal sub-typing: + + Integer32 (150..100) -- first greater than second + Integer32 (0..100 | 50..500) -- ranges overlap + Integer32 (0 | 2 | 0 ) -- value duplicated + Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed + Integer32 ((SIZE (0..34)) -- must not use SIZE + OCTET STRING (0..100) -- must use SIZE + OCTET STRING (SIZE(-10..100)) -- negative SIZE + +13.3. Rules for Textual Conventions + + Sub-typing of Textual Conventions (see [3]) is allowed but must be + valid. In particular, each range specified for the textual + convention must be a subset of a range specified for the base type. + For example, + + Tc1 ::= INTEGER (1..10 | 11..20) + Tc2 ::= Tc1 (2..10 | 12..15) -- is valid + Tc3 ::= Tc1 (4..8) -- is valid + Tc4 ::= Tc1 (8..12) -- is invalid + +14. Security Considerations + + Security issues are not discussed in this memo. + + + + +SNMPv2 Working Group Standards Track [Page 38] + +RFC 1902 SMI for SNMPv2 January 1996 + + +15. Editor's Address + + Keith McCloghrie + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + US + + Phone: +1 408 526 5260 + EMail: kzm@cisco.com + +16. Acknowledgements + + This document is the result of significant work by the four major + contributors: + + Jeffrey D. Case (SNMP Research, case@snmp.com) + Keith McCloghrie (Cisco Systems, kzm@cisco.com) + Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) + Steven Waldbusser (International Network Services, stevew@uni.ins.com) + + In addition, the contributions of the SNMPv2 Working Group are + acknowledged. In particular, a special thanks is extended for the + contributions of: + + Alexander I. Alten (Novell) + Dave Arneson (Cabletron) + Uri Blumenthal (IBM) + Doug Book (Chipcom) + Kim Curran (Bell-Northern Research) + Jim Galvin (Trusted Information Systems) + Maria Greene (Ascom Timeplex) + Iain Hanson (Digital) + Dave Harrington (Cabletron) + Nguyen Hien (IBM) + Jeff Johnson (Cisco Systems) + Michael Kornegay (Object Quest) + Deirdre Kostick (AT&T Bell Labs) + David Levi (SNMP Research) + Daniel Mahoney (Cabletron) + Bob Natale (ACE*COMM) + Brian O'Keefe (Hewlett Packard) + Andrew Pearson (SNMP Research) + Dave Perkins (Peer Networks) + Randy Presuhn (Peer Networks) + Aleksey Romanov (Quality Quorum) + Shawn Routhier (Epilogue) + Jon Saperia (BGS Systems) + + + +SNMPv2 Working Group Standards Track [Page 39] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Bob Stewart (Cisco Systems, bstewart@cisco.com), chair + Kaj Tesink (Bellcore) + Glenn Waters (Bell-Northern Research) + Bert Wijnen (IBM) + +17. References + +[1] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization. International + Standard 8824, (December, 1987). + +[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Conformance Statements for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1904, January 1996. + +[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + +[4] Information processing systems - Open Systems Interconnection - + Specification of Basic Encoding Rules for Abstract Syntax Notation + One (ASN.1), International Organization for Standardization. + International Standard 8825, (December, 1987). + +[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Management Information Base for Version 2 of the + Simple Network Management Protocol (SNMPv2)", RFC 1907, + January 1996. + +[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Protocol Operations for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + +[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Coexistence between Version 1 and Version 2 of the + Internet-standard Network Management Framework", RFC 1908, + January 1996. + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 40] + diff --git a/doc/rfc/rfc1905.txt b/doc/rfc/rfc1905.txt new file mode 100644 index 0000000000..d6217d3087 --- /dev/null +++ b/doc/rfc/rfc1905.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group SNMPv2 Working Group +Request for Comments: 1905 J. Case +Obsoletes: 1448 SNMP Research, Inc. +Category: Standards Track K. McCloghrie + Cisco Systems, Inc. + M. Rose + Dover Beach Consulting, Inc. + S. Waldbusser + International Network Services + January 1996 + + + Protocol Operations + for Version 2 of the + Simple Network Management Protocol (SNMPv2) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Introduction + + A 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 + authentication, authorization, access control, and privacy policies. + + Management stations execute management applications which monitor and + control managed elements. Managed elements are devices such as + hosts, routers, terminal servers, etc., which are monitored and + controlled via access to their 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) [1], termed the Structure of + Management Information (SMI) [2]. + + + + + + +SNMPv2 Working Group Standards Track [Page 1] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + The management protocol, version 2 of the Simple Network 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 this document, Protocol Operations for SNMPv2, + to define the operations of the protocol with respect to the sending + and receiving of the PDUs. + +1.1. A Note on Terminology + + For the purpose of exposition, the original Internet-standard Network + Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD + 15), and 1212 (STD 16), is termed the SNMP version 1 framework + (SNMPv1). The current framework is termed the SNMP version 2 + framework (SNMPv2). + +2. Overview + +2.1. Roles of Protocol Entities + + A SNMPv2 entity may operate in a manager role or an agent role. + + A SNMPv2 entity acts in an agent role when it performs SNMPv2 + management operations in response to received SNMPv2 protocol + messages (other than an inform notification) or when it sends trap + notifications. + + A SNMPv2 entity acts in a manager role when it initiates SNMPv2 + management operations by the generation of SNMPv2 protocol messages + or when it performs SNMPv2 management operations in response to + received trap or inform notifications. + + A SNMPv2 entity may support either or both roles, as dictated by its + implementation and configuration. Further, a SNMPv2 entity can also + act in the role of a proxy agent, in which it appears to be acting in + an agent role, but satisfies management requests by acting in a + manager role with a remote entity. + +2.2. Management Information + + The term, variable, refers to an instance of a non-aggregate object + type defined according to the conventions set forth in the SMI [2] or + the textual conventions based on the SMI [3]. The term, variable + binding, normally refers to the pairing of the name of a variable and + + + +SNMPv2 Working Group Standards Track [Page 2] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + its associated value. However, if certain kinds of exceptional + conditions occur during processing of a retrieval request, a variable + binding will pair a name and an indication of that exception. + + A variable-binding list is a simple list of variable bindings. + + The name of a variable is an OBJECT IDENTIFIER which is the + concatenation of the OBJECT IDENTIFIER of the corresponding object- + type together with an OBJECT IDENTIFIER fragment identifying the + instance. The OBJECT IDENTIFIER of the corresponding object-type is + called the OBJECT IDENTIFIER prefix of the variable. + +2.3. Access to Management Information + + Three types of access to management information are provided by the + protocol. One type is a request-response interaction, in which a + SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2 + entity, acting in an agent role, and the latter SNMPv2 entity then + responds to the request. This type is used to retrieve or modify + management information associated with the managed device. + + A second type is also a request-response interaction, in which a + SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2 + entity, also acting in a manager role, and the latter SNMPv2 entity + then responds to the request. This type is used to notify a SNMPv2 + entity, acting in a manager role, of management information + associated with another SNMPv2 entity, also acting in a manager role. + + The third type of access is an unconfirmed interaction, in which a + SNMPv2 entity, acting in an agent role, sends a unsolicited message, + termed a trap, to a SNMPv2 entity, acting in a manager role, and no + response is returned. This type is used to notify a SNMPv2 entity, + acting in a manager role, of an exceptional situation, which has + resulted in changes to management information associated with the + managed device. + +2.4. Retransmission of Requests + + For all types of request in this protocol, the receiver is required + under normal circumstances, to generate and transmit a response to + the originator of the request. Whether or not a request should be + retransmitted if no corresponding response is received in an + appropriate time interval, is at the discretion of the application + originating the request. This will normally depend on the urgency of + the request. However, such an application needs to act responsibly + in respect to the frequency and duration of re-transmissions. + + + + + +SNMPv2 Working Group Standards Track [Page 3] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + +2.5. Message Sizes + + The maximum size of a SNMPv2 message is limited to the minimum of: + +(1) the maximum message size which the destination SNMPv2 entity can + accept; and, + +(2) the maximum message size which the source SNMPv2 entity can + generate. + + The former may be known on a per-recipient basis; and in the absence + of such knowledge, is indicated by transport domain used when sending + the message. The latter is imposed by implementation-specific local + constraints. + + Each transport mapping for the SNMPv2 indicates the minimum message + size which a SNMPv2 implementation must be able to produce or + consume. Although implementations are encouraged to support larger + values whenever possible, a conformant implementation must never + generate messages larger than allowed by the receiving SNMPv2 entity. + + One of the aims of the GetBulkRequest-PDU, specified in this + protocol, is to minimize the number of protocol exchanges required to + retrieve a large amount of management information. As such, this PDU + type allows a SNMPv2 entity acting in a manager role to request that + the response be as large as possible given the constraints on message + sizes. These constraints include the limits on the size of messages + which the SNMPv2 entity acting in an agent role can generate, and the + SNMPv2 entity acting in a manager role can receive. + + However, it is possible that such maximum sized messages may be + larger than the Path MTU of the path across the network traversed by + the messages. In this situation, such messages are subject to + fragmentation. Fragmentation is generally considered to be harmful + [4], since among other problems, it leads to a decrease in the + reliability of the transfer of the messages. Thus, a SNMPv2 entity + which sends a GetBulkRequest-PDU must take care to set its parameters + accordingly, so as to reduce the risk of fragmentation. In + particular, under conditions of network stress, only small values + should be used for max-repetitions. + +2.6. Transport Mappings + + It is important to note that the exchange of SNMPv2 messages requires + only an unreliable datagram service, with every message being + entirely and independently contained in a single transport datagram. + Specific transport mappings and encoding rules are specified + elsewhere [5]. However, the preferred mapping is the use of the User + + + +SNMPv2 Working Group Standards Track [Page 4] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + Datagram Protocol [6]. + +3. Definitions + + SNMPv2-PDU DEFINITIONS ::= BEGIN + + IMPORTS + ObjectName, ObjectSyntax, Integer32 + FROM SNMPv2-SMI; + + + -- protocol data units + + PDUs ::= + CHOICE { + get-request + GetRequest-PDU, + + get-next-request + GetNextRequest-PDU, + + get-bulk-request + GetBulkRequest-PDU, + + response + Response-PDU, + + set-request + SetRequest-PDU, + + inform-request + InformRequest-PDU, + + snmpV2-trap + SNMPv2-Trap-PDU, + + report + Report-PDU, + } + + + -- PDUs + + GetRequest-PDU ::= + [0] + IMPLICIT PDU + + GetNextRequest-PDU ::= + + + +SNMPv2 Working Group Standards Track [Page 5] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + [1] + IMPLICIT PDU + + Response-PDU ::= + [2] + IMPLICIT PDU + + SetRequest-PDU ::= + [3] + IMPLICIT PDU + + -- [4] is obsolete + + GetBulkRequest-PDU ::= + [5] + IMPLICIT BulkPDU + + InformRequest-PDU ::= + [6] + IMPLICIT PDU + + SNMPv2-Trap-PDU ::= + [7] + IMPLICIT PDU + + -- Usage and precise semantics of Report-PDU are not presently + -- defined. Any SNMP administrative framework making use of + -- this PDU must define its usage and semantics. + Report-PDU ::= + [8] + IMPLICIT PDU + + max-bindings + INTEGER ::= 2147483647 + + PDU ::= + SEQUENCE { + request-id + Integer32, + + error-status -- sometimes ignored + INTEGER { + noError(0), + tooBig(1), + noSuchName(2), -- for proxy compatibility + badValue(3), -- for proxy compatibility + readOnly(4), -- for proxy compatibility + genErr(5), + + + +SNMPv2 Working Group Standards Track [Page 6] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + noAccess(6), + wrongType(7), + wrongLength(8), + wrongEncoding(9), + wrongValue(10), + noCreation(11), + inconsistentValue(12), + resourceUnavailable(13), + commitFailed(14), + undoFailed(15), + authorizationError(16), + notWritable(17), + inconsistentName(18) + }, + + error-index -- sometimes ignored + INTEGER (0..max-bindings), + + variable-bindings -- values are sometimes ignored + VarBindList + } + + + BulkPDU ::= -- MUST be identical in + SEQUENCE { -- structure to PDU + request-id + Integer32, + + non-repeaters + INTEGER (0..max-bindings), + + max-repetitions + INTEGER (0..max-bindings), + + variable-bindings -- values are ignored + VarBindList + } + + + -- variable binding + + VarBind ::= + SEQUENCE { + name + ObjectName, + + CHOICE { + value + + + +SNMPv2 Working Group Standards Track [Page 7] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + ObjectSyntax, + + unSpecified -- in retrieval requests + NULL, + + -- exceptions in responses + noSuchObject[0] + IMPLICIT NULL, + + noSuchInstance[1] + IMPLICIT NULL, + + endOfMibView[2] + IMPLICIT NULL + } + } + + + -- variable-binding list + + VarBindList ::= + SEQUENCE (SIZE (0..max-bindings)) OF + VarBind + + + END + + +4. Protocol Specification + +4.1. Common Constructs + + The value of the request-id field in a Response-PDU takes the value + of the request-id field in the request PDU to which it is a response. + By use of the request-id value, a SNMPv2 application can distinguish + the (potentially multiple) outstanding requests, and thereby + correlate incoming responses with outstanding requests. In cases + where an unreliable datagram service is used, the request-id also + provides a simple means of identifying messages duplicated by the + network. Use of the same request-id on a retransmission of a request + allows the response to either the original transmission or the + retransmission to satisfy the request. However, in order to + calculate the round trip time for transmission and processing of a + request-response transaction, the SNMPv2 application needs to use a + different request-id value on a retransmitted request. The latter + strategy is recommended for use in the majority of situations. + + + + + +SNMPv2 Working Group Standards Track [Page 8] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + A non-zero value of the error-status field in a Response-PDU is used + to indicate that an exception occurred to prevent the processing of + the request. In these cases, a non-zero value of the Response-PDU's + error-index field provides additional information by identifying + which variable binding in the list caused the exception. A variable + binding is identified by its index value. The first variable binding + in a variable-binding list is index one, the second is index two, + etc. + + SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub- + identifiers, where each sub-identifier has a maximum value of 2**32- + 1. + +4.2. PDU Processing + + It is mandatory that all SNMPv2 entities acting in an agent role be + able to generate the following PDU types: Response-PDU and SNMPv2- + Trap-PDU; further, all such implementations must be able to receive + the following PDU types: GetRequest-PDU, GetNextRequest-PDU, + GetBulkRequest-PDU, and SetRequest-PDU. + + It is mandatory that all SNMPv2 entities acting in a manager role be + able to generate the following PDU types: GetRequest-PDU, + GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, + InformRequest-PDU, and Response-PDU; further, all such + implementations must be able to receive the following PDU types: + Response-PDU, SNMPv2-Trap-PDU, + + InformRequest-PDU; + + In the elements of procedure below, any field of a PDU which is not + referenced by the relevant procedure is ignored by the receiving + SNMPv2 entity. However, all components of a PDU, including those + whose values are ignored by the receiving SNMPv2 entity, must have + valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the + GetRequest-PDU) are concerned only with the name of a variable and + not its value. In this case, the value portion of the variable + binding is ignored by the receiving SNMPv2 entity. The unSpecified + value is defined for use as the value portion of such bindings. + + On generating a management communication, the message "wrapper" to + encapsulate the PDU is generated according to the "Elements of + Procedure" of the administrative framework in use is followed. While + the definition of "max-bindings" does impose an upper-bound on the + number of variable bindings, in practice, the size of a message is + limited only by constraints on the maximum message size -- it is not + limited by the number of variable bindings. + + + + +SNMPv2 Working Group Standards Track [Page 9] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + On receiving a management communication, the "Elements of Procedure" + of the administrative framework in use is followed, and if those + procedures indicate that the operation contained within the message + is to be performed locally, then those procedures also indicate the + MIB view which is visible to the operation. + +4.2.1. The GetRequest-PDU + + A GetRequest-PDU is generated and transmitted at the request of a + SNMPv2 application. + + Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity + processes each variable binding in the variable-binding list to + produce a Response-PDU. All fields of the Response-PDU have the same + values as the corresponding fields of the received request except as + indicated below. Each variable binding is processed as follows: + +(1) If the variable binding's name exactly matches the name of a + variable accessible by this request, then the variable binding's + value field is set to the value of the named variable. + +(2) Otherwise, if the variable binding's name does not have an OBJECT + IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER + prefix of any (potential) variable accessible by this request, then + its value field is set to `noSuchObject'. + +(3) Otherwise, the variable binding's value field is set to + `noSuchInstance'. + + If the processing of any variable binding fails for a reason other + than listed above, then the Response-PDU is re-formatted with the + same values in its request-id and variable-bindings fields as the + received GetRequest-PDU, with the value of its error-status field set + to `genErr', and the value of its error-index field is set to the + index of the failed variable binding. + + Otherwise, the value of the Response-PDU's error-status field is set + to `noError', and the value of its error-index field is zero. + + The generated Response-PDU is then encapsulated into a message. If + the size of the resultant message is less than or equal to both a + local constraint and the maximum message size of the originator, it + is transmitted to the originator of the GetRequest-PDU. + + Otherwise, an alternate Response-PDU is generated. This alternate + Response-PDU is formatted with the same value in its request-id field + as the received GetRequest-PDU, with the value of its error-status + field set to `tooBig', the value of its error-index field set to + + + +SNMPv2 Working Group Standards Track [Page 10] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + zero, and an empty variable-bindings field. This alternate + Response-PDU is then encapsulated into a message. If the size of the + resultant message is less than or equal to both a local constraint + and the maximum message size of the originator, it is transmitted to + the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops + [9] counter is incremented and the resultant message is discarded. + +4.2.2. The GetNextRequest-PDU + + A GetNextRequest-PDU is generated and transmitted at the request of a + SNMPv2 application. + + Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity + processes each variable binding in the variable-binding list to + produce a Response-PDU. All fields of the Response-PDU have the same + values as the corresponding fields of the received request except as + indicated below. Each variable binding is processed as follows: + +(1) The variable is located which is in the lexicographically ordered + list of the names of all variables which are accessible by this + request and whose name is the first lexicographic successor of the + variable binding's name in the incoming GetNextRequest-PDU. The + corresponding variable binding's name and value fields in the + Response-PDU are set to the name and value of the located variable. + +(2) If the requested variable binding's name does not lexicographically + precede the name of any variable accessible by this request, i.e., + there is no lexicographic successor, then the corresponding + variable binding produced in the Response-PDU has its value field + set to `endOfMibView', and its name field set to the variable + binding's name in the request. + + If the processing of any variable binding fails for a reason other + than listed above, then the Response-PDU is re-formatted with the + same values in its request-id and variable-bindings fields as the + received GetNextRequest-PDU, with the value of its error-status field + set to `genErr', and the value of its error-index field is set to the + index of the failed variable binding. + + Otherwise, the value of the Response-PDU's error-status field is set + to `noError', and the value of its error-index field is zero. + + The generated Response-PDU is then encapsulated into a message. If + the size of the resultant message is less than or equal to both a + local constraint and the maximum message size of the originator, it + is transmitted to the originator of the GetNextRequest-PDU. + + + + + +SNMPv2 Working Group Standards Track [Page 11] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + Otherwise, an alternate Response-PDU is generated. This alternate + Response-PDU is formatted with the same values in its request-id + field as the received GetNextRequest-PDU, with the value of its + error-status field set to `tooBig', the value of its error-index + field set to zero, and an empty variable-bindings field. This + alternate Response-PDU is then encapsulated into a message. If the + size of the resultant message is less than or equal to both a local + constraint and the maximum message size of the originator, it is + transmitted to the originator of the GetNextRequest-PDU. Otherwise, + the snmpSilentDrops [9] counter is incremented and the resultant + message is discarded. + +4.2.2.1. Example of Table Traversal + + An important use of the GetNextRequest-PDU is the traversal of + conceptual tables of information within a MIB. The semantics of this + type of request, together with the method of identifying individual + instances of objects in the MIB, provides access to related objects + in the MIB as if they enjoyed a tabular organization. + + In the protocol exchange sketched below, a SNMPv2 application + retrieves the media-dependent physical address and the address- + mapping type for each entry in the IP net-to-media Address + Translation Table [7] of a particular network element. It also + retrieves the value of sysUpTime [9], at which the mappings existed. + Suppose that the agent's IP net-to-media table has three entries: + + Interface-Number Network-Address Physical-Address Type + + 1 10.0.0.51 00:00:10:01:23:45 static + 1 9.2.3.4 00:00:10:54:32:10 dynamic + 2 10.0.0.15 00:00:10:98:76:54 dynamic + + The SNMPv2 entity acting in a manager role begins by sending a + GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values + as the requested variable names: + + GetNextRequest ( sysUpTime, + ipNetToMediaPhysAddress, + ipNetToMediaType ) + + The SNMPv2 entity acting in an agent role responds with a Response- + PDU: + + Response (( sysUpTime.0 = "123456" ), + ( ipNetToMediaPhysAddress.1.9.2.3.4 = + "000010543210" ), + ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) + + + +SNMPv2 Working Group Standards Track [Page 12] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + The SNMPv2 entity acting in a manager role continues with: + + GetNextRequest ( sysUpTime, + ipNetToMediaPhysAddress.1.9.2.3.4, + ipNetToMediaType.1.9.2.3.4 ) + + The SNMPv2 entity acting in an agent role responds with: + + Response (( sysUpTime.0 = "123461" ), + ( ipNetToMediaPhysAddress.1.10.0.0.51 = + "000010012345" ), + ( ipNetToMediaType.1.10.0.0.51 = "static" )) + + The SNMPv2 entity acting in a manager role continues with: + + GetNextRequest ( sysUpTime, + ipNetToMediaPhysAddress.1.10.0.0.51, + ipNetToMediaType.1.10.0.0.51 ) + + The SNMPv2 entity acting in an agent role responds with: + + Response (( sysUpTime.0 = "123466" ), + ( ipNetToMediaPhysAddress.2.10.0.0.15 = + "000010987654" ), + ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) + + The SNMPv2 entity acting in a manager role continues with: + + GetNextRequest ( sysUpTime, + ipNetToMediaPhysAddress.2.10.0.0.15, + ipNetToMediaType.2.10.0.0.15 ) + + As there are no further entries in the table, the SNMPv2 entity + acting in an agent role responds with the variables that are next in + the lexicographical ordering of the accessible object names, for + example: + + Response (( sysUpTime.0 = "123471" ), + ( ipNetToMediaNetAddress.1.9.2.3.4 = + "9.2.3.4" ), + ( ipRoutingDiscards.0 = "2" )) + + This response signals the end of the table to the SNMPv2 entity + acting in a manager role. + + + + + + + +SNMPv2 Working Group Standards Track [Page 13] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + +4.2.3. The GetBulkRequest-PDU + + A GetBulkRequest-PDU is generated and transmitted at the request of a + SNMPv2 application. The purpose of the GetBulkRequest-PDU is to + request the transfer of a potentially large amount of data, + including, but not limited to, the efficient and rapid retrieval of + large tables. + + Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity + processes each variable binding in the variable-binding list to + produce a Response-PDU with its request-id field having the same + value as in the request. Processing begins by examining the values + in the non-repeaters and max-repetitions fields. If the value in the + non-repeaters field is less than zero, then the value of the field is + set to zero. Similarly, if the value in the max-repetitions field is + less than zero, then the value of the field is set to zero. + + For the GetBulkRequest-PDU type, the successful processing of each + variable binding in the request generates zero or more variable + bindings in the Response-PDU. That is, the one-to-one mapping + between the variable bindings of the GetRequest-PDU, GetNextRequest- + PDU, and SetRequest-PDU types and the resultant Response-PDUs does + not apply for the mapping between the variable bindings of a + GetBulkRequest-PDU and the resultant Response-PDU. + + The values of the non-repeaters and max-repetitions fields in the + request specify the processing requested. One variable binding in + the Response-PDU is requested for the first N variable bindings in + the request and M variable bindings are requested for each of the R + remaining variable bindings in the request. Consequently, the total + number of requested variable bindings communicated by the request is + given by N + (M * R), where N is the minimum of: a) the value of the + non-repeaters field in the request, and b) the number of variable + bindings in the request; M is the value of the max-repetitions field + in the request; and R is the maximum of: a) number of variable + bindings in the request - N, and b) zero. + + The receiving SNMPv2 entity produces a Response-PDU with up to the + total number of requested variable bindings communicated by the + request. The request-id shall have the same value as the received + GetBulkRequest-PDU. + + If N is greater than zero, the first through the (N)-th variable + bindings of the Response-PDU are each produced as follows: + +(1) The variable is located which is in the lexicographically ordered + list of the names of all variables which are accessible by this + request and whose name is the first lexicographic successor of the + + + +SNMPv2 Working Group Standards Track [Page 14] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + variable binding's name in the incoming GetBulkRequest-PDU. The + corresponding variable binding's name and value fields in the + Response-PDU are set to the name and value of the located variable. + +(2) If the requested variable binding's name does not lexicographically + precede the name of any variable accessible by this request, i.e., + there is no lexicographic successor, then the corresponding + variable binding produced in the Response-PDU has its value field + set to `endOfMibView', and its name field set to the variable + binding's name in the request. + + If M and R are non-zero, the (N + 1)-th and subsequent variable + bindings of the Response-PDU are each produced in a similar manner. + For each iteration i, such that i is greater than zero and less than + or equal to M, and for each repeated variable, r, such that r is + greater than zero and less than or equal to R, the (N + ( (i-1) * R ) + + r)-th variable binding of the Response-PDU is produced as follows: + +(1) The variable which is in the lexicographically ordered list of the + names of all variables which are accessible by this request and + whose name is the (i)-th lexicographic successor of the (N + r)-th + variable binding's name in the incoming GetBulkRequest-PDU is + located and the variable binding's name and value fields are set to + the name and value of the located variable. + +(2) If there is no (i)-th lexicographic successor, then the + corresponding variable binding produced in the Response-PDU has its + value field set to `endOfMibView', and its name field set to either + the last lexicographic successor, or if there are no lexicographic + successors, to the (N + r)-th variable binding's name in the + request. + + While the maximum number of variable bindings in the Response-PDU is + bounded by N + (M * R), the response may be generated with a lesser + number of variable bindings (possibly zero) for either of three + reasons. + +(1) If the size of the message encapsulating the Response-PDU + containing the requested number of variable bindings would be + greater than either a local constraint or the maximum message size + of the originator, then the response is generated with a lesser + number of variable bindings. This lesser number is the ordered set + of variable bindings with some of the variable bindings at the end + of the set removed, such that the size of the message encapsulating + the Response-PDU is approximately equal to but no greater than + either a local constraint or the maximum message size of the + originator. Note that the number of variable bindings removed has + no relationship to the values of N, M, or R. + + + +SNMPv2 Working Group Standards Track [Page 15] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + +(2) The response may also be generated with a lesser number of variable + bindings if for some value of iteration i, such that i is greater + than zero and less than or equal to M, that all of the generated + variable bindings have the value field set to the `endOfMibView'. + In this case, the variable bindings may be truncated after the (N + + (i * R))-th variable binding. + +(3) In the event that the processing of a request with many repetitions + requires a significantly greater amount of processing time than a + normal request, then an agent may terminate the request with less + than the full number of repetitions, providing at least one + repetition is completed. + + If the processing of any variable binding fails for a reason other + than listed above, then the Response-PDU is re-formatted with the + same values in its request-id and variable-bindings fields as the + received GetBulkRequest-PDU, with the value of its error-status field + set to `genErr', and the value of its error-index field is set to the + index of the variable binding in the original request which + corresponds to the failed variable binding. + + Otherwise, the value of the Response-PDU's error-status field is set + to `noError', and the value of its error-index field to zero. + + The generated Response-PDU (possibly with an empty variable-bindings + field) is then encapsulated into a message. If the size of the + resultant message is less than or equal to both a local constraint + and the maximum message size of the originator, it is transmitted to + the originator of the GetBulkRequest-PDU. Otherwise, the + snmpSilentDrops [9] counter is incremented and the resultant message + is discarded. + +4.2.3.1. Another Example of Table Traversal + + This example demonstrates how the GetBulkRequest-PDU can be used as + an alternative to the GetNextRequest-PDU. The same traversal of the + IP net-to-media table as shown in Section 4.2.2.1 is achieved with + fewer exchanges. + + The SNMPv2 entity acting in a manager role begins by sending a + GetBulkRequest-PDU with the modest max-repetitions value of 2, and + containing the indicated OBJECT IDENTIFIER values as the requested + variable names: + + GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] + ( sysUpTime, + ipNetToMediaPhysAddress, + ipNetToMediaType ) + + + +SNMPv2 Working Group Standards Track [Page 16] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + The SNMPv2 entity acting in an agent role responds with a Response-PDU: + + Response (( sysUpTime.0 = "123456" ), + ( ipNetToMediaPhysAddress.1.9.2.3.4 = + "000010543210" ), + ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), + ( ipNetToMediaPhysAddress.1.10.0.0.51 = + "000010012345" ), + ( ipNetToMediaType.1.10.0.0.51 = "static" )) + + The SNMPv2 entity acting in a manager role continues with: + + GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] + ( sysUpTime, + ipNetToMediaPhysAddress.1.10.0.0.51, + ipNetToMediaType.1.10.0.0.51 ) + + The SNMPv2 entity acting in an agent role responds with: + + Response (( sysUpTime.0 = "123466" ), + ( ipNetToMediaPhysAddress.2.10.0.0.15 = + "000010987654" ), + ( ipNetToMediaType.2.10.0.0.15 = + "dynamic" ), + ( ipNetToMediaNetAddress.1.9.2.3.4 = + "9.2.3.4" ), + ( ipRoutingDiscards.0 = "2" )) + + This response signals the end of the table to the SNMPv2 entity + acting in a manager role. + +4.2.4. The Response-PDU + + The Response-PDU is generated by a SNMPv2 entity only upon receipt of + a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, + SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this + document. + + If the error-status field of the Response-PDU is non-zero, the value + fields of the variable bindings in the variable binding list are + ignored. + + If both the error-status field and the error-index field of the + Response-PDU are non-zero, then the value of the error-index field is + the index of the variable binding (in the variable-binding list of + the corresponding request) for which the request failed. The first + variable binding in a request's variable-binding list is index one, + the second is index two, etc. + + + +SNMPv2 Working Group Standards Track [Page 17] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + A compliant SNMPv2 entity acting in a manager role must be able to + properly receive and handle a Response-PDU with an error-status field + equal to `noSuchName', `badValue', or `readOnly'. (See Section 3.1.2 + of [8].) + + Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents + its contents to the SNMPv2 application which generated the request + with the same request-id value. + +4.2.5. The SetRequest-PDU + + A SetRequest-PDU is generated and transmitted at the request of a + SNMPv2 application. + + Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity + determines the size of a message encapsulating a Response-PDU having + the same values in its request-id and variable-bindings fields as the + received SetRequest-PDU, and the largest possible sizes of the + error-status and error-index fields. If the determined message size + is greater than either a local constraint or the maximum message size + of the originator, then an alternate Response-PDU is generated, + transmitted to the originator of the SetRequest-PDU, and processing + of the SetRequest-PDU terminates immediately thereafter. This + alternate Response-PDU is formatted with the same values in its + request-id field as the received SetRequest-PDU, with the value of + its error-status field set to `tooBig', the value of its error-index + field set to zero, and an empty variable-bindings field. This + alternate Response-PDU is then encapsulated into a message. If the + size of the resultant message is less than or equal to both a local + constraint and the maximum message size of the originator, it is + transmitted to the originator of the SetRequest-PDU. Otherwise, the + snmpSilentDrops [9] counter is incremented and the resultant message + is discarded. Regardless, processing of the SetRequest-PDU + terminates. + + Otherwise, the receiving SNMPv2 entity processes each variable + binding in the variable-binding list to produce a Response-PDU. All + fields of the Response-PDU have the same values as the corresponding + fields of the received request except as indicated below. + + The variable bindings are conceptually processed as a two phase + operation. In the first phase, each variable binding is validated; + if all validations are successful, then each variable is altered in + the second phase. Of course, implementors are at liberty to + implement either the first, or second, or both, of these conceptual + phases as multiple implementation phases. Indeed, such multiple + implementation phases may be necessary in some cases to ensure + consistency. + + + +SNMPv2 Working Group Standards Track [Page 18] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + The following validations are performed in the first phase on each + variable binding until they are all successful, or until one fails: + +(1) If the variable binding's name specifies an existing or non- + existent variable to which this request is/would be denied access + because it is/would not be in the appropriate MIB view, then the + value of the Response-PDU's error-status field is set to + `noAccess', and the value of its error-index field is set to the + index of the failed variable binding. + +(2) Otherwise, if there are no variables which share the same OBJECT + IDENTIFIER prefix as the variable binding's name, and which are + able to be created or modified no matter what new value is + specified, then the value of the Response-PDU's error-status field + is set to `notWritable', and the value of its error-index field is + set to the index of the failed variable binding. + +(3) Otherwise, if the variable binding's value field specifies, + according to the ASN.1 language, a type which is inconsistent with + that required for all variables which share the same OBJECT + IDENTIFIER prefix as the variable binding's name, then the value of + the Response-PDU's error-status field is set to `wrongType', and + the value of its error-index field is set to the index of the + failed variable binding. + +(4) Otherwise, if the variable binding's value field specifies, + according to the ASN.1 language, a length which is inconsistent + with that required for all variables which share the same OBJECT + IDENTIFIER prefix as the variable binding's name, then the value of + the Response-PDU's error-status field is set to `wrongLength', and + the value of its error-index field is set to the index of the + failed variable binding. + +(5) Otherwise, if the variable binding's value field contains an ASN.1 + encoding which is inconsistent with that field's ASN.1 tag, then + the value of the Response-PDU's error-status field is set to + `wrongEncoding', and the value of its error-index field is set to + the index of the failed variable binding. (Note that not all + implementation strategies will generate this error.) + +(6) Otherwise, if the variable binding's value field specifies a value + which could under no circumstances be assigned to the variable, + then the value of the Response-PDU's error-status field is set to + `wrongValue', and the value of its error-index field is set to the + index of the failed variable binding. + +(7) Otherwise, if the variable binding's name specifies a variable + which does not exist and could not ever be created (even though + + + +SNMPv2 Working Group Standards Track [Page 19] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + some variables sharing the same OBJECT IDENTIFIER prefix might + under some circumstances be able to be created), then the value of + the Response-PDU's error-status field is set to `noCreation', and + the value of its error-index field is set to the index of the + failed variable binding. + +(8) Otherwise, if the variable binding's name specifies a variable + which does not exist but can not be created under the present + circumstances (even though it could be created under other + circumstances), then the value of the Response-PDU's error-status + field is set to `inconsistentName', and the value of its error- + index field is set to the index of the failed variable binding. + +(9) Otherwise, if the variable binding's name specifies a variable + which exists but can not be modified no matter what new value is + specified, then the value of the Response-PDU's error-status field + is set to `notWritable', and the value of its error-index field is + set to the index of the failed variable binding. + +(10) Otherwise, if the variable binding's value field specifies a value + that could under other circumstances be held by the variable, but + is presently inconsistent or otherwise unable to be assigned to the + variable, then the value of the Response-PDU's error-status field + is set to `inconsistentValue', and the value of its error-index + field is set to the index of the failed variable binding. + +(11) When, during the above steps, the assignment of the value specified + by the variable binding's value field to the specified variable + requires the allocation of a resource which is presently + unavailable, then the value of the Response-PDU's error-status + field is set to `resourceUnavailable', and the value of its error- + index field is set to the index of the failed variable binding. + +(12) If the processing of the variable binding fails for a reason other + than listed above, then the value of the Response-PDU's error- + status field is set to `genErr', and the value of its error-index + field is set to the index of the failed variable binding. + +(13) Otherwise, the validation of the variable binding succeeds. + + At the end of the first phase, if the validation of all variable + bindings succeeded, then the value of the Response-PDU's error-status + field is set to `noError' and the value of its error-index field is + zero, and processing continues as follows. + + For each variable binding in the request, the named variable is + created if necessary, and the specified value is assigned to it. + Each of these variable assignments occurs as if simultaneously with + + + +SNMPv2 Working Group Standards Track [Page 20] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + respect to all other assignments specified in the same request. + However, if the same variable is named more than once in a single + request, with different associated values, then the actual assignment + made to that variable is implementation-specific. + + If any of these assignments fail (even after all the previous + validations), then all other assignments are undone, and the + Response-PDU is modified to have the value of its error-status field + set to `commitFailed', and the value of its error-index field set to + the index of the failed variable binding. + + If and only if it is not possible to undo all the assignments, then + the Response-PDU is modified to have the value of its error-status + field set to `undoFailed', and the value of its error-index field is + set to zero. Note that implementations are strongly encouraged to + take all possible measures to avoid use of either `commitFailed' or + `undoFailed' - these two error-status codes are not to be taken as + license to take the easy way out in an implementation. + + Finally, the generated Response-PDU is encapsulated into a message, + and transmitted to the originator of the SetRequest-PDU. + +4.2.6. The SNMPv2-Trap-PDU + + A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity + acting in an agent role when an exceptional situation occurs. + + The destination(s) to which a SNMPv2-Trap-PDU is sent is determined + in an implementation-dependent fashion by the SNMPv2 entity. The + first two variable bindings in the variable binding list of an + SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9] + respectively. If the OBJECTS clause is present in the invocation of + the corresponding NOTIFICATION-TYPE macro, then each corresponding + variable, as instantiated by this notification, is copied, in order, + to the variable-bindings field. If any additional variables are + being included (at the option of the generating SNMPv2 entity), then + each is copied to the variable-bindings field. + +4.2.7. The InformRequest-PDU + + An InformRequest-PDU is generated and transmitted at the request of + an application in a SNMPv2 entity acting in a manager role, that + wishes to notify another application (in a SNMPv2 entity also acting + in a manager role) of information in a MIB view which is remote to + the receiving application. + + The destination(s) to which an InformRequest-PDU is sent is specified + by the requesting application. The first two variable bindings in + + + +SNMPv2 Working Group Standards Track [Page 21] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + the variable binding list of an InformRequest-PDU are sysUpTime.0 [9] + and snmpTrapOID.0 [9] respectively. If the OBJECTS clause is present + in the invocation of the corresponding NOTIFICATION-TYPE macro, then + each corresponding variable, as instantiated by this notification, is + copied, in order, to the variable-bindings field. + + Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity + determines the size of a message encapsulating a Response-PDU with + the same values in its request-id, error-status, error-index and + variable-bindings fields as the received InformRequest-PDU. If the + determined message size is greater than either a local constraint or + the maximum message size of the originator, then an alternate + Response-PDU is generated, transmitted to the originator of the + InformRequest-PDU, and processing of the InformRequest-PDU terminates + immediately thereafter. This alternate Response-PDU is formatted + with the same values in its request-id field as the received + InformRequest-PDU, with the value of its error-status field set to + `tooBig', the value of its error-index field set to zero, and an + empty variable-bindings field. This alternate Response-PDU is then + encapsulated into a message. If the size of the resultant message is + less than or equal to both a local constraint and the maximum message + size of the originator, it is transmitted to the originator of the + InformRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is + incremented and the resultant message is discarded. Regardless, + processing of the InformRequest-PDU terminates. + + Otherwise, the receiving SNMPv2 entity: + +(1) presents its contents to the appropriate SNMPv2 application; + +(2) generates a Response-PDU with the same values in its request-id and + variable-bindings fields as the received InformRequest-PDU, with + the value of its error-status field is set to `noError' and the + value of its error-index field is zero; and + +(3) transmits the generated Response-PDU to the originator of the + InformRequest-PDU. + +5. Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 22] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + +6. Editor's Address + + Keith McCloghrie + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + US + + Phone: +1 408 526 5260 + EMail: kzm@cisco.com + +7. Acknowledgements + + This document is the result of significant work by the four major + contributors: + + Jeffrey D. Case (SNMP Research, case@snmp.com) + Keith McCloghrie (Cisco Systems, kzm@cisco.com) + Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) + Steven Waldbusser (International Network Services, stevew@uni.ins.com) + + In addition, the contributions of the SNMPv2 Working Group are + acknowledged. In particular, a special thanks is extended for the + contributions of: + + Alexander I. Alten (Novell) + Dave Arneson (Cabletron) + Uri Blumenthal (IBM) + Doug Book (Chipcom) + Kim Curran (Bell-Northern Research) + Jim Galvin (Trusted Information Systems) + Maria Greene (Ascom Timeplex) + Iain Hanson (Digital) + Dave Harrington (Cabletron) + Nguyen Hien (IBM) + Jeff Johnson (Cisco Systems) + Michael Kornegay (Object Quest) + Deirdre Kostick (AT&T Bell Labs) + David Levi (SNMP Research) + Daniel Mahoney (Cabletron) + Bob Natale (ACE*COMM) + Brian O'Keefe (Hewlett Packard) + Andrew Pearson (SNMP Research) + Dave Perkins (Peer Networks) + Randy Presuhn (Peer Networks) + Aleksey Romanov (Quality Quorum) + Shawn Routhier (Epilogue) + Jon Saperia (BGS Systems) + + + +SNMPv2 Working Group Standards Track [Page 23] + +RFC 1905 Protocol Operations for SNMPv2 January 1996 + + + Bob Stewart (Cisco Systems, bstewart@cisco.com), chair + Kaj Tesink (Bellcore) + Glenn Waters (Bell-Northern Research) + Bert Wijnen (IBM) + +8. References + +[1] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization. International + Standard 8824, (December, 1987). + +[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Structure of Management Information for Version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC 1902, + January 1996. + +[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + +[4] Kent, C., and J. Mogul, Fragmentation Considered Harmful, + Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987). + +[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Transport Mappings for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1906, January 1996. + +[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + +[7] McCloghrie, K., and M. Rose, Editors, "Management Information + Base for Network Management of TCP/IP-based internets: + MIB-II", STD 17, RFC 1213, March 1991. + +[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Coexistence between Version 1 and Version 2 + of the Internet-standard Network Management Framework", RFC 1908, + January 1996. + +[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Management Information Base for Version 2 of the + Simple Network Management Protocol (SNMPv2)", RFC 1907, + January 1996. + + + + + + + +SNMPv2 Working Group Standards Track [Page 24] + -- 2.47.2