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]
added
removed
doc/rfc/rfc1901.txt
