home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1065 < prev    next >
Text File  |  1991-04-21  |  38KB  |  1,179 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            M. Rose
  8. Request for Comments: 1065                                 K. McCloghrie
  9.                                                                      TWG
  10.                                                              August 1988
  11.  
  12.  
  13.  
  14.          Structure and Identification of Management Information
  15.                        for TCP/IP-based internets
  16.  
  17.                            Table of Contents
  18.  
  19. 1. Status of this Memo .............................................  1
  20. 2. Introduction ....................................................  2
  21. 3. Structure and Identification of Management Information...........  4
  22. 3.1 Names ..........................................................  4
  23. 3.1.1 DIRECTORY ....................................................  5
  24. 3.1.2 MGMT .........................................................  6
  25. 3.1.3 EXPERIMENTAL .................................................  6
  26. 3.1.4 PRIVATE ......................................................  7
  27. 3.2 Syntax .........................................................  7
  28. 3.2.1 Primitive Types ..............................................  7
  29. 3.2.1.1 Guidelines for Enumerated INTEGERs .........................  7
  30. 3.2.2 Constructor Types ............................................  8
  31. 3.2.3 Defined Types ................................................  8
  32. 3.2.3.1 NetworkAddress .............................................  8
  33. 3.2.3.2 IpAddress ..................................................  8
  34. 3.2.3.3 Counter ....................................................  8
  35. 3.2.3.4 Gauge ......................................................  9
  36. 3.2.3.5 TimeTicks ..................................................  9
  37. 3.2.3.6 Opaque .....................................................  9
  38. 3.3 Encodings ......................................................  9
  39. 4. Managed Objects ................................................. 10
  40. 4.1 Guidelines for Object Names .................................... 10
  41. 4.2 Object Types and Instances ..................................... 10
  42. 4.3 Macros for Managed Objects ..................................... 14
  43. 5. Extensions to the MIB ........................................... 16
  44. 6. Definitions ..................................................... 17
  45. 7. Acknowledgements ................................................ 20
  46. 8. References ...................................................... 21
  47.  
  48. 1.  Status of this Memo
  49.  
  50.    This memo provides the common definitions for the structure and
  51.    identification of management information for TCP/IP-based internets.
  52.    In particular, together with its companion memos which describe the
  53.    initial management information base along with the initial network
  54.    management protocol, these documents provide a simple, workable
  55.  
  56.  
  57.  
  58. Rose & McCloghrie                                               [Page 1]
  59.  
  60. RFC 1065                          SMI                        August 1988
  61.  
  62.  
  63.    architecture and system for managing TCP/IP-based internets and in
  64.    particular, the Internet.
  65.  
  66.    This memo specifies a draft standard for the Internet community.
  67.    TCP/IP implementations in the Internet which are network manageable
  68.    are expected to adopt and implement this specification.
  69.  
  70.    Distribution of this memo is unlimited.
  71.  
  72. 2.  Introduction
  73.  
  74.    This memo describes the common structures and identification scheme
  75.    for the definition of management information used in managing
  76.    TCP/IP-based internets.  Included are descriptions of an object
  77.    information model for network management along with a set of generic
  78.    types used to describe management information.  Formal descriptions
  79.    of the structure are given using Abstract Syntax Notation One (ASN.1)
  80.    [1].
  81.  
  82.    This memo is largely concerned with organizational concerns and
  83.    administrative policy: it neither specifies the objects which are
  84.    managed, nor the protocols used to manage those objects.  These
  85.    concerns are addressed by two companion memos: one describing the
  86.    Management Information Base (MIB) [2], and the other describing the
  87.    Simple Network Management Protocol (SNMP) [3].
  88.  
  89.    This memo is based in part on the work of the Internet Engineering
  90.    Task Force, particularly the working note titled "Structure and
  91.    Identification of Management Information for the Internet" [4].  This
  92.    memo uses a skeletal structure derived from that note, but differs in
  93.    one very significant way:that note focuses entirely on the use of
  94.    OSI-style network management.  As such, it is not suitable for use in
  95.    the short-term for which a non-OSI protocol, the SNMP, has been
  96.    designated as the standard.
  97.  
  98.    This memo attempts to achieve two goals: simplicity and
  99.    extensibility.  Both are motivated by a common concern: although the
  100.    management of TCP/IP-based internets has been a topic of study for
  101.    some time, the authors do not feel that the depth and breadth of such
  102.    understanding is complete.  More bluntly, we feel that previous
  103.    experiences, while giving the community insight, are hardly
  104.    conclusive.  By fostering a simple SMI, the minimal number of
  105.    constraints are imposed on future potential approaches; further, by
  106.    fostering an extensible SMI, the maximal number of potential
  107.    approaches are available for experimentation.
  108.  
  109.    It is believed that this memo and its two companions comply with the
  110.    guidelines set forth in RFC 1052, "IAB Recommendations for the
  111.  
  112.  
  113.  
  114. Rose & McCloghrie                                               [Page 2]
  115.  
  116. RFC 1065                          SMI                        August 1988
  117.  
  118.  
  119.    Development of Internet Network Management Standards" [5].  In
  120.    particular, we feel that this memo, along with the memo describing
  121.    the initial management information base, provide a solid basis for
  122.    network management of the Internet.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Rose & McCloghrie                                               [Page 3]
  171.  
  172. RFC 1065                          SMI                        August 1988
  173.  
  174.  
  175. 3.  Structure and Identification of Management Information
  176.  
  177.    Managed objects are accessed via a virtual information store, termed
  178.    the Management Information Base or MIB.  Objects in the MIB are
  179.    defined using Abstract Syntax Notation One (ASN.1) [1].
  180.  
  181.    Each type of object (termed an object type) has a name, a syntax, and
  182.    an encoding.  The name is represented uniquely as an OBJECT
  183.    IDENTIFIER.  An OBJECT IDENTIFIER is an administratively assigned
  184.    name.  The administrative policies used for assigning names are
  185.    discussed later in this memo.
  186.  
  187.    The syntax for an object type defines the abstract data structure
  188.    corresponding to that object type.  For example, the structure of a
  189.    given object type might be an INTEGER or OCTET STRING.  Although in
  190.    general, we should permit any ASN.1 construct to be available for use
  191.    in defining the syntax of an object type, this memo purposely
  192.    restricts the ASN.1 constructs which may be used.  These restrictions
  193.    are made solely for the sake of simplicity.
  194.  
  195.    The encoding of an object type is simply how instances of that object
  196.    type are represented using the object's type syntax.  Implicitly tied
  197.    to the notion of an object's syntax and encoding is how the object is
  198.    represented when being transmitted on the network.  This memo
  199.    specifies the use of the basic encoding rules of ASN.1 [6].
  200.  
  201.    It is beyond the scope of this memo to define either the initial MIB
  202.    used for network management or the network management protocol.  As
  203.    mentioned earlier, these tasks are left to the companion memos.  This
  204.    memo attempts to minimize the restrictions placed upon its companions
  205.    so as to maximize generality.  However, in some cases, restrictions
  206.    have been made (e.g., the syntax which may be used when defining
  207.    object types in the MIB) in order to encourage a particular style of
  208.    management.  Future editions of this memo may remove these
  209.    restrictions.
  210.  
  211. 3.1.  Names
  212.  
  213.    Names are used to identify managed objects.  This memo specifies
  214.    names which are hierarchical in nature.  The OBJECT IDENTIFIER
  215.    concept is used to model this notion.  An OBJECT IDENTIFIER can be
  216.    used for purposes other than naming managed object types; for
  217.    example, each international standard has an OBJECT IDENTIFIER
  218.    assigned to it for the purposes of identification.  In short, OBJECT
  219.    IDENTIFIERs are a means for identifying some object, regardless of
  220.    the semantics associated with the object (e.g., a network object, a
  221.    standards document, etc.)
  222.  
  223.  
  224.  
  225.  
  226. Rose & McCloghrie                                               [Page 4]
  227.  
  228. RFC 1065                          SMI                        August 1988
  229.  
  230.  
  231.    An OBJECT IDENTIFIER is a sequence of integers which traverse a
  232.    global tree.  The tree consists of a root connected to a number of
  233.    labeled nodes via edges.  Each node may, in turn, have children of
  234.    its own which are labeled.  In this case, we may term the node a
  235.    subtree.  This process may continue to an arbitrary level of depth.
  236.    Central to the notion of the OBJECT IDENTIFIER is the understanding
  237.    that administrative control of the meanings assigned to the nodes may
  238.    be delegated as one traverses the tree.  A label is a pairing of a
  239.    brief textual description and an integer.
  240.  
  241.    The root node itself is unlabeled, but has at least three children
  242.    directly under it:  one node is administered by the International
  243.    Standards Organization, with label iso(1); another is administrated
  244.    by the International Telegraph and Telephone Consultative Committee,
  245.    with label ccitt(2); and the third is jointly administered by the ISO
  246.    and the CCITT, joint-iso-ccitt(3).
  247.  
  248.    Under the iso(1) node, the ISO has designated one subtree for use by
  249.    other (inter)national organizations, org(3).  Of the children nodes
  250.    present, two have been assigned to the U.S. National Bureau of
  251.    Standards.  One of these subtrees has been transferred by the NBS to
  252.    the U.S. Department of Defense, dod(6).
  253.  
  254.    As of this writing, the DoD has not indicated how it will manage its
  255.    subtree of OBJECT IDENTIFIERs.  This memo assumes that DoD will
  256.    allocate a node to the Internet community, to be administered by the
  257.    Internet Activities Board (IAB) as follows:
  258.  
  259.       internet    OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
  260.  
  261.    That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
  262.    prefix:
  263.  
  264.       1.3.6.1.
  265.  
  266.    This memo, as an RFC approved by the IAB, now specifies the policy
  267.    under which this subtree of OBJECT IDENTIFIERs is administered.
  268.    Initially, four nodes are present:
  269.  
  270.       directory     OBJECT IDENTIFIER ::= { internet 1 }
  271.       mgmt          OBJECT IDENTIFIER ::= { internet 2 }
  272.       experimental   OBJECT IDENTIFIER ::= { internet 3 }
  273.       private       OBJECT IDENTIFIER ::= { internet 4 }
  274.  
  275. 3.1.1.  DIRECTORY
  276.  
  277.    The directory(1) subtree is reserved for use with a future memo that
  278.    discusses how the OSI Directory may be used in the Internet.
  279.  
  280.  
  281.  
  282. Rose & McCloghrie                                               [Page 5]
  283.  
  284. RFC 1065                          SMI                        August 1988
  285.  
  286.  
  287. 3.1.2.  MGMT
  288.  
  289.    The mgmt(2) subtree is used to identify objects which are defined in
  290.    IAB-approved documents.  Administration of the mgmt(2) subtree is
  291.    delegated by the IAB to the Assigned Numbers authority for the
  292.    Internet.  As RFCs which define new versions of the Internet-standard
  293.    Management Information Base are approved, they are assigned an OBJECT
  294.    IDENTIFIER by the Assigned Numbers authority for identifying the
  295.    objects defined by that memo.
  296.  
  297.    For example, the RFC which defines the initial Internet standard MIB
  298.    would be assigned management document number 1.  This RFC would use
  299.    the OBJECT IDENTIFIER
  300.  
  301.       { mgmt 1 }
  302.  
  303.    or
  304.  
  305.       1.3.6.1.2.1
  306.  
  307.    in defining the Internet-standard MIB.
  308.  
  309.    The generation of new versions of the Internet-standard MIB is a
  310.    rigorous process.  Section 5 of this memo describes the rules used
  311.    when a new version is defined.
  312.  
  313. 3.1.3.  EXPERIMENTAL
  314.  
  315.    The experimental(3) subtree is used to identify objects used in
  316.    Internet experiments.  Administration of the experimental(3) subtree
  317.    is delegated by the IAB to the Assigned Numbers authority of the
  318.    Internet.
  319.  
  320.    For example, an experimenter might received number 17, and would have
  321.    available the OBJECT IDENTIFIER
  322.  
  323.       { experimental 17 }
  324.  
  325.    or
  326.  
  327.       1.3.6.1.3.17
  328.  
  329.    for use.
  330.  
  331.    As a part of the assignment process, the Assigned Numbers authority
  332.    may make requirements as to how that subtree is used.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Rose & McCloghrie                                               [Page 6]
  339.  
  340. RFC 1065                          SMI                        August 1988
  341.  
  342.  
  343. 3.1.4.  PRIVATE
  344.  
  345.    The private(4) subtree is used to identify objects defined
  346.    unilaterally.  Administration of the private(4) subtree is delegated
  347.    by the IAB to the Assigned Numbers authority for the Internet.
  348.    Initially, this subtree has at least one child:
  349.  
  350.       enterprises   OBJECT IDENTIFIER ::= { private 1 }
  351.  
  352.    The enterprises(1) subtree is used, among other things, to permit
  353.    parties providing networking subsystems to register models of their
  354.    products.
  355.  
  356.    Upon receiving a subtree, the enterprise may, for example, define new
  357.    MIB objects in this subtree.  In addition, it is strongly recommended
  358.    that the enterprise will also register its networking subsystems
  359.    under this subtree, in order to provide an unambiguous identification
  360.    mechanism for use in management protocols.  For example, if the
  361.    "Flintstones, Inc."  enterprise produced networking subsystems, then
  362.    they could request a node under the enterprises subtree from the
  363.    Assigned Numbers authority.  Such a node might be numbered:
  364.  
  365.       1.3.6.1.4.1.42
  366.  
  367.    The "Flintstones, Inc." enterprise might then register their "Fred
  368.    Router" under the name of:
  369.  
  370.       1.3.6.1.4.1.42.1.1
  371.  
  372. 3.2.  Syntax
  373.  
  374.    Syntax is used to define the structure corresponding to object types.
  375.    ASN.1 constructs are used to define this structure, although the full
  376.    generality of ASN.1 is not permitted.
  377.  
  378.    The ASN.1 type ObjectSyntax defines the different syntaxes which may
  379.    be used in defining an object type.
  380.  
  381. 3.2.1.  Primitive Types
  382.  
  383.    Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT
  384.    IDENTIFIER, and NULL are permitted.  These are sometimes referred to
  385.    as non-aggregate types.
  386.  
  387. 3.2.1.1.  Guidelines for Enumerated INTEGERs
  388.  
  389.    If an enumerated INTEGER is listed as an object type, then a named-
  390.    number having the value 0 shall not be present in the list of
  391.  
  392.  
  393.  
  394. Rose & McCloghrie                                               [Page 7]
  395.  
  396. RFC 1065                          SMI                        August 1988
  397.  
  398.  
  399.    enumerations.  Use of this value is prohibited.
  400.  
  401. 3.2.2.  Constructor Types
  402.  
  403.    The ASN.1 constructor type SEQUENCE is permitted, providing that it
  404.    is used to generate either lists or tables.
  405.  
  406.    For lists, the syntax takes the form:
  407.  
  408.       SEQUENCE { <type1>, ..., <typeN> }
  409.  
  410.    where each <type> resolves to one of the ASN.1 primitive types listed
  411.    above.  Further, these ASN.1 types are always present (the DEFAULT
  412.    and OPTIONAL clauses do not appear in the SEQUENCE definition).
  413.  
  414.    For tables, the syntax takes the form:
  415.  
  416.       SEQUENCE OF <entry>
  417.  
  418.    where <entry> resolves to a list constructor.
  419.  
  420.    Lists and tables are sometimes referred to as aggregate types.
  421.  
  422. 3.2.3.  Defined Types
  423.  
  424.    In addition, new application-wide types may be defined, so long as
  425.    they resolve into an IMPLICITly defined ASN.1 primitive type, list,
  426.    table, or some other application-wide type.  Initially, few
  427.    application-wide types are defined.  Future memos will no doubt
  428.    define others once a consensus is reached.
  429.  
  430. 3.2.3.1.  NetworkAddress
  431.  
  432.    This CHOICE represents an address from one of possibly several
  433.    protocol families.  Currently, only one protocol family, the Internet
  434.    family, is present in this CHOICE.
  435.  
  436. 3.2.3.2.  IpAddress
  437.  
  438.    This application-wide type represents a 32-bit internet address.  It
  439.    is represented as an OCTET STRING of length 4, in network byte-order.
  440.  
  441.    When this ASN.1 type is encoded using the ASN.1 basic encoding rules,
  442.    only the primitive encoding form shall be used.
  443.  
  444. 3.2.3.3.  Counter
  445.  
  446.    This application-wide type represents a non-negative integer which
  447.  
  448.  
  449.  
  450. Rose & McCloghrie                                               [Page 8]
  451.  
  452. RFC 1065                          SMI                        August 1988
  453.  
  454.  
  455.    monotonically increases until it reaches a maximum value, when it
  456.    wraps around and starts increasing again from zero.  This memo
  457.    specifies a maximum value of 2^32-1 (4294967295 decimal) for
  458.    counters.
  459.  
  460. 3.2.3.4.  Gauge
  461.  
  462.    This application-wide type represents a non-negative integer, which
  463.    may increase or decrease, but which latches at a maximum value.  This
  464.    memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
  465.    gauges.
  466.  
  467. 3.2.3.5.  TimeTicks
  468.  
  469.    This application-wide type represents a non-negative integer which
  470.    counts the time in hundredths of a second since some epoch.  When
  471.    object types are defined in the MIB which use this ASN.1 type, the
  472.    description of the object type identifies the reference epoch.
  473.  
  474. 3.2.3.6.  Opaque
  475.  
  476.    This application-wide type supports the capability to pass arbitrary
  477.    ASN.1 syntax.  A value is encoded using the ASN.1 basic rules into a
  478.    string of octets.  This, in turn, is encoded as an OCTET STRING, in
  479.    effect "double-wrapping" the original ASN.1 value.
  480.  
  481.    Note that a conforming implementation need only be able to accept and
  482.    recognize opaquely-encoded data.  It need not be able to unwrap the
  483.    data and then interpret its contents.
  484.  
  485.    Further note that by use of the ASN.1 EXTERNAL type, encodings other
  486.    than ASN.1 may be used in opaquely-encoded data.
  487.  
  488. 3.3.  Encodings
  489.  
  490.    Once an instance of an object type has been identified, its value may
  491.    be transmitted by applying the basic encoding rules of ASN.1 to the
  492.    syntax for the object type.
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Rose & McCloghrie                                               [Page 9]
  507.  
  508. RFC 1065                          SMI                        August 1988
  509.  
  510.  
  511. 4.  Managed Objects
  512.  
  513.    Although it is not the purpose of this memo to define objects in the
  514.    MIB, this memo specifies a format to be used by other memos which
  515.    define these objects.
  516.  
  517.    An object type definition consists of five fields:
  518.  
  519.    OBJECT:
  520.    -------
  521.       A textual name, termed the OBJECT DESCRIPTOR, for the object type,
  522.       along with its corresponding OBJECT IDENTIFIER.
  523.  
  524.    Syntax:
  525.       The abstract syntax for the object type.  This must resolve to an
  526.       instance of the ASN.1 type ObjectSyntax (defined below).
  527.  
  528.    Definition:
  529.       A textual description of the semantics of the object type.
  530.       Implementations should ensure that their instance of the object
  531.       fulfills this definition since this MIB is intended for use in
  532.       multi-vendor environments.  As such it is vital that objects have
  533.       consistent meaning across all machines.
  534.  
  535.    Access:
  536.       One of read-only, read-write, write-only, or not-accessible.
  537.  
  538.    Status:
  539.       One of mandatory, optional, or obsolete.
  540.  
  541.    Future memos may also specify other fields for the objects which they
  542.    define.
  543.  
  544. 4.1.  Guidelines for Object Names
  545.  
  546.    No object type in the Internet-Standard MIB shall use a sub-
  547.    identifier of 0 in its name.  This value is reserved for use with
  548.    future extensions.
  549.  
  550.    Each OBJECT DESCRIPTOR corresponding to an object type in the
  551.    internet-standard MIB shall be a unique, but mnemonic, printable
  552.    string.  This promotes a common language for humans to use when
  553.    discussing the MIB and also facilitates simple table mappings for
  554.    user interfaces.
  555.  
  556. 4.2.  Object Types and Instances
  557.  
  558.    An object type is a definition of a kind of managed object; it is
  559.  
  560.  
  561.  
  562. Rose & McCloghrie                                              [Page 10]
  563.  
  564. RFC 1065                          SMI                        August 1988
  565.  
  566.  
  567.    declarative in nature.  In contrast, an object instance is an
  568.    instantiation of an object type which has been bound to a value.  For
  569.    example, the notion of an entry in a routing table might be defined
  570.    in the MIB.  Such a notion corresponds to an object type; individual
  571.    entries in a particular routing table which exist at some time are
  572.    object instances of that object type.
  573.  
  574.    A collection of object types is defined in the MIB.  Each such
  575.    subject type is uniquely named by its OBJECT IDENTIFIER and also has
  576.    a textual name, which is its OBJECT DESCRIPTOR.  The means whereby
  577.    object instances are referenced is not defined in the MIB.  Reference
  578.    to object instances is achieved by a protocol-specific mechanism: it
  579.    is the responsibility of each management protocol adhering to the SMI
  580.    to define this mechanism.
  581.  
  582.    An object type may be defined in the MIB such that an instance of
  583.    that object type represents an aggregation of information also
  584.    represented by instances of some number of "subordinate" object
  585.    types.  For example, suppose the following object types are defined
  586.    in the MIB:
  587.  
  588.  
  589.    OBJECT:
  590.    -------
  591.       atIndex { atEntry 1 }
  592.  
  593.    Syntax:
  594.       INTEGER
  595.  
  596.    Definition:
  597.       The interface number for the physical address.
  598.  
  599.    Access:
  600.       read-write.
  601.  
  602.    Status:
  603.       mandatory.
  604.  
  605.  
  606.    OBJECT:
  607.    -------
  608.       atPhysAddress { atEntry 2 }
  609.  
  610.    Syntax:
  611.       OCTET STRING
  612.  
  613.    Definition:
  614.       The media-dependent physical address.
  615.  
  616.  
  617.  
  618. Rose & McCloghrie                                              [Page 11]
  619.  
  620. RFC 1065                          SMI                        August 1988
  621.  
  622.  
  623.    Access:
  624.       read-write.
  625.  
  626.    Status:
  627.       mandatory.
  628.  
  629.  
  630.    OBJECT:
  631.    -------
  632.       atNetAddress { atEntry 3 }
  633.  
  634.    Syntax:
  635.       NetworkAddress
  636.  
  637.    Definition:
  638.       The network address corresponding to the media-dependent physical
  639.       address.
  640.  
  641.    Access:
  642.       read-write.
  643.  
  644.    Status:
  645.       mandatory.
  646.  
  647.    Then, a fourth object type might also be defined in the MIB:
  648.  
  649.  
  650.    OBJECT:
  651.    -------
  652.       atEntry { atTable 1 }
  653.  
  654.    Syntax:
  655.  
  656.       AtEntry ::= SEQUENCE {
  657.             atIndex
  658.             INTEGER,
  659.             atPhysAddress
  660.             OCTET STRING,
  661.             atNetAddress
  662.             NetworkAddress
  663.             }
  664.  
  665.    Definition:
  666.       An entry in the address translation table.
  667.  
  668.    Access:
  669.       read-write.
  670.  
  671.  
  672.  
  673.  
  674. Rose & McCloghrie                                              [Page 12]
  675.  
  676. RFC 1065                          SMI                        August 1988
  677.  
  678.  
  679.    Status:
  680.       mandatory.
  681.  
  682.    Each instance of this object type comprises information represented
  683.    by instances of the former three object types.  An object type
  684.    defined in this way is called a list.
  685.  
  686.    Similarly, tables can be formed by aggregations of a list type.  For
  687.    example, a fifth object type might also be defined in the MIB:
  688.  
  689.  
  690.    OBJECT:
  691.    ------
  692.       atTable { at 1 }
  693.  
  694.    Syntax:
  695.       SEQUENCE OF AtEntry
  696.  
  697.    Definition:
  698.       The address translation table.
  699.  
  700.    Access:
  701.       read-write.
  702.  
  703.    Status:
  704.       mandatory.
  705.  
  706.    such that each instance of the atTable object comprises information
  707.    represented by the set of atEntry object types that collectively
  708.    constitute a given atTable object instance, that is, a given address
  709.    translation table.
  710.  
  711.    Consider how one might refer to a simple object within a table.
  712.    Continuing with the previous example, one might name the object type
  713.  
  714.       { atPhysAddress }
  715.  
  716.    and specify, using a protocol-specific mechanism, the object instance
  717.  
  718.       { atNetAddress } = { internet "10.0.0.52" }
  719.  
  720.    This pairing of object type and object instance would refer to all
  721.    instances of atPhysAddress which are part of any entry in some
  722.    address translation table for which the associated atNetAddress value
  723.    is { internet "10.0.0.52" }.
  724.  
  725.    To continue with this example, consider how one might refer to an
  726.    aggregate object (list) within a table.  Naming the object type
  727.  
  728.  
  729.  
  730. Rose & McCloghrie                                              [Page 13]
  731.  
  732. RFC 1065                          SMI                        August 1988
  733.  
  734.  
  735.       { atEntry }
  736.  
  737.    and specifying, using a protocol-specific mechanism, the object
  738.    instance
  739.  
  740.       { atNetAddress } = { internet "10.0.0.52" }
  741.  
  742.    refers to all instances of entries in the table for which the
  743.    associated atNetAddress value is { internet "10.0.0.52" }.
  744.  
  745.    Each management protocol must provide a mechanism for accessing
  746.    simple (non-aggregate) object types.  Each management protocol
  747.    specifies whether or not it supports access to aggregate object
  748.    types.  Further, the protocol must specify which instances are
  749.    "returned" when an object type/instance pairing refers to more than
  750.    one instance of a type.
  751.  
  752.    To afford support for a variety of management protocols, all
  753.    information by which instances of a given object type may be usefully
  754.    distinguished, one from another, is represented by instances of
  755.    object types defined in the MIB.
  756.  
  757. 4.3.  Macros for Managed Objects
  758.  
  759.    In order to facilitate the use of tools for processing the definition
  760.    of the MIB, the OBJECT-TYPE macro may be used.  This macro permits
  761.    the key aspects of an object type to be represented in a formal way.
  762.  
  763.       OBJECT-TYPE MACRO ::=
  764.       BEGIN
  765.           TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
  766.                             "ACCESS" Access
  767.                             "STATUS" Status
  768.           VALUE NOTATION ::= value (VALUE ObjectName)
  769.  
  770.           Access ::= "read-only"
  771.                           | "read-write"
  772.                           | "write-only"
  773.                           | "not-accessible"
  774.           Status ::= "mandatory"
  775.                           | "optional"
  776.                           | "obsolete"
  777.           END
  778.  
  779.    Given the object types defined earlier, we might imagine the
  780.    following definitions being present in the MIB:
  781.  
  782.                   atIndex OBJECT-TYPE
  783.  
  784.  
  785.  
  786. Rose & McCloghrie                                              [Page 14]
  787.  
  788. RFC 1065                          SMI                        August 1988
  789.  
  790.  
  791.                           SYNTAX  INTEGER
  792.                           ACCESS  read-write
  793.                           STATUS  mandatory
  794.                           ::= { atEntry 1 }
  795.  
  796.                   atPhysAddress OBJECT-TYPE
  797.                           SYNTAX  OCTET STRING
  798.                           ACCESS  read-write
  799.                           STATUS  mandatory
  800.                           ::= { atEntry 2 }
  801.  
  802.                   atNetAddress OBJECT-TYPE
  803.                           SYNTAX  NetworkAddress
  804.                           ACCESS  read-write
  805.                           STATUS  mandatory
  806.                           ::= { atEntry 3 }
  807.  
  808.                   atEntry OBJECT-TYPE
  809.                           SYNTAX  AtEntry
  810.                           ACCESS  read-write
  811.                           STATUS  mandatory
  812.                           ::= { atTable 1 }
  813.  
  814.                   atTable OBJECT-TYPE
  815.                           SYNTAX  SEQUENCE OF AtEntry
  816.                           ACCESS  read-write
  817.                           STATUS  mandatory
  818.                           ::= { at 1 }
  819.  
  820.                   AtEntry ::= SEQUENCE {
  821.                       atIndex
  822.                           INTEGER,
  823.                       atPhysAddress
  824.                           OCTET STRING,
  825.                       atNetAddress
  826.                           NetworkAddress
  827.                   }
  828.  
  829.    The first five definitions describe object types, relating, for
  830.    example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
  831.    atEntry 1 }.  In addition, the syntax of this object is defined
  832.    (INTEGER) along with the access permitted (read-write) and status
  833.    (mandatory).  The sixth definition describes an ASN.1 type called
  834.    AtEntry.
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Rose & McCloghrie                                              [Page 15]
  843.  
  844. RFC 1065                          SMI                        August 1988
  845.  
  846.  
  847. 5.  Extensions to the MIB
  848.  
  849.    Every Internet-standard MIB document obsoletes all previous such
  850.    documents.  The portion of a name, termed the tail, following the
  851.    OBJECT IDENTIFIER
  852.  
  853.       { mgmt version-number }
  854.  
  855.    used to name objects shall remain unchanged between versions.  New
  856.    versions may:
  857.  
  858.       (1) declare old object types obsolete (if necessary), but not
  859.       delete their names;
  860.  
  861.       (2) augment the definition of an object type corresponding to a
  862.       list by appending non-aggregate object types to the object types
  863.       in the list; or,
  864.  
  865.       (3) define entirely new object types.
  866.  
  867.    New versions may not:
  868.  
  869.       (1) change the semantics of any previously defined object without
  870.       changing the name of that object.
  871.  
  872.    These rules are important because they admit easier support for
  873.    multiple versions of the Internet-standard MIB.  In particular, the
  874.    semantics associated with the tail of a name remain constant
  875.    throughout different versions of the MIB.  Because multiple versions
  876.    of the MIB may thus coincide in "tail-space," implementations
  877.    supporting multiple versions of the MIB can be vastly simplified.
  878.  
  879.    However, as a consequence, a management agent might return an
  880.    instance corresponding to a superset of the expected object type.
  881.    Following the principle of robustness, in this exceptional case, a
  882.    manager should ignore any additional information beyond the
  883.    definition of the expected object type.  However, the robustness
  884.    principle requires that one exercise care with respect to control
  885.    actions: if an instance does not have the same syntax as its expected
  886.    object type, then those control actions must fail.  In both the
  887.    monitoring and control cases, the name of an object returned by an
  888.    operation must be identical to the name requested by an operation.
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Rose & McCloghrie                                              [Page 16]
  899.  
  900. RFC 1065                          SMI                        August 1988
  901.  
  902.  
  903. 6.  Definitions
  904.  
  905.            RFC1065-SMI DEFINITIONS ::= BEGIN
  906.  
  907.            EXPORTS -- EVERYTHING
  908.                    internet, directory, mgmt,
  909.                    experimental, private, enterprises,
  910.                    OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,
  911.                    ApplicationSyntax, NetworkAddress, IpAddress,
  912.                    Counter, Gauge, TimeTicks, Opaque;
  913.  
  914.             -- the path to the root
  915.  
  916.             internet      OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
  917.  
  918.             directory     OBJECT IDENTIFIER ::= { internet 1 }
  919.  
  920.             mgmt          OBJECT IDENTIFIER ::= { internet 2 }
  921.  
  922.             experimental  OBJECT IDENTIFIER ::= { internet 3 }
  923.  
  924.             private       OBJECT IDENTIFIER ::= { internet 4 }
  925.             enterprises   OBJECT IDENTIFIER ::= { private 1 }
  926.  
  927.  
  928.             -- definition of object types
  929.  
  930.             OBJECT-TYPE MACRO ::=
  931.             BEGIN
  932.                 TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
  933.                                   "ACCESS" Access
  934.                                   "STATUS" Status
  935.                 VALUE NOTATION ::= value (VALUE ObjectName)
  936.  
  937.                 Access ::= "read-only"
  938.                                 | "read-write"
  939.                                 | "write-only"
  940.                                 | "not-accessible"
  941.                 Status ::= "mandatory"
  942.                                 | "optional"
  943.                                 | "obsolete"
  944.             END
  945.  
  946.                -- names of objects in the MIB
  947.  
  948.                ObjectName ::=
  949.                    OBJECT IDENTIFIER
  950.  
  951.  
  952.  
  953.  
  954. Rose & McCloghrie                                              [Page 17]
  955.  
  956. RFC 1065                          SMI                        August 1988
  957.  
  958.  
  959.                -- syntax of objects in the MIB
  960.  
  961.                ObjectSyntax ::=
  962.                    CHOICE {
  963.                        simple
  964.                            SimpleSyntax,
  965.  
  966.                -- note that simple SEQUENCEs are not directly
  967.                -- mentioned here to keep things simple (i.e.,
  968.                -- prevent mis-use).  However, application-wide
  969.                -- types which are IMPLICITly encoded simple
  970.                -- SEQUENCEs may appear in the following CHOICE
  971.  
  972.                           application-wide
  973.                               ApplicationSyntax
  974.                       }
  975.  
  976.                   SimpleSyntax ::=
  977.                       CHOICE {
  978.                           number
  979.                               INTEGER,
  980.  
  981.                           string
  982.                               OCTET STRING,
  983.  
  984.                           object
  985.                               OBJECT IDENTIFIER,
  986.  
  987.                           empty
  988.                               NULL
  989.                       }
  990.  
  991.                   ApplicationSyntax ::=
  992.                       CHOICE {
  993.                           address
  994.                               NetworkAddress,
  995.  
  996.                           counter
  997.                               Counter,
  998.  
  999.                           gauge
  1000.                               Gauge,
  1001.  
  1002.                           ticks
  1003.                               TimeTicks,
  1004.  
  1005.                           arbitrary
  1006.                               Opaque
  1007.  
  1008.  
  1009.  
  1010. Rose & McCloghrie                                              [Page 18]
  1011.  
  1012. RFC 1065                          SMI                        August 1988
  1013.  
  1014.  
  1015.                   -- other application-wide types, as they are
  1016.                   -- defined, will be added here
  1017.                       }
  1018.  
  1019.  
  1020.                   -- application-wide types
  1021.  
  1022.                   NetworkAddress ::=
  1023.                       CHOICE {
  1024.                           internet
  1025.                               IpAddress
  1026.                       }
  1027.  
  1028.                   IpAddress ::=
  1029.                       [APPLICATION 0]          -- in network-byte order
  1030.                           IMPLICIT OCTET STRING (SIZE (4))
  1031.  
  1032.                   Counter ::=
  1033.                       [APPLICATION 1]
  1034.                           IMPLICIT INTEGER (0..4294967295)
  1035.  
  1036.                   Gauge ::=
  1037.                       [APPLICATION 2]
  1038.                           IMPLICIT INTEGER (0..4294967295)
  1039.  
  1040.                   TimeTicks ::=
  1041.                       [APPLICATION 3]
  1042.                           IMPLICIT INTEGER
  1043.  
  1044.                   Opaque ::=
  1045.                       [APPLICATION 4]          -- arbitrary ASN.1 value,
  1046.                           IMPLICIT OCTET STRING   --   "double-wrapped"
  1047.  
  1048.                   END
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Rose & McCloghrie                                              [Page 19]
  1067.  
  1068. RFC 1065                          SMI                        August 1988
  1069.  
  1070.  
  1071. 7.  Acknowledgements
  1072.  
  1073.    This memo was influenced by three sets of contributors:
  1074.  
  1075.    First, Lee Labarre of the MITRE Corporation, who as author of the
  1076.    NETMAN SMI [4], presented the basic roadmap for the SMI.
  1077.  
  1078.    Second, several individuals who provided valuable comments on this
  1079.    memo prior to its initial distribution:
  1080.  
  1081.          James Davin, Proteon
  1082.          Mark S. Fedor, NYSERNet
  1083.          Craig Partridge, BBN Laboratories
  1084.          Martin Lee Schoffstall, Rensselaer Polytechnic Institute
  1085.          Wengyik Yeong, NYSERNet
  1086.  
  1087.  
  1088.    Third, the IETF MIB working group:
  1089.  
  1090.          Karl Auerbach, Epilogue Technology
  1091.          K. Ramesh Babu, Excelan
  1092.          Lawrence Besaw, Hewlett-Packard
  1093.          Jeffrey D. Case, University of Tennessee at Knoxville
  1094.          James R. Davin, Proteon
  1095.          Mark S. Fedor, NYSERNet
  1096.          Robb Foster, BBN
  1097.          Phill Gross, The MITRE Corporation
  1098.          Bent Torp Jensen, Convergent Technology
  1099.          Lee Labarre, The MITRE Corporation
  1100.          Dan Lynch, Advanced Computing Environments
  1101.          Keith McCloghrie, The Wollongong Group
  1102.          Dave Mackie, 3Com/Bridge
  1103.          Craig Partridge, BBN (chair)
  1104.          Jim Robertson, 3Com/Bridge
  1105.          Marshall T. Rose, The Wollongong Group
  1106.          Greg Satz, cisco
  1107.          Martin Lee Schoffstall, Rensselaer Polytechnic Institute
  1108.          Lou Steinberg, IBM
  1109.          Dean Throop, Data General
  1110.          Unni Warrier, Unisys
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Rose & McCloghrie                                              [Page 20]
  1123.  
  1124. RFC 1065                          SMI                        August 1988
  1125.  
  1126.  
  1127. 8.  References
  1128.  
  1129.    [1] Information processing systems - Open Systems Interconnection,
  1130.        "Specification of Abstract Syntax Notation One (ASN.1)",
  1131.        International Organization for Standardization, International
  1132.        Standard 8824, December 1987.
  1133.  
  1134.    [2] McCloghrie K., and M. Rose, "Management Information Base for
  1135.        Network Management of TCP/IP-based internets", RFC 1066, TWG,
  1136.        August 1988.
  1137.  
  1138.    [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
  1139.        Network Management Protocol", RFC 1067, University of Tennessee
  1140.        at Knoxville, NYSERNet, Rensselaer Polytechnic, Proteon, August
  1141.        1988.
  1142.  
  1143.    [4] LaBarre, L., "Structure and Identification of Management
  1144.        Information for the Internet", Internet Engineering Task Force
  1145.        working note, Network Information Center, SRI International,
  1146.        Menlo Park, California, April 1988.
  1147.  
  1148.    [5] Cerf, V., "IAB Recommendations for the Development of Internet
  1149.        Network Management Standards", RFC 1052, IAB, April 1988.
  1150.  
  1151.    [6] Information processing systems - Open Systems Interconnection,
  1152.        "Specification of Basic Encoding Rules for Abstract Notation One
  1153.        (ASN.1)", International Organization for Standardization,
  1154.        International Standard 8825, December 1987.
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Rose & McCloghrie                                              [Page 21]
  1179.