![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1155.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs|
Return to rfc1155.txt CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs |
1.1 root 1:
2:
3:
4:
5:
6:
7: Network Working Group M. Rose
8: Request for Comments: 1155 Performance Systems International
9: Obsoletes: RFC 1065 K. McCloghrie
10: Hughes LAN Systems
11: May 1990
12:
13:
14:
15: Structure and Identification of Management Information
16: for TCP/IP-based Internets
17:
18: Table of Contents
19:
20: 1. Status of this Memo ............................................. 1
21: 2. Introduction .................................................... 2
22: 3. Structure and Identification of Management Information........... 4
23: 3.1 Names .......................................................... 4
24: 3.1.1 Directory .................................................... 5
25: 3.1.2 Mgmt ......................................................... 6
26: 3.1.3 Experimental ................................................. 6
27: 3.1.4 Private ...................................................... 7
28: 3.2 Syntax ......................................................... 7
29: 3.2.1 Primitive Types .............................................. 7
30: 3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7
31: 3.2.2 Constructor Types ............................................ 8
32: 3.2.3 Defined Types ................................................ 8
33: 3.2.3.1 NetworkAddress ............................................. 8
34: 3.2.3.2 IpAddress .................................................. 8
35: 3.2.3.3 Counter .................................................... 8
36: 3.2.3.4 Gauge ...................................................... 9
37: 3.2.3.5 TimeTicks .................................................. 9
38: 3.2.3.6 Opaque ..................................................... 9
39: 3.3 Encodings ...................................................... 9
40: 4. Managed Objects ................................................. 10
41: 4.1 Guidelines for Object Names .................................... 10
42: 4.2 Object Types and Instances ..................................... 10
43: 4.3 Macros for Managed Objects ..................................... 14
44: 5. Extensions to the MIB ........................................... 16
45: 6. Definitions ..................................................... 17
46: 7. Acknowledgements ................................................ 20
47: 8. References ...................................................... 21
48: 9. Security Considerations.......................................... 21
49: 10. Authors' Addresses.............................................. 22
50:
51: 1. Status of this Memo
52:
53: This RFC is a re-release of RFC 1065, with a changed "Status of this
54: Memo", plus a few minor typographical corrections. The technical
55:
56:
57:
58: Rose & McCloghrie [Page 1]
59:
60: RFC 1155 SMI May 1990
61:
62:
63: content of the document is unchanged from RFC 1065.
64:
65: This memo provides the common definitions for the structure and
66: identification of management information for TCP/IP-based internets.
67: In particular, together with its companion memos which describe the
68: management information base along with the network management
69: protocol, these documents provide a simple, workable architecture and
70: system for managing TCP/IP-based internets and in particular, the
71: Internet.
72:
73: This memo specifies a Standard Protocol for the Internet community.
74: Its status is "Recommended". TCP/IP implementations in the Internet
75: which are network manageable are expected to adopt and implement this
76: specification.
77:
78: The Internet Activities Board recommends that all IP and TCP
79: implementations be network manageable. This implies implementation
80: of the Internet MIB (RFC-1156) and at least one of the two
81: recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
82: It should be noted that, at this time, SNMP is a full Internet
83: standard and CMOT is a draft standard. See also the Host and Gateway
84: Requirements RFCs for more specific information on the applicability
85: of this standard.
86:
87: Please refer to the latest edition of the "IAB Official Protocol
88: Standards" RFC for current information on the state and status of
89: standard Internet protocols.
90:
91: Distribution of this memo is unlimited.
92:
93: 2. Introduction
94:
95: This memo describes the common structures and identification scheme
96: for the definition of management information used in managing
97: TCP/IP-based internets. Included are descriptions of an object
98: information model for network management along with a set of generic
99: types used to describe management information. Formal descriptions
100: of the structure are given using Abstract Syntax Notation One (ASN.1)
101: [1].
102:
103: This memo is largely concerned with organizational concerns and
104: administrative policy: it neither specifies the objects which are
105: managed, nor the protocols used to manage those objects. These
106: concerns are addressed by two companion memos: one describing the
107: Management Information Base (MIB) [2], and the other describing the
108: Simple Network Management Protocol (SNMP) [3].
109:
110: This memo is based in part on the work of the Internet Engineering
111:
112:
113:
114: Rose & McCloghrie [Page 2]
115:
116: RFC 1155 SMI May 1990
117:
118:
119: Task Force, particularly the working note titled "Structure and
120: Identification of Management Information for the Internet" [4]. This
121: memo uses a skeletal structure derived from that note, but differs in
122: one very significant way: that note focuses entirely on the use of
123: OSI-style network management. As such, it is not suitable for use
124: with SNMP.
125:
126: This memo attempts to achieve two goals: simplicity and
127: extensibility. Both are motivated by a common concern: although the
128: management of TCP/IP-based internets has been a topic of study for
129: some time, the authors do not feel that the depth and breadth of such
130: understanding is complete. More bluntly, we feel that previous
131: experiences, while giving the community insight, are hardly
132: conclusive. By fostering a simple SMI, the minimal number of
133: constraints are imposed on future potential approaches; further, by
134: fostering an extensible SMI, the maximal number of potential
135: approaches are available for experimentation.
136:
137: It is believed that this memo and its two companions comply with the
138: guidelines set forth in RFC 1052, "IAB Recommendations for the
139: Development of Internet Network Management Standards" [5] and RFC
140: 1109, "Report of the Second Ad Hoc Network Management Review Group"
141: [6]. In particular, we feel that this memo, along with the memo
142: describing the management information base, provide a solid basis for
143: network management of the Internet.
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 1155 SMI May 1990
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 [7].
200:
201: It is beyond the scope of this memo to define either the MIB used for
202: network management or the network management protocol. As mentioned
203: earlier, these tasks are left to companion memos. This memo attempts
204: to minimize the restrictions placed upon its companions so as to
205: maximize generality. However, in some cases, restrictions have been
206: made (e.g., the syntax which may be used when defining object types
207: in the MIB) in order to encourage a particular style of management.
208: Future editions of this memo may remove these restrictions.
209:
210: 3.1. Names
211:
212: Names are used to identify managed objects. This memo specifies
213: names which are hierarchical in nature. The OBJECT IDENTIFIER
214: concept is used to model this notion. An OBJECT IDENTIFIER can be
215: used for purposes other than naming managed object types; for
216: example, each international standard has an OBJECT IDENTIFIER
217: assigned to it for the purposes of identification. In short, OBJECT
218: IDENTIFIERs are a means for identifying some object, regardless of
219: the semantics associated with the object (e.g., a network object, a
220: standards document, etc.)
221:
222: An OBJECT IDENTIFIER is a sequence of integers which traverse a
223:
224:
225:
226: Rose & McCloghrie [Page 4]
227:
228: RFC 1155 SMI May 1990
229:
230:
231: global tree. The tree consists of a root connected to a number of
232: labeled nodes via edges. Each node may, in turn, have children of
233: its own which are labeled. In this case, we may term the node a
234: subtree. This process may continue to an arbitrary level of depth.
235: Central to the notion of the OBJECT IDENTIFIER is the understanding
236: that administrative control of the meanings assigned to the nodes may
237: be delegated as one traverses the tree. A label is a pairing of a
238: brief textual description and an integer.
239:
240: The root node itself is unlabeled, but has at least three children
241: directly under it: one node is administered by the International
242: Organization for Standardization, with label iso(1); another is
243: administrated by the International Telegraph and Telephone
244: Consultative Committee, with label ccitt(0); and the third is jointly
245: administered by the ISO and the CCITT, joint-iso-ccitt(2).
246:
247: Under the iso(1) node, the ISO has designated one subtree for use by
248: other (inter)national organizations, org(3). Of the children nodes
249: present, two have been assigned to the U.S. National Institutes of
250: Standards and Technology. One of these subtrees has been transferred
251: by the NIST to the U.S. Department of Defense, dod(6).
252:
253: As of this writing, the DoD has not indicated how it will manage its
254: subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will
255: allocate a node to the Internet community, to be administered by the
256: Internet Activities Board (IAB) as follows:
257:
258: internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
259:
260: That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
261: prefix:
262:
263: 1.3.6.1.
264:
265: This memo, as a standard approved by the IAB, now specifies the
266: policy under which this subtree of OBJECT IDENTIFIERs is
267: administered. Initially, four nodes are present:
268:
269: directory OBJECT IDENTIFIER ::= { internet 1 }
270: mgmt OBJECT IDENTIFIER ::= { internet 2 }
271: experimental OBJECT IDENTIFIER ::= { internet 3 }
272: private OBJECT IDENTIFIER ::= { internet 4 }
273:
274: 3.1.1. Directory
275:
276: The directory(1) subtree is reserved for use with a future memo that
277: discusses how the OSI Directory may be used in the Internet.
278:
279:
280:
281:
282: Rose & McCloghrie [Page 5]
283:
284: RFC 1155 SMI May 1990
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 Internet Assigned Numbers Authority for
292: the Internet. As RFCs which define new versions of the Internet-
293: standard Management Information Base are approved, they are assigned
294: an OBJECT IDENTIFIER by the Internet Assigned Numbers Authority for
295: identifying the 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 Internet Assigned Numbers Authority of
318: the 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 Internet Assigned Numbers
332: Authority may make requirements as to how that subtree is used.
333:
334:
335:
336:
337:
338: Rose & McCloghrie [Page 6]
339:
340: RFC 1155 SMI May 1990
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 Internet Assigned Numbers Authority for the
348: Internet. 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: Internet 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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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 1155 SMI May 1990
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
886: expected object type, then those control actions must fail. In both
887: the monitoring and control cases, the name of an object returned by
888: an 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 1155 SMI May 1990
901:
902:
903: 6. Definitions
904:
905: RFC1155-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 1155 SMI May 1990
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 1155 SMI May 1990
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 (0..4294967295)
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 1155 SMI May 1990
1069:
1070:
1071: 7. Acknowledgements
1072:
1073: This memo was influenced by three sets of contributors to earlier
1074: drafts:
1075:
1076: First, Lee Labarre of the MITRE Corporation, who as author of the
1077: NETMAN SMI [4], presented the basic roadmap for the SMI.
1078:
1079: Second, several individuals who provided valuable comments on this
1080: memo prior to its initial distribution:
1081:
1082: James R. Davin, Proteon
1083: Mark S. Fedor, NYSERNet
1084: Craig Partridge, BBN Laboratories
1085: Martin Lee Schoffstall, Rensselaer Polytechnic Institute
1086: Wengyik Yeong, NYSERNet
1087:
1088:
1089: Third, the IETF MIB working group:
1090:
1091: Karl Auerbach, Epilogue Technology
1092: K. Ramesh Babu, Excelan
1093: Lawrence Besaw, Hewlett-Packard
1094: Jeffrey D. Case, University of Tennessee at Knoxville
1095: James R. Davin, Proteon
1096: Mark S. Fedor, NYSERNet
1097: Robb Foster, BBN
1098: Phill Gross, The MITRE Corporation
1099: Bent Torp Jensen, Convergent Technology
1100: Lee Labarre, The MITRE Corporation
1101: Dan Lynch, Advanced Computing Environments
1102: Keith McCloghrie, The Wollongong Group
1103: Dave Mackie, 3Com/Bridge
1104: Craig Partridge, BBN (chair)
1105: Jim Robertson, 3Com/Bridge
1106: Marshall T. Rose, The Wollongong Group
1107: Greg Satz, cisco
1108: Martin Lee Schoffstall, Rensselaer Polytechnic Institute
1109: Lou Steinberg, IBM
1110: Dean Throop, Data General
1111: Unni Warrier, Unisys
1112:
1113:
1114:
1115:
1116:
1117:
1118:
1119:
1120:
1121:
1122: Rose & McCloghrie [Page 20]
1123:
1124: RFC 1155 SMI May 1990
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 1156,
1136: Performance Systems International and Hughes LAN Systems, May
1137: 1990.
1138:
1139: [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
1140: Network Management Protocol", RFC 1157, University of Tennessee
1141: at Knoxville, Performance Systems International, Performance
1142: Systems International, and the MIT Laboratory for Computer
1143: Science, May 1990.
1144:
1145: [4] LaBarre, L., "Structure and Identification of Management
1146: Information for the Internet", Internet Engineering Task Force
1147: working note, Network Information Center, SRI International,
1148: Menlo Park, California, April 1988.
1149:
1150: [5] Cerf, V., "IAB Recommendations for the Development of Internet
1151: Network Management Standards", RFC 1052, IAB, April 1988.
1152:
1153: [6] Cerf, V., "Report of the Second Ad Hoc Network Management Review
1154: Group", RFC 1109, IAB, August 1989.
1155:
1156: [7] Information processing systems - Open Systems Interconnection,
1157: "Specification of Basic Encoding Rules for Abstract Notation One
1158: (ASN.1)", International Organization for Standardization,
1159: International Standard 8825, December 1987.
1160:
1161: Security Considerations
1162:
1163: Security issues are not discussed in this memo.
1164:
1165:
1166:
1167:
1168:
1169:
1170:
1171:
1172:
1173:
1174:
1175:
1176:
1177:
1178: Rose & McCloghrie [Page 21]
1179:
1180: RFC 1155 SMI May 1990
1181:
1182:
1183: Authors' Addresses
1184:
1185: Marshall T. Rose
1186: PSI, Inc.
1187: PSI California Office
1188: P.O. Box 391776
1189: Mountain View, CA 94039
1190:
1191: Phone: (415) 961-3380
1192:
1193: EMail: [email protected]
1194:
1195:
1196: Keith McCloghrie
1197: The Wollongong Group
1198: 1129 San Antonio Road
1199: Palo Alto, CA 04303
1200:
1201: Phone: (415) 962-7160
1202:
1203: EMail: [email protected]
1204:
1205:
1206:
1207:
1208:
1209:
1210:
1211:
1212:
1213:
1214:
1215:
1216:
1217:
1218:
1219:
1220:
1221:
1222:
1223:
1224:
1225:
1226:
1227:
1228:
1229:
1230:
1231:
1232:
1233:
1234: Rose & McCloghrie [Page 22]
1235:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.