Node-Red configuration
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

rfc1155.txt 39KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235
  1. Network Working Group M. Rose
  2. Request for Comments: 1155 Performance Systems International
  3. Obsoletes: RFC 1065 K. McCloghrie
  4. Hughes LAN Systems
  5. May 1990
  6. Structure and Identification of Management Information
  7. for TCP/IP-based Internets
  8. Table of Contents
  9. 1. Status of this Memo ............................................. 1
  10. 2. Introduction .................................................... 2
  11. 3. Structure and Identification of Management Information........... 4
  12. 3.1 Names .......................................................... 4
  13. 3.1.1 Directory .................................................... 5
  14. 3.1.2 Mgmt ......................................................... 6
  15. 3.1.3 Experimental ................................................. 6
  16. 3.1.4 Private ...................................................... 7
  17. 3.2 Syntax ......................................................... 7
  18. 3.2.1 Primitive Types .............................................. 7
  19. 3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7
  20. 3.2.2 Constructor Types ............................................ 8
  21. 3.2.3 Defined Types ................................................ 8
  22. 3.2.3.1 NetworkAddress ............................................. 8
  23. 3.2.3.2 IpAddress .................................................. 8
  24. 3.2.3.3 Counter .................................................... 8
  25. 3.2.3.4 Gauge ...................................................... 9
  26. 3.2.3.5 TimeTicks .................................................. 9
  27. 3.2.3.6 Opaque ..................................................... 9
  28. 3.3 Encodings ...................................................... 9
  29. 4. Managed Objects ................................................. 10
  30. 4.1 Guidelines for Object Names .................................... 10
  31. 4.2 Object Types and Instances ..................................... 10
  32. 4.3 Macros for Managed Objects ..................................... 14
  33. 5. Extensions to the MIB ........................................... 16
  34. 6. Definitions ..................................................... 17
  35. 7. Acknowledgements ................................................ 20
  36. 8. References ...................................................... 21
  37. 9. Security Considerations.......................................... 21
  38. 10. Authors' Addresses.............................................. 22
  39. 1. Status of this Memo
  40. This RFC is a re-release of RFC 1065, with a changed "Status of this
  41. Memo", plus a few minor typographical corrections. The technical
  42. Rose & McCloghrie [Page 1]
  43. RFC 1155 SMI May 1990
  44. content of the document is unchanged from RFC 1065.
  45. This memo provides the common definitions for the structure and
  46. identification of management information for TCP/IP-based internets.
  47. In particular, together with its companion memos which describe the
  48. management information base along with the network management
  49. protocol, these documents provide a simple, workable architecture and
  50. system for managing TCP/IP-based internets and in particular, the
  51. Internet.
  52. This memo specifies a Standard Protocol for the Internet community.
  53. Its status is "Recommended". TCP/IP implementations in the Internet
  54. which are network manageable are expected to adopt and implement this
  55. specification.
  56. The Internet Activities Board recommends that all IP and TCP
  57. implementations be network manageable. This implies implementation
  58. of the Internet MIB (RFC-1156) and at least one of the two
  59. recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
  60. It should be noted that, at this time, SNMP is a full Internet
  61. standard and CMOT is a draft standard. See also the Host and Gateway
  62. Requirements RFCs for more specific information on the applicability
  63. of this standard.
  64. Please refer to the latest edition of the "IAB Official Protocol
  65. Standards" RFC for current information on the state and status of
  66. standard Internet protocols.
  67. Distribution of this memo is unlimited.
  68. 2. Introduction
  69. This memo describes the common structures and identification scheme
  70. for the definition of management information used in managing
  71. TCP/IP-based internets. Included are descriptions of an object
  72. information model for network management along with a set of generic
  73. types used to describe management information. Formal descriptions
  74. of the structure are given using Abstract Syntax Notation One (ASN.1)
  75. [1].
  76. This memo is largely concerned with organizational concerns and
  77. administrative policy: it neither specifies the objects which are
  78. managed, nor the protocols used to manage those objects. These
  79. concerns are addressed by two companion memos: one describing the
  80. Management Information Base (MIB) [2], and the other describing the
  81. Simple Network Management Protocol (SNMP) [3].
  82. This memo is based in part on the work of the Internet Engineering
  83. Rose & McCloghrie [Page 2]
  84. RFC 1155 SMI May 1990
  85. Task Force, particularly the working note titled "Structure and
  86. Identification of Management Information for the Internet" [4]. This
  87. memo uses a skeletal structure derived from that note, but differs in
  88. one very significant way: that note focuses entirely on the use of
  89. OSI-style network management. As such, it is not suitable for use
  90. with SNMP.
  91. This memo attempts to achieve two goals: simplicity and
  92. extensibility. Both are motivated by a common concern: although the
  93. management of TCP/IP-based internets has been a topic of study for
  94. some time, the authors do not feel that the depth and breadth of such
  95. understanding is complete. More bluntly, we feel that previous
  96. experiences, while giving the community insight, are hardly
  97. conclusive. By fostering a simple SMI, the minimal number of
  98. constraints are imposed on future potential approaches; further, by
  99. fostering an extensible SMI, the maximal number of potential
  100. approaches are available for experimentation.
  101. It is believed that this memo and its two companions comply with the
  102. guidelines set forth in RFC 1052, "IAB Recommendations for the
  103. Development of Internet Network Management Standards" [5] and RFC
  104. 1109, "Report of the Second Ad Hoc Network Management Review Group"
  105. [6]. In particular, we feel that this memo, along with the memo
  106. describing the management information base, provide a solid basis for
  107. network management of the Internet.
  108. Rose & McCloghrie [Page 3]
  109. RFC 1155 SMI May 1990
  110. 3. Structure and Identification of Management Information
  111. Managed objects are accessed via a virtual information store, termed
  112. the Management Information Base or MIB. Objects in the MIB are
  113. defined using Abstract Syntax Notation One (ASN.1) [1].
  114. Each type of object (termed an object type) has a name, a syntax, and
  115. an encoding. The name is represented uniquely as an OBJECT
  116. IDENTIFIER. An OBJECT IDENTIFIER is an administratively assigned
  117. name. The administrative policies used for assigning names are
  118. discussed later in this memo.
  119. The syntax for an object type defines the abstract data structure
  120. corresponding to that object type. For example, the structure of a
  121. given object type might be an INTEGER or OCTET STRING. Although in
  122. general, we should permit any ASN.1 construct to be available for use
  123. in defining the syntax of an object type, this memo purposely
  124. restricts the ASN.1 constructs which may be used. These restrictions
  125. are made solely for the sake of simplicity.
  126. The encoding of an object type is simply how instances of that object
  127. type are represented using the object's type syntax. Implicitly tied
  128. to the notion of an object's syntax and encoding is how the object is
  129. represented when being transmitted on the network. This memo
  130. specifies the use of the basic encoding rules of ASN.1 [7].
  131. It is beyond the scope of this memo to define either the MIB used for
  132. network management or the network management protocol. As mentioned
  133. earlier, these tasks are left to companion memos. This memo attempts
  134. to minimize the restrictions placed upon its companions so as to
  135. maximize generality. However, in some cases, restrictions have been
  136. made (e.g., the syntax which may be used when defining object types
  137. in the MIB) in order to encourage a particular style of management.
  138. Future editions of this memo may remove these restrictions.
  139. 3.1. Names
  140. Names are used to identify managed objects. This memo specifies
  141. names which are hierarchical in nature. The OBJECT IDENTIFIER
  142. concept is used to model this notion. An OBJECT IDENTIFIER can be
  143. used for purposes other than naming managed object types; for
  144. example, each international standard has an OBJECT IDENTIFIER
  145. assigned to it for the purposes of identification. In short, OBJECT
  146. IDENTIFIERs are a means for identifying some object, regardless of
  147. the semantics associated with the object (e.g., a network object, a
  148. standards document, etc.)
  149. An OBJECT IDENTIFIER is a sequence of integers which traverse a
  150. Rose & McCloghrie [Page 4]
  151. RFC 1155 SMI May 1990
  152. global tree. The tree consists of a root connected to a number of
  153. labeled nodes via edges. Each node may, in turn, have children of
  154. its own which are labeled. In this case, we may term the node a
  155. subtree. This process may continue to an arbitrary level of depth.
  156. Central to the notion of the OBJECT IDENTIFIER is the understanding
  157. that administrative control of the meanings assigned to the nodes may
  158. be delegated as one traverses the tree. A label is a pairing of a
  159. brief textual description and an integer.
  160. The root node itself is unlabeled, but has at least three children
  161. directly under it: one node is administered by the International
  162. Organization for Standardization, with label iso(1); another is
  163. administrated by the International Telegraph and Telephone
  164. Consultative Committee, with label ccitt(0); and the third is jointly
  165. administered by the ISO and the CCITT, joint-iso-ccitt(2).
  166. Under the iso(1) node, the ISO has designated one subtree for use by
  167. other (inter)national organizations, org(3). Of the children nodes
  168. present, two have been assigned to the U.S. National Institutes of
  169. Standards and Technology. One of these subtrees has been transferred
  170. by the NIST to the U.S. Department of Defense, dod(6).
  171. As of this writing, the DoD has not indicated how it will manage its
  172. subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will
  173. allocate a node to the Internet community, to be administered by the
  174. Internet Activities Board (IAB) as follows:
  175. internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
  176. That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
  177. prefix:
  178. 1.3.6.1.
  179. This memo, as a standard approved by the IAB, now specifies the
  180. policy under which this subtree of OBJECT IDENTIFIERs is
  181. administered. Initially, four nodes are present:
  182. directory OBJECT IDENTIFIER ::= { internet 1 }
  183. mgmt OBJECT IDENTIFIER ::= { internet 2 }
  184. experimental OBJECT IDENTIFIER ::= { internet 3 }
  185. private OBJECT IDENTIFIER ::= { internet 4 }
  186. 3.1.1. Directory
  187. The directory(1) subtree is reserved for use with a future memo that
  188. discusses how the OSI Directory may be used in the Internet.
  189. Rose & McCloghrie [Page 5]
  190. RFC 1155 SMI May 1990
  191. 3.1.2. Mgmt
  192. The mgmt(2) subtree is used to identify objects which are defined in
  193. IAB-approved documents. Administration of the mgmt(2) subtree is
  194. delegated by the IAB to the Internet Assigned Numbers Authority for
  195. the Internet. As RFCs which define new versions of the Internet-
  196. standard Management Information Base are approved, they are assigned
  197. an OBJECT IDENTIFIER by the Internet Assigned Numbers Authority for
  198. identifying the objects defined by that memo.
  199. For example, the RFC which defines the initial Internet standard MIB
  200. would be assigned management document number 1. This RFC would use
  201. the OBJECT IDENTIFIER
  202. { mgmt 1 }
  203. or
  204. 1.3.6.1.2.1
  205. in defining the Internet-standard MIB.
  206. The generation of new versions of the Internet-standard MIB is a
  207. rigorous process. Section 5 of this memo describes the rules used
  208. when a new version is defined.
  209. 3.1.3. Experimental
  210. The experimental(3) subtree is used to identify objects used in
  211. Internet experiments. Administration of the experimental(3) subtree
  212. is delegated by the IAB to the Internet Assigned Numbers Authority of
  213. the Internet.
  214. For example, an experimenter might received number 17, and would have
  215. available the OBJECT IDENTIFIER
  216. { experimental 17 }
  217. or
  218. 1.3.6.1.3.17
  219. for use.
  220. As a part of the assignment process, the Internet Assigned Numbers
  221. Authority may make requirements as to how that subtree is used.
  222. Rose & McCloghrie [Page 6]
  223. RFC 1155 SMI May 1990
  224. 3.1.4. Private
  225. The private(4) subtree is used to identify objects defined
  226. unilaterally. Administration of the private(4) subtree is delegated
  227. by the IAB to the Internet Assigned Numbers Authority for the
  228. Internet. Initially, this subtree has at least one child:
  229. enterprises OBJECT IDENTIFIER ::= { private 1 }
  230. The enterprises(1) subtree is used, among other things, to permit
  231. parties providing networking subsystems to register models of their
  232. products.
  233. Upon receiving a subtree, the enterprise may, for example, define new
  234. MIB objects in this subtree. In addition, it is strongly recommended
  235. that the enterprise will also register its networking subsystems
  236. under this subtree, in order to provide an unambiguous identification
  237. mechanism for use in management protocols. For example, if the
  238. "Flintstones, Inc." enterprise produced networking subsystems, then
  239. they could request a node under the enterprises subtree from the
  240. Internet Assigned Numbers Authority. Such a node might be numbered:
  241. 1.3.6.1.4.1.42
  242. The "Flintstones, Inc." enterprise might then register their "Fred
  243. Router" under the name of:
  244. 1.3.6.1.4.1.42.1.1
  245. 3.2. Syntax
  246. Syntax is used to define the structure corresponding to object types.
  247. ASN.1 constructs are used to define this structure, although the full
  248. generality of ASN.1 is not permitted.
  249. The ASN.1 type ObjectSyntax defines the different syntaxes which may
  250. be used in defining an object type.
  251. 3.2.1. Primitive Types
  252. Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT
  253. IDENTIFIER, and NULL are permitted. These are sometimes referred to
  254. as non-aggregate types.
  255. 3.2.1.1. Guidelines for Enumerated INTEGERs
  256. If an enumerated INTEGER is listed as an object type, then a named-
  257. number having the value 0 shall not be present in the list of
  258. Rose & McCloghrie [Page 7]
  259. RFC 1155 SMI May 1990
  260. enumerations. Use of this value is prohibited.
  261. 3.2.2. Constructor Types
  262. The ASN.1 constructor type SEQUENCE is permitted, providing that it
  263. is used to generate either lists or tables.
  264. For lists, the syntax takes the form:
  265. SEQUENCE { <type1>, ..., <typeN> }
  266. where each <type> resolves to one of the ASN.1 primitive types listed
  267. above. Further, these ASN.1 types are always present (the DEFAULT
  268. and OPTIONAL clauses do not appear in the SEQUENCE definition).
  269. For tables, the syntax takes the form:
  270. SEQUENCE OF <entry>
  271. where <entry> resolves to a list constructor.
  272. Lists and tables are sometimes referred to as aggregate types.
  273. 3.2.3. Defined Types
  274. In addition, new application-wide types may be defined, so long as
  275. they resolve into an IMPLICITly defined ASN.1 primitive type, list,
  276. table, or some other application-wide type. Initially, few
  277. application-wide types are defined. Future memos will no doubt
  278. define others once a consensus is reached.
  279. 3.2.3.1. NetworkAddress
  280. This CHOICE represents an address from one of possibly several
  281. protocol families. Currently, only one protocol family, the Internet
  282. family, is present in this CHOICE.
  283. 3.2.3.2. IpAddress
  284. This application-wide type represents a 32-bit internet address. It
  285. is represented as an OCTET STRING of length 4, in network byte-order.
  286. When this ASN.1 type is encoded using the ASN.1 basic encoding rules,
  287. only the primitive encoding form shall be used.
  288. 3.2.3.3. Counter
  289. This application-wide type represents a non-negative integer which
  290. Rose & McCloghrie [Page 8]
  291. RFC 1155 SMI May 1990
  292. monotonically increases until it reaches a maximum value, when it
  293. wraps around and starts increasing again from zero. This memo
  294. specifies a maximum value of 2^32-1 (4294967295 decimal) for
  295. counters.
  296. 3.2.3.4. Gauge
  297. This application-wide type represents a non-negative integer, which
  298. may increase or decrease, but which latches at a maximum value. This
  299. memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
  300. gauges.
  301. 3.2.3.5. TimeTicks
  302. This application-wide type represents a non-negative integer which
  303. counts the time in hundredths of a second since some epoch. When
  304. object types are defined in the MIB which use this ASN.1 type, the
  305. description of the object type identifies the reference epoch.
  306. 3.2.3.6. Opaque
  307. This application-wide type supports the capability to pass arbitrary
  308. ASN.1 syntax. A value is encoded using the ASN.1 basic rules into a
  309. string of octets. This, in turn, is encoded as an OCTET STRING, in
  310. effect "double-wrapping" the original ASN.1 value.
  311. Note that a conforming implementation need only be able to accept and
  312. recognize opaquely-encoded data. It need not be able to unwrap the
  313. data and then interpret its contents.
  314. Further note that by use of the ASN.1 EXTERNAL type, encodings other
  315. than ASN.1 may be used in opaquely-encoded data.
  316. 3.3. Encodings
  317. Once an instance of an object type has been identified, its value may
  318. be transmitted by applying the basic encoding rules of ASN.1 to the
  319. syntax for the object type.
  320. Rose & McCloghrie [Page 9]
  321. RFC 1155 SMI May 1990
  322. 4. Managed Objects
  323. Although it is not the purpose of this memo to define objects in the
  324. MIB, this memo specifies a format to be used by other memos which
  325. define these objects.
  326. An object type definition consists of five fields:
  327. OBJECT:
  328. -------
  329. A textual name, termed the OBJECT DESCRIPTOR, for the object type,
  330. along with its corresponding OBJECT IDENTIFIER.
  331. Syntax:
  332. The abstract syntax for the object type. This must resolve to an
  333. instance of the ASN.1 type ObjectSyntax (defined below).
  334. Definition:
  335. A textual description of the semantics of the object type.
  336. Implementations should ensure that their instance of the object
  337. fulfills this definition since this MIB is intended for use in
  338. multi-vendor environments. As such it is vital that objects have
  339. consistent meaning across all machines.
  340. Access:
  341. One of read-only, read-write, write-only, or not-accessible.
  342. Status:
  343. One of mandatory, optional, or obsolete.
  344. Future memos may also specify other fields for the objects which they
  345. define.
  346. 4.1. Guidelines for Object Names
  347. No object type in the Internet-Standard MIB shall use a sub-
  348. identifier of 0 in its name. This value is reserved for use with
  349. future extensions.
  350. Each OBJECT DESCRIPTOR corresponding to an object type in the
  351. internet-standard MIB shall be a unique, but mnemonic, printable
  352. string. This promotes a common language for humans to use when
  353. discussing the MIB and also facilitates simple table mappings for
  354. user interfaces.
  355. 4.2. Object Types and Instances
  356. An object type is a definition of a kind of managed object; it is
  357. Rose & McCloghrie [Page 10]
  358. RFC 1155 SMI May 1990
  359. declarative in nature. In contrast, an object instance is an
  360. instantiation of an object type which has been bound to a value. For
  361. example, the notion of an entry in a routing table might be defined
  362. in the MIB. Such a notion corresponds to an object type; individual
  363. entries in a particular routing table which exist at some time are
  364. object instances of that object type.
  365. A collection of object types is defined in the MIB. Each such
  366. subject type is uniquely named by its OBJECT IDENTIFIER and also has
  367. a textual name, which is its OBJECT DESCRIPTOR. The means whereby
  368. object instances are referenced is not defined in the MIB. Reference
  369. to object instances is achieved by a protocol-specific mechanism: it
  370. is the responsibility of each management protocol adhering to the SMI
  371. to define this mechanism.
  372. An object type may be defined in the MIB such that an instance of
  373. that object type represents an aggregation of information also
  374. represented by instances of some number of "subordinate" object
  375. types. For example, suppose the following object types are defined
  376. in the MIB:
  377. OBJECT:
  378. -------
  379. atIndex { atEntry 1 }
  380. Syntax:
  381. INTEGER
  382. Definition:
  383. The interface number for the physical address.
  384. Access:
  385. read-write.
  386. Status:
  387. mandatory.
  388. OBJECT:
  389. -------
  390. atPhysAddress { atEntry 2 }
  391. Syntax:
  392. OCTET STRING
  393. Definition:
  394. The media-dependent physical address.
  395. Rose & McCloghrie [Page 11]
  396. RFC 1155 SMI May 1990
  397. Access:
  398. read-write.
  399. Status:
  400. mandatory.
  401. OBJECT:
  402. -------
  403. atNetAddress { atEntry 3 }
  404. Syntax:
  405. NetworkAddress
  406. Definition:
  407. The network address corresponding to the media-dependent physical
  408. address.
  409. Access:
  410. read-write.
  411. Status:
  412. mandatory.
  413. Then, a fourth object type might also be defined in the MIB:
  414. OBJECT:
  415. -------
  416. atEntry { atTable 1 }
  417. Syntax:
  418. AtEntry ::= SEQUENCE {
  419. atIndex
  420. INTEGER,
  421. atPhysAddress
  422. OCTET STRING,
  423. atNetAddress
  424. NetworkAddress
  425. }
  426. Definition:
  427. An entry in the address translation table.
  428. Access:
  429. read-write.
  430. Rose & McCloghrie [Page 12]
  431. RFC 1155 SMI May 1990
  432. Status:
  433. mandatory.
  434. Each instance of this object type comprises information represented
  435. by instances of the former three object types. An object type
  436. defined in this way is called a list.
  437. Similarly, tables can be formed by aggregations of a list type. For
  438. example, a fifth object type might also be defined in the MIB:
  439. OBJECT:
  440. ------
  441. atTable { at 1 }
  442. Syntax:
  443. SEQUENCE OF AtEntry
  444. Definition:
  445. The address translation table.
  446. Access:
  447. read-write.
  448. Status:
  449. mandatory.
  450. such that each instance of the atTable object comprises information
  451. represented by the set of atEntry object types that collectively
  452. constitute a given atTable object instance, that is, a given address
  453. translation table.
  454. Consider how one might refer to a simple object within a table.
  455. Continuing with the previous example, one might name the object type
  456. { atPhysAddress }
  457. and specify, using a protocol-specific mechanism, the object instance
  458. { atNetAddress } = { internet "10.0.0.52" }
  459. This pairing of object type and object instance would refer to all
  460. instances of atPhysAddress which are part of any entry in some
  461. address translation table for which the associated atNetAddress value
  462. is { internet "10.0.0.52" }.
  463. To continue with this example, consider how one might refer to an
  464. aggregate object (list) within a table. Naming the object type
  465. Rose & McCloghrie [Page 13]
  466. RFC 1155 SMI May 1990
  467. { atEntry }
  468. and specifying, using a protocol-specific mechanism, the object
  469. instance
  470. { atNetAddress } = { internet "10.0.0.52" }
  471. refers to all instances of entries in the table for which the
  472. associated atNetAddress value is { internet "10.0.0.52" }.
  473. Each management protocol must provide a mechanism for accessing
  474. simple (non-aggregate) object types. Each management protocol
  475. specifies whether or not it supports access to aggregate object
  476. types. Further, the protocol must specify which instances are
  477. "returned" when an object type/instance pairing refers to more than
  478. one instance of a type.
  479. To afford support for a variety of management protocols, all
  480. information by which instances of a given object type may be usefully
  481. distinguished, one from another, is represented by instances of
  482. object types defined in the MIB.
  483. 4.3. Macros for Managed Objects
  484. In order to facilitate the use of tools for processing the definition
  485. of the MIB, the OBJECT-TYPE macro may be used. This macro permits
  486. the key aspects of an object type to be represented in a formal way.
  487. OBJECT-TYPE MACRO ::=
  488. BEGIN
  489. TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
  490. "ACCESS" Access
  491. "STATUS" Status
  492. VALUE NOTATION ::= value (VALUE ObjectName)
  493. Access ::= "read-only"
  494. | "read-write"
  495. | "write-only"
  496. | "not-accessible"
  497. Status ::= "mandatory"
  498. | "optional"
  499. | "obsolete"
  500. END
  501. Given the object types defined earlier, we might imagine the
  502. following definitions being present in the MIB:
  503. atIndex OBJECT-TYPE
  504. Rose & McCloghrie [Page 14]
  505. RFC 1155 SMI May 1990
  506. SYNTAX INTEGER
  507. ACCESS read-write
  508. STATUS mandatory
  509. ::= { atEntry 1 }
  510. atPhysAddress OBJECT-TYPE
  511. SYNTAX OCTET STRING
  512. ACCESS read-write
  513. STATUS mandatory
  514. ::= { atEntry 2 }
  515. atNetAddress OBJECT-TYPE
  516. SYNTAX NetworkAddress
  517. ACCESS read-write
  518. STATUS mandatory
  519. ::= { atEntry 3 }
  520. atEntry OBJECT-TYPE
  521. SYNTAX AtEntry
  522. ACCESS read-write
  523. STATUS mandatory
  524. ::= { atTable 1 }
  525. atTable OBJECT-TYPE
  526. SYNTAX SEQUENCE OF AtEntry
  527. ACCESS read-write
  528. STATUS mandatory
  529. ::= { at 1 }
  530. AtEntry ::= SEQUENCE {
  531. atIndex
  532. INTEGER,
  533. atPhysAddress
  534. OCTET STRING,
  535. atNetAddress
  536. NetworkAddress
  537. }
  538. The first five definitions describe object types, relating, for
  539. example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
  540. atEntry 1 }. In addition, the syntax of this object is defined
  541. (INTEGER) along with the access permitted (read-write) and status
  542. (mandatory). The sixth definition describes an ASN.1 type called
  543. AtEntry.
  544. Rose & McCloghrie [Page 15]
  545. RFC 1155 SMI May 1990
  546. 5. Extensions to the MIB
  547. Every Internet-standard MIB document obsoletes all previous such
  548. documents. The portion of a name, termed the tail, following the
  549. OBJECT IDENTIFIER
  550. { mgmt version-number }
  551. used to name objects shall remain unchanged between versions. New
  552. versions may:
  553. (1) declare old object types obsolete (if necessary), but not
  554. delete their names;
  555. (2) augment the definition of an object type corresponding to a
  556. list by appending non-aggregate object types to the object types
  557. in the list; or,
  558. (3) define entirely new object types.
  559. New versions may not:
  560. (1) change the semantics of any previously defined object without
  561. changing the name of that object.
  562. These rules are important because they admit easier support for
  563. multiple versions of the Internet-standard MIB. In particular, the
  564. semantics associated with the tail of a name remain constant
  565. throughout different versions of the MIB. Because multiple versions
  566. of the MIB may thus coincide in "tail-space," implementations
  567. supporting multiple versions of the MIB can be vastly simplified.
  568. However, as a consequence, a management agent might return an
  569. instance corresponding to a superset of the expected object type.
  570. Following the principle of robustness, in this exceptional case, a
  571. manager should ignore any additional information beyond the
  572. definition of the expected object type. However, the robustness
  573. principle requires that one exercise care with respect to control
  574. actions: if an instance does not have the same syntax as its
  575. expected object type, then those control actions must fail. In both
  576. the monitoring and control cases, the name of an object returned by
  577. an operation must be identical to the name requested by an operation.
  578. Rose & McCloghrie [Page 16]
  579. RFC 1155 SMI May 1990
  580. 6. Definitions
  581. RFC1155-SMI DEFINITIONS ::= BEGIN
  582. EXPORTS -- EVERYTHING
  583. internet, directory, mgmt,
  584. experimental, private, enterprises,
  585. OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,
  586. ApplicationSyntax, NetworkAddress, IpAddress,
  587. Counter, Gauge, TimeTicks, Opaque;
  588. -- the path to the root
  589. internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
  590. directory OBJECT IDENTIFIER ::= { internet 1 }
  591. mgmt OBJECT IDENTIFIER ::= { internet 2 }
  592. experimental OBJECT IDENTIFIER ::= { internet 3 }
  593. private OBJECT IDENTIFIER ::= { internet 4 }
  594. enterprises OBJECT IDENTIFIER ::= { private 1 }
  595. -- definition of object types
  596. OBJECT-TYPE MACRO ::=
  597. BEGIN
  598. TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
  599. "ACCESS" Access
  600. "STATUS" Status
  601. VALUE NOTATION ::= value (VALUE ObjectName)
  602. Access ::= "read-only"
  603. | "read-write"
  604. | "write-only"
  605. | "not-accessible"
  606. Status ::= "mandatory"
  607. | "optional"
  608. | "obsolete"
  609. END
  610. -- names of objects in the MIB
  611. ObjectName ::=
  612. OBJECT IDENTIFIER
  613. Rose & McCloghrie [Page 17]
  614. RFC 1155 SMI May 1990
  615. -- syntax of objects in the MIB
  616. ObjectSyntax ::=
  617. CHOICE {
  618. simple
  619. SimpleSyntax,
  620. -- note that simple SEQUENCEs are not directly
  621. -- mentioned here to keep things simple (i.e.,
  622. -- prevent mis-use). However, application-wide
  623. -- types which are IMPLICITly encoded simple
  624. -- SEQUENCEs may appear in the following CHOICE
  625. application-wide
  626. ApplicationSyntax
  627. }
  628. SimpleSyntax ::=
  629. CHOICE {
  630. number
  631. INTEGER,
  632. string
  633. OCTET STRING,
  634. object
  635. OBJECT IDENTIFIER,
  636. empty
  637. NULL
  638. }
  639. ApplicationSyntax ::=
  640. CHOICE {
  641. address
  642. NetworkAddress,
  643. counter
  644. Counter,
  645. gauge
  646. Gauge,
  647. ticks
  648. TimeTicks,
  649. arbitrary
  650. Opaque
  651. Rose & McCloghrie [Page 18]
  652. RFC 1155 SMI May 1990
  653. -- other application-wide types, as they are
  654. -- defined, will be added here
  655. }
  656. -- application-wide types
  657. NetworkAddress ::=
  658. CHOICE {
  659. internet
  660. IpAddress
  661. }
  662. IpAddress ::=
  663. [APPLICATION 0] -- in network-byte order
  664. IMPLICIT OCTET STRING (SIZE (4))
  665. Counter ::=
  666. [APPLICATION 1]
  667. IMPLICIT INTEGER (0..4294967295)
  668. Gauge ::=
  669. [APPLICATION 2]
  670. IMPLICIT INTEGER (0..4294967295)
  671. TimeTicks ::=
  672. [APPLICATION 3]
  673. IMPLICIT INTEGER (0..4294967295)
  674. Opaque ::=
  675. [APPLICATION 4] -- arbitrary ASN.1 value,
  676. IMPLICIT OCTET STRING -- "double-wrapped"
  677. END
  678. Rose & McCloghrie [Page 19]
  679. RFC 1155 SMI May 1990
  680. 7. Acknowledgements
  681. This memo was influenced by three sets of contributors to earlier
  682. drafts:
  683. First, Lee Labarre of the MITRE Corporation, who as author of the
  684. NETMAN SMI [4], presented the basic roadmap for the SMI.
  685. Second, several individuals who provided valuable comments on this
  686. memo prior to its initial distribution:
  687. James R. Davin, Proteon
  688. Mark S. Fedor, NYSERNet
  689. Craig Partridge, BBN Laboratories
  690. Martin Lee Schoffstall, Rensselaer Polytechnic Institute
  691. Wengyik Yeong, NYSERNet
  692. Third, the IETF MIB working group:
  693. Karl Auerbach, Epilogue Technology
  694. K. Ramesh Babu, Excelan
  695. Lawrence Besaw, Hewlett-Packard
  696. Jeffrey D. Case, University of Tennessee at Knoxville
  697. James R. Davin, Proteon
  698. Mark S. Fedor, NYSERNet
  699. Robb Foster, BBN
  700. Phill Gross, The MITRE Corporation
  701. Bent Torp Jensen, Convergent Technology
  702. Lee Labarre, The MITRE Corporation
  703. Dan Lynch, Advanced Computing Environments
  704. Keith McCloghrie, The Wollongong Group
  705. Dave Mackie, 3Com/Bridge
  706. Craig Partridge, BBN (chair)
  707. Jim Robertson, 3Com/Bridge
  708. Marshall T. Rose, The Wollongong Group
  709. Greg Satz, cisco
  710. Martin Lee Schoffstall, Rensselaer Polytechnic Institute
  711. Lou Steinberg, IBM
  712. Dean Throop, Data General
  713. Unni Warrier, Unisys
  714. Rose & McCloghrie [Page 20]
  715. RFC 1155 SMI May 1990
  716. 8. References
  717. [1] Information processing systems - Open Systems Interconnection,
  718. "Specification of Abstract Syntax Notation One (ASN.1)",
  719. International Organization for Standardization, International
  720. Standard 8824, December 1987.
  721. [2] McCloghrie K., and M. Rose, "Management Information Base for
  722. Network Management of TCP/IP-based Internets", RFC 1156,
  723. Performance Systems International and Hughes LAN Systems, May
  724. 1990.
  725. [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
  726. Network Management Protocol", RFC 1157, University of Tennessee
  727. at Knoxville, Performance Systems International, Performance
  728. Systems International, and the MIT Laboratory for Computer
  729. Science, May 1990.
  730. [4] LaBarre, L., "Structure and Identification of Management
  731. Information for the Internet", Internet Engineering Task Force
  732. working note, Network Information Center, SRI International,
  733. Menlo Park, California, April 1988.
  734. [5] Cerf, V., "IAB Recommendations for the Development of Internet
  735. Network Management Standards", RFC 1052, IAB, April 1988.
  736. [6] Cerf, V., "Report of the Second Ad Hoc Network Management Review
  737. Group", RFC 1109, IAB, August 1989.
  738. [7] Information processing systems - Open Systems Interconnection,
  739. "Specification of Basic Encoding Rules for Abstract Notation One
  740. (ASN.1)", International Organization for Standardization,
  741. International Standard 8825, December 1987.
  742. Security Considerations
  743. Security issues are not discussed in this memo.
  744. Rose & McCloghrie [Page 21]
  745. RFC 1155 SMI May 1990
  746. Authors' Addresses
  747. Marshall T. Rose
  748. PSI, Inc.
  749. PSI California Office
  750. P.O. Box 391776
  751. Mountain View, CA 94039
  752. Phone: (415) 961-3380
  753. EMail: mrose@PSI.COM
  754. Keith McCloghrie
  755. The Wollongong Group
  756. 1129 San Antonio Road
  757. Palo Alto, CA 04303
  758. Phone: (415) 962-7160
  759. EMail: sytek!kzm@HPLABS.HP.COM
  760. Rose & McCloghrie [Page 22]