summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1901.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1901.txt')
-rw-r--r--doc/rfc/rfc1901.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1901.txt b/doc/rfc/rfc1901.txt
new file mode 100644
index 0000000..06bc214
--- /dev/null
+++ b/doc/rfc/rfc1901.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group SNMPv2 Working Group
+Request for Comments: 1901 J. Case
+Category: Experimental SNMP Research, Inc.
+ K. McCloghrie
+ Cisco Systems, Inc.
+ M. Rose
+ Dover Beach Consulting, Inc.
+ S. Waldbusser
+ International Network Services
+ January 1996
+
+
+ Introduction to Community-based SNMPv2
+
+Status of this Memo
+
+ This document specifies an Experimental protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Table of Contents
+
+ 1. Introduction ................................................ 1
+ 2. Components of the SNMPv2 Framework .......................... 2
+ 2.1 Structure of Management Information ........................ 2
+ 2.2 Textual Conventions ........................................ 3
+ 2.3 Conformance Statements ..................................... 3
+ 2.4 Protocol Operations ........................................ 3
+ 2.5 Transport Mappings ......................................... 4
+ 2.6 Protocol Instrumentation ................................... 4
+ 3. The Community-based Administrative Framework ................ 4
+ 4. Security Considerations ..................................... 5
+ 5. Editor's Address ............................................ 6
+ 6. Acknowledgements ............................................ 6
+ 7. References .................................................. 7
+
+1. Introduction
+
+ The purpose of this document is to define the Community-based
+ Administrative Framework for the SNMP version 2 framework (SNMPv2).
+ The SNMPv2 framework is fully described in [1-6]. This framework is
+ derived from the original Internet-standard Network Management
+ Framework (SNMPv1), which consists of these three documents:
+
+ STD 16, RFC 1155 [7] which defines the Structure of Management
+ Information (SMI), the mechanisms used for describing and naming
+ objects for the purpose of management.
+
+
+
+SNMPv2 Working Group Experimental [Page 1]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+ STD 16, RFC 1212 [8] which defines a more concise description
+ mechanism, which is wholly consistent with the SMI.
+
+ STD 15, RFC 1157 [9] which defines the Simple Network Management
+ Protocol (SNMP), the protocol used for network access to managed
+ objects.
+
+ For information on coexistence between SNMPv1 and SNMPv2, consult
+ [10].
+
+2. Components of the SNMPv2 Framework
+
+ 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.
+
+2.1. Structure of Management Information
+
+ Management information is viewed as a collection of managed objects,
+ residing in a virtual information store, termed the Management
+ Information Base (MIB). Collections of related objects are defined
+ in MIB modules. These modules are written using a subset of OSI's
+ Abstract Syntax Notation One (ASN.1) [11]. It is the purpose of the
+ Structure of Management Information for SNMPv2 document [1] to define
+ that subset.
+
+ The SMI is divided into three parts: module definitions, object
+ definitions, and, trap definitions.
+
+ (1) Module definitions are used when describing information modules.
+ An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the
+ semantics of an information module.
+
+ (2) Object definitions are used when describing managed objects. An
+ ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax
+ and semantics of a managed object.
+
+ (3) Notification definitions are used when describing unsolicited
+ transmissions of management information. An ASN.1 macro,
+
+
+
+SNMPv2 Working Group Experimental [Page 2]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+ NOTIFICATION-TYPE, is used to concisely convey the syntax and
+ semantics of a notification.
+
+2.2. Textual Conventions
+
+ When designing a MIB module, it is often useful to define new types
+ similar to those defined in the SMI. In comparison to a type defined
+ in the SMI, each of these new types has a different name, a similar
+ syntax, but a more precise semantics. These newly defined types are
+ termed textual conventions, and are used for the convenience of
+ humans reading the MIB module. It is the purpose of the Textual
+ Conventions for SNMPv2 document [2] to define the initial set of
+ textual conventions available to all MIB modules.
+
+ Objects defined using a textual convention are always encoded by
+ means of the rules that define their primitive type. However,
+ textual conventions often have special semantics associated with
+ them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to
+ concisely convey the syntax and semantics of a textual convention.
+
+2.3. Conformance Statements
+
+ It may be useful to define the acceptable lower-bounds of
+ implementation, along with the actual level of implementation
+ achieved. It is the purpose of the Conformance Statements for SNMPv2
+ document [3] to define the notation used for these purposes. There
+ are two kinds of notations:
+
+ (1) Compliance statements are used when describing requirements for
+ agents with respect to object definitions. An ASN.1 macro,
+ MODULE-COMPLIANCE, is used to concisely convey such requirements.
+
+ (2) Capability statements are used when describing capabilities of
+ agents with respect to object definitions. An ASN.1 macro, AGENT-
+ CAPABILITIES, is used to concisely convey such capabilities.
+
+ Finally, collections of related objects are grouped together to form
+ a unit of conformance. An ASN.1 macro, OBJECT-GROUP, is used to
+ concisely convey the syntax and semantics of a group.
+
+2.4. Protocol Operations
+
+ The management protocol provides for the exchange of messages which
+ convey management information between the agents and the management
+ stations. The form of these messages is a message "wrapper" which
+ encapsulates a Protocol Data Unit (PDU).
+
+
+
+
+
+SNMPv2 Working Group Experimental [Page 3]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+ It is the purpose of the Protocol Operations for SNMPv2 document [4]
+ to define the operations of the protocol with respect to the sending
+ and receiving of the PDUs.
+
+2.5. Transport Mappings
+
+ The management protocol, version 2 of the Simple Network Management
+ Protocol, may be used over a variety of protocol suites. It is the
+ purpose of the Transport Mappings for SNMPv2 document [5] to define
+ how the SNMPv2 maps onto an initial set of transport domains. Other
+ mappings may be defined in the future.
+
+ Although several mappings are defined, the mapping onto UDP is the
+ preferred mapping. As such, to provide for the greatest level of
+ interoperability, systems which choose to deploy other mappings
+ should also provide for proxy service to the UDP mapping.
+
+2.6. Protocol Instrumentation
+
+ It is the purpose of the Management Information Base for SNMPv2
+ document [6] to define managed objects which describe the behavior of
+ a SNMPv2 entity.
+
+3. The Community-based Administrative Framework
+
+ It is the purpose of an administrative framework to define an
+ infrastructure through which effective management can be realized in
+ a variety of configurations and environments. Specified as a part
+ of, or as extensions of, an administrative framework are security
+ mechanisms used to achieve an administratively-defined level of
+ security for protocol interactions.
+
+ The administrative framework for SNMPv2 identified in this document
+ is the same framework as was defined for SNMPv1 [9]. This
+ administrative framework associates each message with a "community"
+ as defined in [9]. Use of this administrative framework with SNMP
+ Version 2 is commonly known as "Community-based SNMPv2 (SNMPv2C)."
+
+ Specifically, Section 3.2.5 of [9] defines the concept of a
+ community, and Section 4.1 of [9] defines the Elements of Procedure
+ for generating and receiving messages. The following updates apply:
+
+ (1) The types of access defined in Section 3.2.5 of [9] are updated
+ by [1].
+
+ (2) The Elements of Procedure defined in Section 4.1 of [9] are
+ updated with the additional requirement of incrementing the
+ relevant statistics counter as defined in [6].
+
+
+
+SNMPv2 Working Group Experimental [Page 4]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+ (3) The requirement in the Elements of Procedure in Section 4.1 of
+ [9] that the "the source transport address that a response
+ message is sent from shall be identical to the destination
+ transport address that the original request message was sent to"
+ is deleted, i.e., the source transport address of a response
+ message can be any transport address belonging to the agent.
+
+ The form of a message is also taken from [9], with the exception that
+ a new version number is used in the message "wrapper". Use of a new
+ version number is necessary because of SNMPv2's new PDU types [4],
+ error codes [4], etc. With this one change, the wrapper becomes:
+
+ COMMUNITY-BASED-SNMPv2 DEFINITIONS ::= BEGIN
+
+ -- top-level message
+
+ Message ::=
+ SEQUENCE {
+ version
+ INTEGER {
+ version(1) -- modified from RFC 1157
+ },
+
+ community -- community name
+ OCTET STRING,
+
+ data -- PDUs as defined in [4]
+ ANY
+ }
+ }
+
+ END
+
+ Note that with this administrative framework, the
+ 'authorizationError(16)' value defined for the error-status component
+ of an SNMPv2 PDU [4] is unused. It may, however, be used with future
+ administrative frameworks.
+
+4. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Experimental [Page 5]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+5. 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
+
+6. 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 Experimental [Page 6]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+ Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
+ Kaj Tesink (Bellcore)
+ Glenn Waters (Bell-Northern Research)
+ Bert Wijnen (IBM)
+
+7. References
+
+[1] 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.
+
+[2] 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.
+
+[3] 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.
+
+[4] 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.
+
+[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] 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.
+
+[7] Rose, M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based internets", STD 16, RFC
+ 1155, May 1990.
+
+[8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
+ RFC 1212, March 1991.
+
+[9] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
+ Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
+ Systems International, MIT Laboratory for Computer Science, May
+ 1990.
+
+
+
+
+
+
+
+SNMPv2 Working Group Experimental [Page 7]
+
+RFC 1901 Introduction to Community-based SNMPv2 January 1996
+
+
+[10] 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.
+
+[11] Information processing systems - Open Systems Interconnection -
+ Specification of Abstract Syntax Notation One (ASN.1),
+ International Organization for Standardization. International
+ Standard 8824, (December, 1987).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group Experimental [Page 8]
+