]>
Commit | Line | Data |
---|---|---|
89d46774 | 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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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: mrose@PSI.COM | |
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: sytek!kzm@HPLABS.HP.COM | |
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 | \f |