📄 rfc1303.txt
字号:
Network Working Group K. McCloghrieRequest For Comments: 1303 Hughes LAN Systems M. Rose Dover Beach Consulting February 1992 A Convention for Describing SNMP-based AgentsStatus of This Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.Abstract This memo suggests a straight-forward approach towards describing SNMP-based agents.Table of Contents 1. The Network Management Framework ............................ 2 2. Objects ..................................................... 2 3. Describing Agents ........................................... 3 3.1 Definitions ................................................ 4 3.2 Mapping of the MODULE-CONFORMANCE macro .................... 5 3.2.1 Mapping of the LAST-UPDATED clause ....................... 6 3.2.2 Mapping of the PRODUCT-RELEASE clause .................... 6 3.2.3 Mapping of the DESCRIPTION clause ........................ 6 3.2.4 Mapping of the SUPPORTS clause ........................... 6 3.2.4.1 Mapping of the INCLUDES clause ......................... 6 3.2.4.2 Mapping of the VARIATION clause ........................ 6 3.2.4.2.1 Mapping of the SYNTAX clause ......................... 6 3.2.4.2.2 Mapping of the WRITE-SYNTAX clause ................... 7 3.2.4.2.3 Mapping of the ACCESS clause ......................... 7 3.2.4.2.4 Mapping of the CREATION-REQUIRES clause .............. 7 3.2.4.2.5 Mapping of the DEFVAL clause ......................... 7 3.2.4.2.6 Mapping of the DESCRIPTION clause .................... 7 3.3 Refined Syntax ............................................. 7 3.4 Usage Example .............................................. 8 4. Acknowledgements ............................................ 11 5. References .................................................. 11 6. Security Considerations...................................... 12 7. Authors' Addresses........................................... 12McCloghrie & Rose [Page 1]RFC 1303 Convention for Describing SNMP Agents February 19921. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 [2] defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1213 [3] which defines MIB-II, the core set of managed objects for the Internet suite of protocols. RFC 1157 [4] which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation.2. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using RFC 1212's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1[5] language is used for this purpose. However, RFC 1155 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated.McCloghrie & Rose [Page 2]RFC 1303 Convention for Describing SNMP Agents February 19923. Describing Agents When a MIB module is written, it is divided into units of conformance termed groups. If an agent claims conformance to a group, then it must implement each and every object within that group. Of course, for whatever reason, an agent may implement only a subset of the groups within a MIB module. In addition, the definition of some MIB objects leave some aspects of the definition to the discretion of an implementor. Practical experience has demonstrated a need for concisely describing the capabilities of an agent with regards to the MIB groups that it implements. This memo defines a new macro, MODULE-CONFORMANCE, which allows an agent implementor to describe the precise level of support which an agent claims in regards to a MIB group, and to bind that description to the sysObjectID associated with the agent. In particular, some objects may have restricted or augmented syntax or access- levels. If the MODULE-CONFORMANCE invocation is given to a management-station implementor, then that implementor can build management applications which optimize themselves when communicating with a particular agent. For example, the management-station can maintain a database of these invocations. When a management-station interacts with an agent, it retrieves the agent's sysObjectID. Based on this, it consults the database. If an entry is found, then the management application can optimize its behavior accordingly. This binding to sysObjectId may not always suffice to define all MIB objects to which an agent can provide access. In particular, this situation occurs where the agent dynamically learns of the objects it supports, for example, an agent supporting SMUX peers via the SMUX protocol [6]. In these situations, additional MIB objects beyond sysObjectID must be used to name other invocations of the MODULE-CONFORMANCE macro to augment the description of MIB support provided by the agent. For example, if an agent's sysObjectID indicates that it supports the SMUX MIB, then each instance of smuxPidentity will indicate another MODULE-CONFORMANCE invocation which is dynamically being supported by the agent.McCloghrie & Rose [Page 3]RFC 1303 Convention for Describing SNMP Agents February 19923.1. Definitions RFC-1303 DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax FROM RFC1155-SMI DisplayString FROM RFC1213-MIB; MODULE-CONFORMANCE MACRO ::= BEGIN TYPE NOTATION ::= "LAST-UPDATED" value(update UTCTime) "PRODUCT-RELEASE" value(release DisplayString) "DESCRIPTION" value(description DisplayString) ModulePart VALUE NOTATION ::= -- agent's sysObjectID -- value(VALUE ObjectName) ModulePart ::= Modules | empty Modules ::= Module | Modules Module Module ::= -- name of module -- "SUPPORTS" ModuleName "INCLUDES" "{" Groups "}" VariationPart ModuleName ::= identifier ModuleIdentifier ModuleIdentifier ::= value (moduleID OBJECT IDENTIFIER) | empty Groups ::= Group | Groups "," Group Group ::= value(group OBJECT IDENTIFIER) VariationPart ::= Variations | emptyMcCloghrie & Rose [Page 4]RFC 1303 Convention for Describing SNMP Agents February 1992 Variations ::= Variation | Variations Variation Variation ::= "VARIATION" value(object ObjectName) Syntax WriteSyntax Access Creation DefaultValue "DESCRIPTION" value(limitext DisplayString) -- must be a refinement for object's SYNTAX Syntax ::= "SYNTAX" type(SYNTAX) | empty -- must be a refinement for object's SYNTAX WriteSyntax ::= "WRITE-SYNTAX" type(WriteSYNTAX) | empty Access ::= "ACCESS" AccessValue | empty AccessValue ::= "read-only" | "read-write" | "write-only" | "not-accessible" Creation ::= "CREATION-REQUIRES" "{" Cells "}" Cells ::= Cell | Cells "," Cell Cell ::= value(cell ObjectName) DefaultValue ::= "DEFVAL" "{" value (defval ObjectSyntax) "}" | empty END END3.2. Mapping of the MODULE-CONFORMANCE macro It should be noted that the expansion of the MODULE-CONFORMANCE macro is something which conceptually happens during implementation and not during run-time.McCloghrie & Rose [Page 5]RFC 1303 Convention for Describing SNMP Agents February 19923.2.1. Mapping of the LAST-UPDATED clause The LAST-UPDATED clause, which must be present, contains the date and time that this definition was last edited.3.2.2. Mapping of the PRODUCT-RELEASE clause The PRODUCT-RELEASE clause, which must be present, contains a textual description of the product release which includes this agent.3.2.3. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual description of this agent.3.2.4. Mapping of the SUPPORTS clause The SUPPORTS clause, which need not be present, is repeatedly used to name each MIB module for which the agent claims a complete or partial implementation. Each MIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER as well. (Note that only a few MIB modules have had OBJECT IDENTIFIERs assigned to them.)3.2.4.1. Mapping of the INCLUDES clause The INCLUDES clause, which must be present for each use of the SUPPORTS clause, is used to name each MIB group associated with the SUPPORT clause, which the agent claims to implement.3.2.4.2. Mapping of the VARIATION clause The VARIATION clause, which need not be present, is repeatedly used to name each MIB object which the agent implements in some variant or refined fashion.3.2.4.2.1. Mapping of the SYNTAX clause The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent VARIATION clause. Note that if this clause and a WRITE-SYNTAX clause are both present, then this clause only applies when instances of the object named in the correspondent VARIATION clause are read. Consult Section 3.3 for more information on refined syntax.McCloghrie & Rose [Page 6]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -