rfc1065.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,179 行 · 第 1/3 页

Rose & McCloghrie                                               [Page 7]

RFC 1065                          SMI                        August 1988


   enumerations.  Use of this value is prohibited.

3.2.2.  Constructor Types

   The ASN.1 constructor type SEQUENCE is permitted, providing that it
   is used to generate either lists or tables.

   For lists, the syntax takes the form:

      SEQUENCE { <type1>, ..., <typeN> }

   where each <type> resolves to one of the ASN.1 primitive types listed
   above.  Further, these ASN.1 types are always present (the DEFAULT
   and OPTIONAL clauses do not appear in the SEQUENCE definition).

   For tables, the syntax takes the form:

      SEQUENCE OF <entry>

   where <entry> resolves to a list constructor.

   Lists and tables are sometimes referred to as aggregate types.

3.2.3.  Defined Types

   In addition, new application-wide types may be defined, so long as
   they resolve into an IMPLICITly defined ASN.1 primitive type, list,
   table, or some other application-wide type.  Initially, few
   application-wide types are defined.  Future memos will no doubt
   define others once a consensus is reached.

3.2.3.1.  NetworkAddress

   This CHOICE represents an address from one of possibly several
   protocol families.  Currently, only one protocol family, the Internet
   family, is present in this CHOICE.

3.2.3.2.  IpAddress

   This application-wide type represents a 32-bit internet address.  It
   is represented as an OCTET STRING of length 4, in network byte-order.

   When this ASN.1 type is encoded using the ASN.1 basic encoding rules,
   only the primitive encoding form shall be used.

3.2.3.3.  Counter

   This application-wide type represents a non-negative integer which



Rose & McCloghrie                                               [Page 8]

RFC 1065                          SMI                        August 1988


   monotonically increases until it reaches a maximum value, when it
   wraps around and starts increasing again from zero.  This memo
   specifies a maximum value of 2^32-1 (4294967295 decimal) for
   counters.

3.2.3.4.  Gauge

   This application-wide type represents a non-negative integer, which
   may increase or decrease, but which latches at a maximum value.  This
   memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
   gauges.

3.2.3.5.  TimeTicks

   This application-wide type represents a non-negative integer which
   counts the time in hundredths of a second since some epoch.  When
   object types are defined in the MIB which use this ASN.1 type, the
   description of the object type identifies the reference epoch.

3.2.3.6.  Opaque

   This application-wide type supports the capability to pass arbitrary
   ASN.1 syntax.  A value is encoded using the ASN.1 basic rules 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.

   Further note that by use of the ASN.1 EXTERNAL type, encodings other
   than ASN.1 may be used in opaquely-encoded data.

3.3.  Encodings

   Once an instance of an object type has been identified, its value may
   be transmitted by applying the basic encoding rules of ASN.1 to the
   syntax for the object type.













Rose & McCloghrie                                               [Page 9]

RFC 1065                          SMI                        August 1988


4.  Managed Objects

   Although it is not the purpose of this memo to define objects in the
   MIB, this memo specifies a format to be used by other memos which
   define these objects.

   An object type definition consists of five fields:

   OBJECT:
   -------
      A textual name, termed the OBJECT DESCRIPTOR, for the object type,
      along with its corresponding OBJECT IDENTIFIER.

   Syntax:
      The abstract syntax for the object type.  This must resolve to an
      instance of the ASN.1 type ObjectSyntax (defined below).

   Definition:
      A textual description of the semantics of the object type.
      Implementations should ensure that their instance of the object
      fulfills this definition since this MIB is intended for use in
      multi-vendor environments.  As such it is vital that objects have
      consistent meaning across all machines.

   Access:
      One of read-only, read-write, write-only, or not-accessible.

   Status:
      One of mandatory, optional, or obsolete.

   Future memos may also specify other fields for the objects which they
   define.

4.1.  Guidelines for Object Names

   No object type in the Internet-Standard MIB shall use a sub-
   identifier of 0 in its name.  This value is reserved for use with
   future extensions.

   Each OBJECT DESCRIPTOR corresponding to an object type in the
   internet-standard MIB shall be a unique, but mnemonic, printable
   string.  This promotes a common language for humans to use when
   discussing the MIB and also facilitates simple table mappings for
   user interfaces.

4.2.  Object Types and Instances

   An object type is a definition of a kind of managed object; it is



Rose & McCloghrie                                              [Page 10]

RFC 1065                          SMI                        August 1988


   declarative in nature.  In contrast, an object instance is an
   instantiation of an object type which has been bound to a value.  For
   example, the notion of an entry in a routing table might be defined
   in the MIB.  Such a notion corresponds to an object type; individual
   entries in a particular routing table which exist at some time are
   object instances of that object type.

   A collection of object types is defined in the MIB.  Each such
   subject type is uniquely named by its OBJECT IDENTIFIER and also has
   a textual name, which is its OBJECT DESCRIPTOR.  The means whereby
   object instances are referenced is not defined in the MIB.  Reference
   to object instances is achieved by a protocol-specific mechanism: it
   is the responsibility of each management protocol adhering to the SMI
   to define this mechanism.

   An object type may be defined in the MIB such that an instance of
   that object type represents an aggregation of information also
   represented by instances of some number of "subordinate" object
   types.  For example, suppose the following object types are defined
   in the MIB:


   OBJECT:
   -------
      atIndex { atEntry 1 }

   Syntax:
      INTEGER

   Definition:
      The interface number for the physical address.

   Access:
      read-write.

   Status:
      mandatory.


   OBJECT:
   -------
      atPhysAddress { atEntry 2 }

   Syntax:
      OCTET STRING

   Definition:
      The media-dependent physical address.



Rose & McCloghrie                                              [Page 11]

RFC 1065                          SMI                        August 1988


   Access:
      read-write.

   Status:
      mandatory.


   OBJECT:
   -------
      atNetAddress { atEntry 3 }

   Syntax:
      NetworkAddress

   Definition:
      The network address corresponding to the media-dependent physical
      address.

   Access:
      read-write.

   Status:
      mandatory.

   Then, a fourth object type might also be defined in the MIB:


   OBJECT:
   -------
      atEntry { atTable 1 }

   Syntax:

      AtEntry ::= SEQUENCE {
            atIndex
            INTEGER,
            atPhysAddress
            OCTET STRING,
            atNetAddress
            NetworkAddress
            }

   Definition:
      An entry in the address translation table.

   Access:
      read-write.




Rose & McCloghrie                                              [Page 12]

RFC 1065                          SMI                        August 1988


   Status:
      mandatory.

   Each instance of this object type comprises information represented
   by instances of the former three object types.  An object type
   defined in this way is called a list.

   Similarly, tables can be formed by aggregations of a list type.  For
   example, a fifth object type might also be defined in the MIB:


   OBJECT:
   ------
      atTable { at 1 }

   Syntax:
      SEQUENCE OF AtEntry

   Definition:
      The address translation table.

   Access:
      read-write.

   Status:
      mandatory.

   such that each instance of the atTable object comprises information
   represented by the set of atEntry object types that collectively
   constitute a given atTable object instance, that is, a given address
   translation table.

   Consider how one might refer to a simple object within a table.
   Continuing with the previous example, one might name the object type

      { atPhysAddress }

   and specify, using a protocol-specific mechanism, the object instance

      { atNetAddress } = { internet "10.0.0.52" }

   This pairing of object type and object instance would refer to all
   instances of atPhysAddress which are part of any entry in some
   address translation table for which the associated atNetAddress value
   is { internet "10.0.0.52" }.

   To continue with this example, consider how one might refer to an
   aggregate object (list) within a table.  Naming the object type



Rose & McCloghrie                                              [Page 13]

RFC 1065                          SMI                        August 1988


      { atEntry }

   and specifying, using a protocol-specific mechanism, the object
   instance

      { atNetAddress } = { internet "10.0.0.52" }

   refers to all instances of entries in the table for which the
   associated atNetAddress value is { internet "10.0.0.52" }.

   Each management protocol must provide a mechanism for accessing
   simple (non-aggregate) object types.  Each management protocol
   specifies whether or not it supports access to aggregate object
   types.  Further, the protocol must specify which instances are
   "returned" when an object type/instance pairing refers to more than
   one instance of a type.

   To afford support for a variety of management protocols, all
   information by which instances of a given object type may be usefully
   distinguished, one from another, is represented by instances of
   object types defined in the MIB.

4.3.  Macros for Managed Objects

   In order to facilitate the use of tools for processing the definition
   of the MIB, the OBJECT-TYPE macro may be used.  This macro permits
   the key aspects of an object type to be represented in a formal way.

      OBJECT-TYPE MACRO ::=
      BEGIN
          TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
                            "ACCESS" Access
                            "STATUS" Status
          VALUE NOTATION ::= value (VALUE ObjectName)

          Access ::= "read-only"
                          | "read-write"
                          | "write-only"
                          | "not-accessible"
          Status ::= "mandatory"
                          | "optional"
                          | "obsolete"
          END

   Given the object types defined earlier, we might imagine the
   following definitions being present in the MIB:

                  atIndex OBJECT-TYPE



Rose & McCloghrie                                              [Page 14]