7 Network Working Group SNMPv2 Working Group
8 Request for Comments: 1901 J. Case
9 Category: Experimental SNMP Research, Inc.
13 Dover Beach Consulting, Inc.
15 International Network Services
19 Introduction to Community-based SNMPv2
23 This document specifies an Experimental protocol for the Internet
24 community. This memo does not specify an Internet standard of any
25 kind. Discussion and suggestions for improvement are requested.
26 Distribution of this memo is unlimited.
30 1. Introduction ................................................ 1
31 2. Components of the SNMPv2 Framework .......................... 2
32 2.1 Structure of Management Information ........................ 2
33 2.2 Textual Conventions ........................................ 3
34 2.3 Conformance Statements ..................................... 3
35 2.4 Protocol Operations ........................................ 3
36 2.5 Transport Mappings ......................................... 4
37 2.6 Protocol Instrumentation ................................... 4
38 3. The Community-based Administrative Framework ................ 4
39 4. Security Considerations ..................................... 5
40 5. Editor's Address ............................................ 6
41 6. Acknowledgements ............................................ 6
42 7. References .................................................. 7
46 The purpose of this document is to define the Community-based
47 Administrative Framework for the SNMP version 2 framework (SNMPv2).
48 The SNMPv2 framework is fully described in [1-6]. This framework is
49 derived from the original Internet-standard Network Management
50 Framework (SNMPv1), which consists of these three documents:
52 STD 16, RFC 1155 [7] which defines the Structure of Management
53 Information (SMI), the mechanisms used for describing and naming
54 objects for the purpose of management.
58 SNMPv2 Working Group Experimental [Page 1]
60 RFC 1901 Introduction to Community-based SNMPv2 January 1996
63 STD 16, RFC 1212 [8] which defines a more concise description
64 mechanism, which is wholly consistent with the SMI.
66 STD 15, RFC 1157 [9] which defines the Simple Network Management
67 Protocol (SNMP), the protocol used for network access to managed
70 For information on coexistence between SNMPv1 and SNMPv2, consult
73 2. Components of the SNMPv2 Framework
75 A management system contains: several (potentially many) nodes, each
76 with a processing entity, termed an agent, which has access to
77 management instrumentation; at least one management station; and, a
78 management protocol, used to convey management information between
79 the agents and management stations. Operations of the protocol are
80 carried out under an administrative framework which defines
81 authentication, authorization, access control, and privacy policies.
83 Management stations execute management applications which monitor and
84 control managed elements. Managed elements are devices such as
85 hosts, routers, terminal servers, etc., which are monitored and
86 controlled via access to their management information.
88 2.1. Structure of Management Information
90 Management information is viewed as a collection of managed objects,
91 residing in a virtual information store, termed the Management
92 Information Base (MIB). Collections of related objects are defined
93 in MIB modules. These modules are written using a subset of OSI's
94 Abstract Syntax Notation One (ASN.1) [11]. It is the purpose of the
95 Structure of Management Information for SNMPv2 document [1] to define
98 The SMI is divided into three parts: module definitions, object
99 definitions, and, trap definitions.
101 (1) Module definitions are used when describing information modules.
102 An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the
103 semantics of an information module.
105 (2) Object definitions are used when describing managed objects. An
106 ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax
107 and semantics of a managed object.
109 (3) Notification definitions are used when describing unsolicited
110 transmissions of management information. An ASN.1 macro,
114 SNMPv2 Working Group Experimental [Page 2]
116 RFC 1901 Introduction to Community-based SNMPv2 January 1996
119 NOTIFICATION-TYPE, is used to concisely convey the syntax and
120 semantics of a notification.
122 2.2. Textual Conventions
124 When designing a MIB module, it is often useful to define new types
125 similar to those defined in the SMI. In comparison to a type defined
126 in the SMI, each of these new types has a different name, a similar
127 syntax, but a more precise semantics. These newly defined types are
128 termed textual conventions, and are used for the convenience of
129 humans reading the MIB module. It is the purpose of the Textual
130 Conventions for SNMPv2 document [2] to define the initial set of
131 textual conventions available to all MIB modules.
133 Objects defined using a textual convention are always encoded by
134 means of the rules that define their primitive type. However,
135 textual conventions often have special semantics associated with
136 them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to
137 concisely convey the syntax and semantics of a textual convention.
139 2.3. Conformance Statements
141 It may be useful to define the acceptable lower-bounds of
142 implementation, along with the actual level of implementation
143 achieved. It is the purpose of the Conformance Statements for SNMPv2
144 document [3] to define the notation used for these purposes. There
145 are two kinds of notations:
147 (1) Compliance statements are used when describing requirements for
148 agents with respect to object definitions. An ASN.1 macro,
149 MODULE-COMPLIANCE, is used to concisely convey such requirements.
151 (2) Capability statements are used when describing capabilities of
152 agents with respect to object definitions. An ASN.1 macro, AGENT-
153 CAPABILITIES, is used to concisely convey such capabilities.
155 Finally, collections of related objects are grouped together to form
156 a unit of conformance. An ASN.1 macro, OBJECT-GROUP, is used to
157 concisely convey the syntax and semantics of a group.
159 2.4. Protocol Operations
161 The management protocol provides for the exchange of messages which
162 convey management information between the agents and the management
163 stations. The form of these messages is a message "wrapper" which
164 encapsulates a Protocol Data Unit (PDU).
170 SNMPv2 Working Group Experimental [Page 3]
172 RFC 1901 Introduction to Community-based SNMPv2 January 1996
175 It is the purpose of the Protocol Operations for SNMPv2 document [4]
176 to define the operations of the protocol with respect to the sending
177 and receiving of the PDUs.
179 2.5. Transport Mappings
181 The management protocol, version 2 of the Simple Network Management
182 Protocol, may be used over a variety of protocol suites. It is the
183 purpose of the Transport Mappings for SNMPv2 document [5] to define
184 how the SNMPv2 maps onto an initial set of transport domains. Other
185 mappings may be defined in the future.
187 Although several mappings are defined, the mapping onto UDP is the
188 preferred mapping. As such, to provide for the greatest level of
189 interoperability, systems which choose to deploy other mappings
190 should also provide for proxy service to the UDP mapping.
192 2.6. Protocol Instrumentation
194 It is the purpose of the Management Information Base for SNMPv2
195 document [6] to define managed objects which describe the behavior of
198 3. The Community-based Administrative Framework
200 It is the purpose of an administrative framework to define an
201 infrastructure through which effective management can be realized in
202 a variety of configurations and environments. Specified as a part
203 of, or as extensions of, an administrative framework are security
204 mechanisms used to achieve an administratively-defined level of
205 security for protocol interactions.
207 The administrative framework for SNMPv2 identified in this document
208 is the same framework as was defined for SNMPv1 [9]. This
209 administrative framework associates each message with a "community"
210 as defined in [9]. Use of this administrative framework with SNMP
211 Version 2 is commonly known as "Community-based SNMPv2 (SNMPv2C)."
213 Specifically, Section 3.2.5 of [9] defines the concept of a
214 community, and Section 4.1 of [9] defines the Elements of Procedure
215 for generating and receiving messages. The following updates apply:
217 (1) The types of access defined in Section 3.2.5 of [9] are updated
220 (2) The Elements of Procedure defined in Section 4.1 of [9] are
221 updated with the additional requirement of incrementing the
222 relevant statistics counter as defined in [6].
226 SNMPv2 Working Group Experimental [Page 4]
228 RFC 1901 Introduction to Community-based SNMPv2 January 1996
231 (3) The requirement in the Elements of Procedure in Section 4.1 of
232 [9] that the "the source transport address that a response
233 message is sent from shall be identical to the destination
234 transport address that the original request message was sent to"
235 is deleted, i.e., the source transport address of a response
236 message can be any transport address belonging to the agent.
238 The form of a message is also taken from [9], with the exception that
239 a new version number is used in the message "wrapper". Use of a new
240 version number is necessary because of SNMPv2's new PDU types [4],
241 error codes [4], etc. With this one change, the wrapper becomes:
243 COMMUNITY-BASED-SNMPv2 DEFINITIONS ::= BEGIN
251 version(1) -- modified from RFC 1157
254 community -- community name
257 data -- PDUs as defined in [4]
264 Note that with this administrative framework, the
265 'authorizationError(16)' value defined for the error-status component
266 of an SNMPv2 PDU [4] is unused. It may, however, be used with future
267 administrative frameworks.
269 4. Security Considerations
271 Security issues are not discussed in this memo.
282 SNMPv2 Working Group Experimental [Page 5]
284 RFC 1901 Introduction to Community-based SNMPv2 January 1996
291 170 West Tasman Drive
292 San Jose, CA 95134-1706
295 Phone: +1 408 526 5260
300 This document is the result of significant work by the four major
303 Jeffrey D. Case (SNMP Research, case@snmp.com)
304 Keith McCloghrie (Cisco Systems, kzm@cisco.com)
305 Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
306 Steven Waldbusser (International Network Services, stevew@uni.ins.com)
308 In addition, the contributions of the SNMPv2 Working Group are
309 acknowledged. In particular, a special thanks is extended for the
312 Alexander I. Alten (Novell)
313 Dave Arneson (Cabletron)
316 Kim Curran (Bell-Northern Research)
317 Jim Galvin (Trusted Information Systems)
318 Maria Greene (Ascom Timeplex)
319 Iain Hanson (Digital)
320 Dave Harrington (Cabletron)
322 Jeff Johnson (Cisco Systems)
323 Michael Kornegay (Object Quest)
324 Deirdre Kostick (AT&T Bell Labs)
325 David Levi (SNMP Research)
326 Daniel Mahoney (Cabletron)
327 Bob Natale (ACE*COMM)
328 Brian O'Keefe (Hewlett Packard)
329 Andrew Pearson (SNMP Research)
330 Dave Perkins (Peer Networks)
331 Randy Presuhn (Peer Networks)
332 Aleksey Romanov (Quality Quorum)
333 Shawn Routhier (Epilogue)
334 Jon Saperia (BGS Systems)
338 SNMPv2 Working Group Experimental [Page 6]
340 RFC 1901 Introduction to Community-based SNMPv2 January 1996
343 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
344 Kaj Tesink (Bellcore)
345 Glenn Waters (Bell-Northern Research)
350 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
351 S. Waldbusser, "Structure of Management Information for Version 2
352 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
355 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
356 S. Waldbusser, "Textual Conventions for Version 2 of the Simple
357 Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
359 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
360 S. Waldbusser, "Conformance Statements for Version 2 of the Simple
361 Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
363 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
364 S. Waldbusser, "Protocol Operations for Version 2 of the Simple
365 Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
367 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
368 S. Waldbusser, "Transport Mappings for Version 2 of the Simple
369 Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
371 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
372 S. Waldbusser, "Management Information Base for Version 2 of the
373 Simple Network Management Protocol (SNMPv2)", RFC 1907,
376 [7] Rose, M., and K. McCloghrie, "Structure and Identification of
377 Management Information for TCP/IP-based internets", STD 16, RFC
380 [8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
381 RFC 1212, March 1991.
383 [9] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
384 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
385 Systems International, MIT Laboratory for Computer Science, May
394 SNMPv2 Working Group Experimental [Page 7]
396 RFC 1901 Introduction to Community-based SNMPv2 January 1996
399 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
400 S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
401 Internet-standard Network Management Framework", RFC 1908,
404 [11] Information processing systems - Open Systems Interconnection -
405 Specification of Abstract Syntax Notation One (ASN.1),
406 International Organization for Standardization. International
407 Standard 8824, (December, 1987).
450 SNMPv2 Working Group Experimental [Page 8]