![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1157.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 rfc1157.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 J. Case
8: Request for Comments: 1157 SNMP Research
9: Obsoletes: RFC 1098 M. Fedor
10: Performance Systems International
11: M. Schoffstall
12: Performance Systems International
13: J. Davin
14: MIT Laboratory for Computer Science
15: May 1990
16:
17:
18: A Simple Network Management Protocol (SNMP)
19:
20: Table of Contents
21:
22: 1. Status of this Memo ................................... 2
23: 2. Introduction .......................................... 2
24: 3. The SNMP Architecture ................................. 5
25: 3.1 Goals of the Architecture ............................ 5
26: 3.2 Elements of the Architecture ......................... 5
27: 3.2.1 Scope of Management Information .................... 6
28: 3.2.2 Representation of Management Information ........... 6
29: 3.2.3 Operations Supported on Management Information ..... 7
30: 3.2.4 Form and Meaning of Protocol Exchanges ............. 8
31: 3.2.5 Definition of Administrative Relationships ......... 8
32: 3.2.6 Form and Meaning of References to Managed Objects .. 12
33: 3.2.6.1 Resolution of Ambiguous MIB References ........... 12
34: 3.2.6.2 Resolution of References across MIB Versions...... 12
35: 3.2.6.3 Identification of Object Instances ............... 12
36: 3.2.6.3.1 ifTable Object Type Names ...................... 13
37: 3.2.6.3.2 atTable Object Type Names ...................... 13
38: 3.2.6.3.3 ipAddrTable Object Type Names .................. 14
39: 3.2.6.3.4 ipRoutingTable Object Type Names ............... 14
40: 3.2.6.3.5 tcpConnTable Object Type Names ................. 14
41: 3.2.6.3.6 egpNeighTable Object Type Names ................ 15
42: 4. Protocol Specification ................................ 16
43: 4.1 Elements of Procedure ................................ 17
44: 4.1.1 Common Constructs .................................. 19
45: 4.1.2 The GetRequest-PDU ................................. 20
46: 4.1.3 The GetNextRequest-PDU ............................. 21
47: 4.1.3.1 Example of Table Traversal ....................... 23
48: 4.1.4 The GetResponse-PDU ................................ 24
49: 4.1.5 The SetRequest-PDU ................................. 25
50: 4.1.6 The Trap-PDU ....................................... 27
51: 4.1.6.1 The coldStart Trap ............................... 28
52: 4.1.6.2 The warmStart Trap ............................... 28
53: 4.1.6.3 The linkDown Trap ................................ 28
54: 4.1.6.4 The linkUp Trap .................................. 28
55:
56:
57:
58: Case, Fedor, Schoffstall, & Davin [Page 1]
59:
60: RFC 1157 SNMP May 1990
61:
62:
63: 4.1.6.5 The authenticationFailure Trap ................... 28
64: 4.1.6.6 The egpNeighborLoss Trap ......................... 28
65: 4.1.6.7 The enterpriseSpecific Trap ...................... 29
66: 5. Definitions ........................................... 30
67: 6. Acknowledgements ...................................... 33
68: 7. References ............................................ 34
69: 8. Security Considerations................................ 35
70: 9. Authors' Addresses..................................... 35
71:
72: 1. Status of this Memo
73:
74: This RFC is a re-release of RFC 1098, with a changed "Status of this
75: Memo" section plus a few minor typographical corrections. This memo
76: defines a simple protocol by which management information for a
77: network element may be inspected or altered by logically remote
78: users. In particular, together with its companion memos which
79: describe the structure of management information along with the
80: management information base, these documents provide a simple,
81: workable architecture and system for managing TCP/IP-based internets
82: and in particular the Internet.
83:
84: The Internet Activities Board recommends that all IP and TCP
85: implementations be network manageable. This implies implementation
86: of the Internet MIB (RFC-1156) and at least one of the two
87: recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
88: It should be noted that, at this time, SNMP is a full Internet
89: standard and CMOT is a draft standard. See also the Host and Gateway
90: Requirements RFCs for more specific information on the applicability
91: of this standard.
92:
93: Please refer to the latest edition of the "IAB Official Protocol
94: Standards" RFC for current information on the state and status of
95: standard Internet protocols.
96:
97: Distribution of this memo is unlimited.
98:
99: 2. Introduction
100:
101: As reported in RFC 1052, IAB Recommendations for the Development of
102: Internet Network Management Standards [1], a two-prong strategy for
103: network management of TCP/IP-based internets was undertaken. In the
104: short-term, the Simple Network Management Protocol (SNMP) was to be
105: used to manage nodes in the Internet community. In the long-term,
106: the use of the OSI network management framework was to be examined.
107: Two documents were produced to define the management information: RFC
108: 1065, which defined the Structure of Management Information (SMI)
109: [2], and RFC 1066, which defined the Management Information Base
110: (MIB) [3]. Both of these documents were designed so as to be
111:
112:
113:
114: Case, Fedor, Schoffstall, & Davin [Page 2]
115:
116: RFC 1157 SNMP May 1990
117:
118:
119: compatible with both the SNMP and the OSI network management
120: framework.
121:
122: This strategy was quite successful in the short-term: Internet-based
123: network management technology was fielded, by both the research and
124: commercial communities, within a few months. As a result of this,
125: portions of the Internet community became network manageable in a
126: timely fashion.
127:
128: As reported in RFC 1109, Report of the Second Ad Hoc Network
129: Management Review Group [4], the requirements of the SNMP and the OSI
130: network management frameworks were more different than anticipated.
131: As such, the requirement for compatibility between the SMI/MIB and
132: both frameworks was suspended. This action permitted the operational
133: network management framework, the SNMP, to respond to new operational
134: needs in the Internet community by producing documents defining new
135: MIB items.
136:
137: The IAB has designated the SNMP, SMI, and the initial Internet MIB to
138: be full "Standard Protocols" with "Recommended" status. By this
139: action, the IAB recommends that all IP and TCP implementations be
140: network manageable and that the implementations that are network
141: manageable are expected to adopt and implement the SMI, MIB, and
142: SNMP.
143:
144: As such, the current network management framework for TCP/IP- based
145: internets consists of: Structure and Identification of Management
146: Information for TCP/IP-based Internets, which describes how managed
147: objects contained in the MIB are defined as set forth in RFC 1155
148: [5]; Management Information Base for Network Management of TCP/IP-
149: based Internets, which describes the managed objects contained in the
150: MIB as set forth in RFC 1156 [6]; and, the Simple Network Management
151: Protocol, which defines the protocol used to manage these objects, as
152: set forth in this memo.
153:
154: As reported in RFC 1052, IAB Recommendations for the Development of
155: Internet Network Management Standards [1], the Internet Activities
156: Board has directed the Internet Engineering Task Force (IETF) to
157: create two new working groups in the area of network management. One
158: group was charged with the further specification and definition of
159: elements to be included in the Management Information Base (MIB).
160: The other was charged with defining the modifications to the Simple
161: Network Management Protocol (SNMP) to accommodate the short-term
162: needs of the network vendor and operations communities, and to align
163: with the output of the MIB working group.
164:
165: The MIB working group produced two memos, one which defines a
166: Structure for Management Information (SMI) [2] for use by the managed
167:
168:
169:
170: Case, Fedor, Schoffstall, & Davin [Page 3]
171:
172: RFC 1157 SNMP May 1990
173:
174:
175: objects contained in the MIB. A second memo [3] defines the list of
176: managed objects.
177:
178: The output of the SNMP Extensions working group is this memo, which
179: incorporates changes to the initial SNMP definition [7] required to
180: attain alignment with the output of the MIB working group. The
181: changes should be minimal in order to be consistent with the IAB's
182: directive that the working groups be "extremely sensitive to the need
183: to keep the SNMP simple." Although considerable care and debate has
184: gone into the changes to the SNMP which are reflected in this memo,
185: the resulting protocol is not backwardly-compatible with its
186: predecessor, the Simple Gateway Monitoring Protocol (SGMP) [8].
187: Although the syntax of the protocol has been altered, the original
188: philosophy, design decisions, and architecture remain intact. In
189: order to avoid confusion, new UDP ports have been allocated for use
190: by the protocol described in this memo.
191:
192:
193:
194:
195:
196:
197:
198:
199:
200:
201:
202:
203:
204:
205:
206:
207:
208:
209:
210:
211:
212:
213:
214:
215:
216:
217:
218:
219:
220:
221:
222:
223:
224:
225:
226: Case, Fedor, Schoffstall, & Davin [Page 4]
227:
228: RFC 1157 SNMP May 1990
229:
230:
231: 3. The SNMP Architecture
232:
233: Implicit in the SNMP architectural model is a collection of network
234: management stations and network elements. Network management
235: stations execute management applications which monitor and control
236: network elements. Network elements are devices such as hosts,
237: gateways, terminal servers, and the like, which have management
238: agents responsible for performing the network management functions
239: requested by the network management stations. The Simple Network
240: Management Protocol (SNMP) is used to communicate management
241: information between the network management stations and the agents in
242: the network elements.
243:
244: 3.1. Goals of the Architecture
245:
246: The SNMP explicitly minimizes the number and complexity of management
247: functions realized by the management agent itself. This goal is
248: attractive in at least four respects:
249:
250: (1) The development cost for management agent software
251: necessary to support the protocol is accordingly reduced.
252:
253: (2) The degree of management function that is remotely
254: supported is accordingly increased, thereby admitting
255: fullest use of internet resources in the management task.
256:
257: (3) The degree of management function that is remotely
258: supported is accordingly increased, thereby imposing the
259: fewest possible restrictions on the form and
260: sophistication of management tools.
261:
262: (4) Simplified sets of management functions are easily
263: understood and used by developers of network management
264: tools.
265:
266: A second goal of the protocol is that the functional paradigm for
267: monitoring and control be sufficiently extensible to accommodate
268: additional, possibly unanticipated aspects of network operation and
269: management.
270:
271: A third goal is that the architecture be, as much as possible,
272: independent of the architecture and mechanisms of particular hosts or
273: particular gateways.
274:
275: 3.2. Elements of the Architecture
276:
277: The SNMP architecture articulates a solution to the network
278: management problem in terms of:
279:
280:
281:
282: Case, Fedor, Schoffstall, & Davin [Page 5]
283:
284: RFC 1157 SNMP May 1990
285:
286:
287: (1) the scope of the management information communicated by
288: the protocol,
289:
290: (2) the representation of the management information
291: communicated by the protocol,
292:
293: (3) operations on management information supported by the
294: protocol,
295:
296: (4) the form and meaning of exchanges among management
297: entities,
298:
299: (5) the definition of administrative relationships among
300: management entities, and
301:
302: (6) the form and meaning of references to management
303: information.
304:
305: 3.2.1. Scope of Management Information
306:
307: The scope of the management information communicated by operation of
308: the SNMP is exactly that represented by instances of all non-
309: aggregate object types either defined in Internet-standard MIB or
310: defined elsewhere according to the conventions set forth in
311: Internet-standard SMI [5].
312:
313: Support for aggregate object types in the MIB is neither required for
314: conformance with the SMI nor realized by the SNMP.
315:
316: 3.2.2. Representation of Management Information
317:
318: Management information communicated by operation of the SNMP is
319: represented according to the subset of the ASN.1 language [9] that is
320: specified for the definition of non-aggregate types in the SMI.
321:
322: The SGMP adopted the convention of using a well-defined subset of the
323: ASN.1 language [9]. The SNMP continues and extends this tradition by
324: utilizing a moderately more complex subset of ASN.1 for describing
325: managed objects and for describing the protocol data units used for
326: managing those objects. In addition, the desire to ease eventual
327: transition to OSI-based network management protocols led to the
328: definition in the ASN.1 language of an Internet-standard Structure of
329: Management Information (SMI) [5] and Management Information Base
330: (MIB) [6]. The use of the ASN.1 language, was, in part, encouraged
331: by the successful use of ASN.1 in earlier efforts, in particular, the
332: SGMP. The restrictions on the use of ASN.1 that are part of the SMI
333: contribute to the simplicity espoused and validated by experience
334: with the SGMP.
335:
336:
337:
338: Case, Fedor, Schoffstall, & Davin [Page 6]
339:
340: RFC 1157 SNMP May 1990
341:
342:
343: Also for the sake of simplicity, the SNMP uses only a subset of the
344: basic encoding rules of ASN.1 [10]. Namely, all encodings use the
345: definite-length form. Further, whenever permissible, non-constructor
346: encodings are used rather than constructor encodings. This
347: restriction applies to all aspects of ASN.1 encoding, both for the
348: top-level protocol data units and the data objects they contain.
349:
350: 3.2.3. Operations Supported on Management Information
351:
352: The SNMP models all management agent functions as alterations or
353: inspections of variables. Thus, a protocol entity on a logically
354: remote host (possibly the network element itself) interacts with the
355: management agent resident on the network element in order to retrieve
356: (get) or alter (set) variables. This strategy has at least two
357: positive consequences:
358:
359: (1) It has the effect of limiting the number of essential
360: management functions realized by the management agent to
361: two: one operation to assign a value to a specified
362: configuration or other parameter and another to retrieve
363: such a value.
364:
365: (2) A second effect of this decision is to avoid introducing
366: into the protocol definition support for imperative
367: management commands: the number of such commands is in
368: practice ever-increasing, and the semantics of such
369: commands are in general arbitrarily complex.
370:
371: The strategy implicit in the SNMP is that the monitoring of network
372: state at any significant level of detail is accomplished primarily by
373: polling for appropriate information on the part of the monitoring
374: center(s). A limited number of unsolicited messages (traps) guide
375: the timing and focus of the polling. Limiting the number of
376: unsolicited messages is consistent with the goal of simplicity and
377: minimizing the amount of traffic generated by the network management
378: function.
379:
380: The exclusion of imperative commands from the set of explicitly
381: supported management functions is unlikely to preclude any desirable
382: management agent operation. Currently, most commands are requests
383: either to set the value of some parameter or to retrieve such a
384: value, and the function of the few imperative commands currently
385: supported is easily accommodated in an asynchronous mode by this
386: management model. In this scheme, an imperative command might be
387: realized as the setting of a parameter value that subsequently
388: triggers the desired action. For example, rather than implementing a
389: "reboot command," this action might be invoked by simply setting a
390: parameter indicating the number of seconds until system reboot.
391:
392:
393:
394: Case, Fedor, Schoffstall, & Davin [Page 7]
395:
396: RFC 1157 SNMP May 1990
397:
398:
399: 3.2.4. Form and Meaning of Protocol Exchanges
400:
401: The communication of management information among management entities
402: is realized in the SNMP through the exchange of protocol messages.
403: The form and meaning of those messages is defined below in Section 4.
404:
405: Consistent with the goal of minimizing complexity of the management
406: agent, the exchange of SNMP messages requires only an unreliable
407: datagram service, and every message is entirely and independently
408: represented by a single transport datagram. While this document
409: specifies the exchange of messages via the UDP protocol [11], the
410: mechanisms of the SNMP are generally suitable for use with a wide
411: variety of transport services.
412:
413: 3.2.5. Definition of Administrative Relationships
414:
415: The SNMP architecture admits a variety of administrative
416: relationships among entities that participate in the protocol. The
417: entities residing at management stations and network elements which
418: communicate with one another using the SNMP are termed SNMP
419: application entities. The peer processes which implement the SNMP,
420: and thus support the SNMP application entities, are termed protocol
421: entities.
422:
423: A pairing of an SNMP agent with some arbitrary set of SNMP
424: application entities is called an SNMP community. Each SNMP
425: community is named by a string of octets, that is called the
426: community name for said community.
427:
428: An SNMP message originated by an SNMP application entity that in fact
429: belongs to the SNMP community named by the community component of
430: said message is called an authentic SNMP message. The set of rules
431: by which an SNMP message is identified as an authentic SNMP message
432: for a particular SNMP community is called an authentication scheme.
433: An implementation of a function that identifies authentic SNMP
434: messages according to one or more authentication schemes is called an
435: authentication service.
436:
437: Clearly, effective management of administrative relationships among
438: SNMP application entities requires authentication services that (by
439: the use of encryption or other techniques) are able to identify
440: authentic SNMP messages with a high degree of certainty. Some SNMP
441: implementations may wish to support only a trivial authentication
442: service that identifies all SNMP messages as authentic SNMP messages.
443:
444: For any network element, a subset of objects in the MIB that pertain
445: to that element is called a SNMP MIB view. Note that the names of
446: the object types represented in a SNMP MIB view need not belong to a
447:
448:
449:
450: Case, Fedor, Schoffstall, & Davin [Page 8]
451:
452: RFC 1157 SNMP May 1990
453:
454:
455: single sub-tree of the object type name space.
456:
457: An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
458: access mode.
459:
460: A pairing of a SNMP access mode with a SNMP MIB view is called an
461: SNMP community profile. A SNMP community profile represents
462: specified access privileges to variables in a specified MIB view. For
463: every variable in the MIB view in a given SNMP community profile,
464: access to that variable is represented by the profile according to
465: the following conventions:
466:
467: (1) if said variable is defined in the MIB with "Access:" of
468: "none," it is unavailable as an operand for any operator;
469:
470: (2) if said variable is defined in the MIB with "Access:" of
471: "read-write" or "write-only" and the access mode of the
472: given profile is READ-WRITE, that variable is available
473: as an operand for the get, set, and trap operations;
474:
475: (3) otherwise, the variable is available as an operand for
476: the get and trap operations.
477:
478: (4) In those cases where a "write-only" variable is an
479: operand used for the get or trap operations, the value
480: given for the variable is implementation-specific.
481:
482: A pairing of a SNMP community with a SNMP community profile is called
483: a SNMP access policy. An access policy represents a specified
484: community profile afforded by the SNMP agent of a specified SNMP
485: community to other members of that community. All administrative
486: relationships among SNMP application entities are architecturally
487: defined in terms of SNMP access policies.
488:
489: For every SNMP access policy, if the network element on which the
490: SNMP agent for the specified SNMP community resides is not that to
491: which the MIB view for the specified profile pertains, then that
492: policy is called a SNMP proxy access policy. The SNMP agent
493: associated with a proxy access policy is called a SNMP proxy agent.
494: While careless definition of proxy access policies can result in
495: management loops, prudent definition of proxy policies is useful in
496: at least two ways:
497:
498: (1) It permits the monitoring and control of network elements
499: which are otherwise not addressable using the management
500: protocol and the transport protocol. That is, a proxy
501: agent may provide a protocol conversion function allowing
502: a management station to apply a consistent management
503:
504:
505:
506: Case, Fedor, Schoffstall, & Davin [Page 9]
507:
508: RFC 1157 SNMP May 1990
509:
510:
511: framework to all network elements, including devices such
512: as modems, multiplexors, and other devices which support
513: different management frameworks.
514:
515: (2) It potentially shields network elements from elaborate
516: access control policies. For example, a proxy agent may
517: implement sophisticated access control whereby diverse
518: subsets of variables within the MIB are made accessible
519: to different management stations without increasing the
520: complexity of the network element.
521:
522: By way of example, Figure 1 illustrates the relationship between
523: management stations, proxy agents, and management agents. In this
524: example, the proxy agent is envisioned to be a normal Internet
525: Network Operations Center (INOC) of some administrative domain which
526: has a standard managerial relationship with a set of management
527: agents.
528:
529:
530:
531:
532:
533:
534:
535:
536:
537:
538:
539:
540:
541:
542:
543:
544:
545:
546:
547:
548:
549:
550:
551:
552:
553:
554:
555:
556:
557:
558:
559:
560:
561:
562: Case, Fedor, Schoffstall, & Davin [Page 10]
563:
564: RFC 1157 SNMP May 1990
565:
566:
567: +------------------+ +----------------+ +----------------+
568: | Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
569: | | | | | |
570: |Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
571: |CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
572: |PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
573: | | | | | |
574: +------------------+ +----------------+ +----------------+
575: /|\ /|\ /|\
576: | | |
577: | | |
578: | \|/ |
579: | +-----------------+ |
580: +-------------->| Region #3 INOC |<-------------+
581: | |
582: |Domain=Region #3 |
583: |CPU=super-mini-2 |
584: |PCommunity=pub, |
585: | slate |
586: |DCommunity=secret|
587: +-------------->| |<-------------+
588: | +-----------------+ |
589: | /|\ |
590: | | |
591: | | |
592: \|/ \|/ \|/
593: +-----------------+ +-----------------+ +-----------------+
594: |Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
595: |CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
596: |DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
597: +-----------------+ +-----------------+ +-----------------+
598:
599:
600: Domain: the administrative domain of the element
601: PCommunity: the name of a community utilizing a proxy agent
602: DCommunity: the name of a direct community
603:
604:
605: Figure 1
606: Example Network Management Configuration
607:
608:
609:
610:
611:
612:
613:
614:
615:
616:
617:
618: Case, Fedor, Schoffstall, & Davin [Page 11]
619:
620: RFC 1157 SNMP May 1990
621:
622:
623: 3.2.6. Form and Meaning of References to Managed Objects
624:
625: The SMI requires that the definition of a conformant management
626: protocol address:
627:
628: (1) the resolution of ambiguous MIB references,
629:
630: (2) the resolution of MIB references in the presence multiple
631: MIB versions, and
632:
633: (3) the identification of particular instances of object
634: types defined in the MIB.
635:
636: 3.2.6.1. Resolution of Ambiguous MIB References
637:
638: Because the scope of any SNMP operation is conceptually confined to
639: objects relevant to a single network element, and because all SNMP
640: references to MIB objects are (implicitly or explicitly) by unique
641: variable names, there is no possibility that any SNMP reference to
642: any object type defined in the MIB could resolve to multiple
643: instances of that type.
644:
645: 3.2.6.2. Resolution of References across MIB Versions
646:
647: The object instance referred to by any SNMP operation is exactly that
648: specified as part of the operation request or (in the case of a get-
649: next operation) its immediate successor in the MIB as a whole. In
650: particular, a reference to an object as part of some version of the
651: Internet-standard MIB does not resolve to any object that is not part
652: of said version of the Internet-standard MIB, except in the case that
653: the requested operation is get-next and the specified object name is
654: lexicographically last among the names of all objects presented as
655: part of said version of the Internet-Standard MIB.
656:
657: 3.2.6.3. Identification of Object Instances
658:
659: The names for all object types in the MIB are defined explicitly
660: either in the Internet-standard MIB or in other documents which
661: conform to the naming conventions of the SMI. The SMI requires that
662: conformant management protocols define mechanisms for identifying
663: individual instances of those object types for a particular network
664: element.
665:
666: Each instance of any object type defined in the MIB is identified in
667: SNMP operations by a unique name called its "variable name." In
668: general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
669: form x.y, where x is the name of a non-aggregate object type defined
670: in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
671:
672:
673:
674: Case, Fedor, Schoffstall, & Davin [Page 12]
675:
676: RFC 1157 SNMP May 1990
677:
678:
679: specific to the named object type, identifies the desired instance.
680:
681: This naming strategy admits the fullest exploitation of the semantics
682: of the GetNextRequest-PDU (see Section 4), because it assigns names
683: for related variables so as to be contiguous in the lexicographical
684: ordering of all variable names known in the MIB.
685:
686: The type-specific naming of object instances is defined below for a
687: number of classes of object types. Instances of an object type to
688: which none of the following naming conventions are applicable are
689: named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
690: said object type in the MIB definition.
691:
692: For example, suppose one wanted to identify an instance of the
693: variable sysDescr The object class for sysDescr is:
694:
695: iso org dod internet mgmt mib system sysDescr
696: 1 3 6 1 2 1 1 1
697:
698: Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
699: appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0
700: identifies the one and only instance of sysDescr.
701:
702: 3.2.6.3.1. ifTable Object Type Names
703:
704: The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
705: the form i, where i has the value of that instance of the ifIndex
706: object type associated with s.
707:
708: For each object type, t, for which the defined name, n, has a prefix
709: of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
710: the form n.s, where s is the name of the subnet interface about which
711: i represents information.
712:
713: For example, suppose one wanted to identify the instance of the
714: variable ifType associated with interface 2. Accordingly, ifType.2
715: would identify the desired instance.
716:
717: 3.2.6.3.2. atTable Object Type Names
718:
719: The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
720: of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
721: "dot" notation) of the atNetAddress object type associated with x.
722:
723: The name of an address translation equivalence e is an OBJECT
724: IDENTIFIER value of the form s.w, such that s is the value of that
725: instance of the atIndex object type associated with e and such that w
726: is the name of the AT-cached network address associated with e.
727:
728:
729:
730: Case, Fedor, Schoffstall, & Davin [Page 13]
731:
732: RFC 1157 SNMP May 1990
733:
734:
735: For each object type, t, for which the defined name, n, has a prefix
736: of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
737: the form n.y, where y is the name of the address translation
738: equivalence about which i represents information.
739:
740: For example, suppose one wanted to find the physical address of an
741: entry in the address translation table (ARP cache) associated with an
742: IP address of 89.1.1.42 and interface 3. Accordingly,
743: atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
744:
745: 3.2.6.3.3. ipAddrTable Object Type Names
746:
747: The name of an IP-addressable network element, x, is the OBJECT
748: IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
749: familiar "dot" notation) of that instance of the ipAdEntAddr object
750: type associated with x.
751:
752: For each object type, t, for which the defined name, n, has a prefix
753: of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
754: of the form n.y, where y is the name of the IP-addressable network
755: element about which i represents information.
756:
757: For example, suppose one wanted to find the network mask of an entry
758: in the IP interface table associated with an IP address of 89.1.1.42.
759: Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
760: instance.
761:
762: 3.2.6.3.4. ipRoutingTable Object Type Names
763:
764: The name of an IP route, x, is the OBJECT IDENTIFIER of the form
765: a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
766: notation) of that instance of the ipRouteDest object type associated
767: with x.
768:
769: For each object type, t, for which the defined name, n, has a prefix
770: of ipRoutingEntry, an instance, i, of t is named by an OBJECT
771: IDENTIFIER of the form n.y, where y is the name of the IP route about
772: which i represents information.
773:
774: For example, suppose one wanted to find the next hop of an entry in
775: the IP routing table associated with the destination of 89.1.1.42.
776: Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
777: instance.
778:
779: 3.2.6.3.5. tcpConnTable Object Type Names
780:
781: The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
782: a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
783:
784:
785:
786: Case, Fedor, Schoffstall, & Davin [Page 14]
787:
788: RFC 1157 SNMP May 1990
789:
790:
791: "dot" notation) of that instance of the tcpConnLocalAddress object
792: type associated with x and such that f.g.h.i is the value (in the
793: familiar "dot" notation) of that instance of the tcpConnRemoteAddress
794: object type associated with x and such that e is the value of that
795: instance of the tcpConnLocalPort object type associated with x and
796: such that j is the value of that instance of the tcpConnRemotePort
797: object type associated with x.
798:
799: For each object type, t, for which the defined name, n, has a prefix
800: of tcpConnEntry, an instance, i, of t is named by an OBJECT
801: IDENTIFIER of the form n.y, where y is the name of the TCP connection
802: about which i represents information.
803:
804: For example, suppose one wanted to find the state of a TCP connection
805: between the local address of 89.1.1.42 on TCP port 21 and the remote
806: address of 10.0.0.51 on TCP port 2059. Accordingly,
807: tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
808: instance.
809:
810: 3.2.6.3.6. egpNeighTable Object Type Names
811:
812: The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
813: a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
814: notation) of that instance of the egpNeighAddr object type associated
815: with x.
816:
817: For each object type, t, for which the defined name, n, has a prefix
818: of egpNeighEntry, an instance, i, of t is named by an OBJECT
819: IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
820: about which i represents information.
821:
822: For example, suppose one wanted to find the neighbor state for the IP
823: address of 89.1.1.42. Accordingly, egpNeighState.89.1.1.42 would
824: identify the desired instance.
825:
826:
827:
828:
829:
830:
831:
832:
833:
834:
835:
836:
837:
838:
839:
840:
841:
842: Case, Fedor, Schoffstall, & Davin [Page 15]
843:
844: RFC 1157 SNMP May 1990
845:
846:
847: 4. Protocol Specification
848:
849: The network management protocol is an application protocol by which
850: the variables of an agent's MIB may be inspected or altered.
851:
852: Communication among protocol entities is accomplished by the exchange
853: of messages, each of which is entirely and independently represented
854: within a single UDP datagram using the basic encoding rules of ASN.1
855: (as discussed in Section 3.2.2). A message consists of a version
856: identifier, an SNMP community name, and a protocol data unit (PDU).
857: A protocol entity receives messages at UDP port 161 on the host with
858: which it is associated for all messages except for those which report
859: traps (i.e., all messages except those which contain the Trap-PDU).
860: Messages which report traps should be received on UDP port 162 for
861: further processing. An implementation of this protocol need not
862: accept messages whose length exceeds 484 octets. However, it is
863: recommended that implementations support larger datagrams whenever
864: feasible.
865:
866: It is mandatory that all implementations of the SNMP support the five
867: PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
868: SetRequest-PDU, and Trap-PDU.
869:
870: RFC1157-SNMP DEFINITIONS ::= BEGIN
871:
872: IMPORTS
873: ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
874: FROM RFC1155-SMI;
875:
876:
877: -- top-level message
878:
879: Message ::=
880: SEQUENCE {
881: version -- version-1 for this RFC
882: INTEGER {
883: version-1(0)
884: },
885:
886: community -- community name
887: OCTET STRING,
888:
889: data -- e.g., PDUs if trivial
890: ANY -- authentication is being used
891: }
892:
893:
894:
895:
896:
897:
898: Case, Fedor, Schoffstall, & Davin [Page 16]
899:
900: RFC 1157 SNMP May 1990
901:
902:
903: -- protocol data units
904:
905: PDUs ::=
906: CHOICE {
907: get-request
908: GetRequest-PDU,
909:
910: get-next-request
911: GetNextRequest-PDU,
912:
913: get-response
914: GetResponse-PDU,
915:
916: set-request
917: SetRequest-PDU,
918:
919: trap
920: Trap-PDU
921: }
922:
923: -- the individual PDUs and commonly used
924: -- data types will be defined later
925:
926: END
927:
928:
929: 4.1. Elements of Procedure
930:
931: This section describes the actions of a protocol entity implementing
932: the SNMP. Note, however, that it is not intended to constrain the
933: internal architecture of any conformant implementation.
934:
935: In the text that follows, the term transport address is used. In the
936: case of the UDP, a transport address consists of an IP address along
937: with a UDP port. Other transport services may be used to support the
938: SNMP. In these cases, the definition of a transport address should
939: be made accordingly.
940:
941: The top-level actions of a protocol entity which generates a message
942: are as follows:
943:
944: (1) It first constructs the appropriate PDU, e.g., the
945: GetRequest-PDU, as an ASN.1 object.
946:
947: (2) It then passes this ASN.1 object along with a community
948: name its source transport address and the destination
949: transport address, to the service which implements the
950: desired authentication scheme. This authentication
951:
952:
953:
954: Case, Fedor, Schoffstall, & Davin [Page 17]
955:
956: RFC 1157 SNMP May 1990
957:
958:
959: service returns another ASN.1 object.
960:
961: (3) The protocol entity then constructs an ASN.1 Message
962: object, using the community name and the resulting ASN.1
963: object.
964:
965: (4) This new ASN.1 object is then serialized, using the basic
966: encoding rules of ASN.1, and then sent using a transport
967: service to the peer protocol entity.
968:
969: Similarly, the top-level actions of a protocol entity which receives
970: a message are as follows:
971:
972: (1) It performs a rudimentary parse of the incoming datagram
973: to build an ASN.1 object corresponding to an ASN.1
974: Message object. If the parse fails, it discards the
975: datagram and performs no further actions.
976:
977: (2) It then verifies the version number of the SNMP message.
978: If there is a mismatch, it discards the datagram and
979: performs no further actions.
980:
981: (3) The protocol entity then passes the community name and
982: user data found in the ASN.1 Message object, along with
983: the datagram's source and destination transport addresses
984: to the service which implements the desired
985: authentication scheme. This entity returns another ASN.1
986: object, or signals an authentication failure. In the
987: latter case, the protocol entity notes this failure,
988: (possibly) generates a trap, and discards the datagram
989: and performs no further actions.
990:
991: (4) The protocol entity then performs a rudimentary parse on
992: the ASN.1 object returned from the authentication service
993: to build an ASN.1 object corresponding to an ASN.1 PDUs
994: object. If the parse fails, it discards the datagram and
995: performs no further actions. Otherwise, using the named
996: SNMP community, the appropriate profile is selected, and
997: the PDU is processed accordingly. If, as a result of
998: this processing, a message is returned then the source
999: transport address that the response message is sent from
1000: shall be identical to the destination transport address
1001: that the original request message was sent to.
1002:
1003:
1004:
1005:
1006:
1007:
1008:
1009:
1010: Case, Fedor, Schoffstall, & Davin [Page 18]
1011:
1012: RFC 1157 SNMP May 1990
1013:
1014:
1015: 4.1.1. Common Constructs
1016:
1017: Before introducing the six PDU types of the protocol, it is
1018: appropriate to consider some of the ASN.1 constructs used frequently:
1019:
1020: -- request/response information
1021:
1022: RequestID ::=
1023: INTEGER
1024:
1025: ErrorStatus ::=
1026: INTEGER {
1027: noError(0),
1028: tooBig(1),
1029: noSuchName(2),
1030: badValue(3),
1031: readOnly(4)
1032: genErr(5)
1033: }
1034:
1035: ErrorIndex ::=
1036: INTEGER
1037:
1038:
1039: -- variable bindings
1040:
1041: VarBind ::=
1042: SEQUENCE {
1043: name
1044: ObjectName,
1045:
1046: value
1047: ObjectSyntax
1048: }
1049:
1050: VarBindList ::=
1051: SEQUENCE OF
1052: VarBind
1053:
1054:
1055: RequestIDs are used to distinguish among outstanding requests. By
1056: use of the RequestID, an SNMP application entity can correlate
1057: incoming responses with outstanding requests. In cases where an
1058: unreliable datagram service is being used, the RequestID also
1059: provides a simple means of identifying messages duplicated by the
1060: network.
1061:
1062: A non-zero instance of ErrorStatus is used to indicate that an
1063:
1064:
1065:
1066: Case, Fedor, Schoffstall, & Davin [Page 19]
1067:
1068: RFC 1157 SNMP May 1990
1069:
1070:
1071: exception occurred while processing a request. In these cases,
1072: ErrorIndex may provide additional information by indicating which
1073: variable in a list caused the exception.
1074:
1075: The term variable refers to an instance of a managed object. A
1076: variable binding, or VarBind, refers to the pairing of the name of a
1077: variable to the variable's value. A VarBindList is a simple list of
1078: variable names and corresponding values. Some PDUs are concerned
1079: only with the name of a variable and not its value (e.g., the
1080: GetRequest-PDU). In this case, the value portion of the binding is
1081: ignored by the protocol entity. However, the value portion must
1082: still have valid ASN.1 syntax and encoding. It is recommended that
1083: the ASN.1 value NULL be used for the value portion of such bindings.
1084:
1085: 4.1.2. The GetRequest-PDU
1086:
1087: The form of the GetRequest-PDU is:
1088: GetRequest-PDU ::=
1089: [0]
1090: IMPLICIT SEQUENCE {
1091: request-id
1092: RequestID,
1093:
1094: error-status -- always 0
1095: ErrorStatus,
1096:
1097: error-index -- always 0
1098: ErrorIndex,
1099:
1100: variable-bindings
1101: VarBindList
1102: }
1103:
1104:
1105: The GetRequest-PDU is generated by a protocol entity only at the
1106: request of its SNMP application entity.
1107:
1108: Upon receipt of the GetRequest-PDU, the receiving protocol entity
1109: responds according to any applicable rule in the list below:
1110:
1111: (1) If, for any object named in the variable-bindings field,
1112: the object's name does not exactly match the name of some
1113: object available for get operations in the relevant MIB
1114: view, then the receiving entity sends to the originator
1115: of the received message the GetResponse-PDU of identical
1116: form, except that the value of the error-status field is
1117: noSuchName, and the value of the error-index field is the
1118: index of said object name component in the received
1119:
1120:
1121:
1122: Case, Fedor, Schoffstall, & Davin [Page 20]
1123:
1124: RFC 1157 SNMP May 1990
1125:
1126:
1127: message.
1128:
1129: (2) If, for any object named in the variable-bindings field,
1130: the object is an aggregate type (as defined in the SMI),
1131: then the receiving entity sends to the originator of the
1132: received message the GetResponse-PDU of identical form,
1133: except that the value of the error-status field is
1134: noSuchName, and the value of the error-index field is the
1135: index of said object name component in the received
1136: message.
1137:
1138: (3) If the size of the GetResponse-PDU generated as described
1139: below would exceed a local limitation, then the receiving
1140: entity sends to the originator of the received message
1141: the GetResponse-PDU of identical form, except that the
1142: value of the error-status field is tooBig, and the value
1143: of the error-index field is zero.
1144:
1145: (4) If, for any object named in the variable-bindings field,
1146: the value of the object cannot be retrieved for reasons
1147: not covered by any of the foregoing rules, then the
1148: receiving entity sends to the originator of the received
1149: message the GetResponse-PDU of identical form, except
1150: that the value of the error-status field is genErr and
1151: the value of the error-index field is the index of said
1152: object name component in the received message.
1153:
1154: If none of the foregoing rules apply, then the receiving protocol
1155: entity sends to the originator of the received message the
1156: GetResponse-PDU such that, for each object named in the variable-
1157: bindings field of the received message, the corresponding component
1158: of the GetResponse-PDU represents the name and value of that
1159: variable. The value of the error- status field of the GetResponse-
1160: PDU is noError and the value of the error-index field is zero. The
1161: value of the request-id field of the GetResponse-PDU is that of the
1162: received message.
1163:
1164: 4.1.3. The GetNextRequest-PDU
1165:
1166: The form of the GetNextRequest-PDU is identical to that of the
1167: GetRequest-PDU except for the indication of the PDU type. In the
1168: ASN.1 language:
1169:
1170: GetNextRequest-PDU ::=
1171: [1]
1172: IMPLICIT SEQUENCE {
1173: request-id
1174: RequestID,
1175:
1176:
1177:
1178: Case, Fedor, Schoffstall, & Davin [Page 21]
1179:
1180: RFC 1157 SNMP May 1990
1181:
1182:
1183: error-status -- always 0
1184: ErrorStatus,
1185:
1186: error-index -- always 0
1187: ErrorIndex,
1188:
1189: variable-bindings
1190: VarBindList
1191: }
1192:
1193:
1194: The GetNextRequest-PDU is generated by a protocol entity only at the
1195: request of its SNMP application entity.
1196:
1197: Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
1198: responds according to any applicable rule in the list below:
1199:
1200: (1) If, for any object name in the variable-bindings field,
1201: that name does not lexicographically precede the name of
1202: some object available for get operations in the relevant
1203: MIB view, then the receiving entity sends to the
1204: originator of the received message the GetResponse-PDU of
1205: identical form, except that the value of the error-status
1206: field is noSuchName, and the value of the error-index
1207: field is the index of said object name component in the
1208: received message.
1209:
1210: (2) If the size of the GetResponse-PDU generated as described
1211: below would exceed a local limitation, then the receiving
1212: entity sends to the originator of the received message
1213: the GetResponse-PDU of identical form, except that the
1214: value of the error-status field is tooBig, and the value
1215: of the error-index field is zero.
1216:
1217: (3) If, for any object named in the variable-bindings field,
1218: the value of the lexicographical successor to the named
1219: object cannot be retrieved for reasons not covered by any
1220: of the foregoing rules, then the receiving entity sends
1221: to the originator of the received message the
1222: GetResponse-PDU of identical form, except that the value
1223: of the error-status field is genErr and the value of the
1224: error-index field is the index of said object name
1225: component in the received message.
1226:
1227: If none of the foregoing rules apply, then the receiving protocol
1228: entity sends to the originator of the received message the
1229: GetResponse-PDU such that, for each name in the variable-bindings
1230: field of the received message, the corresponding component of the
1231:
1232:
1233:
1234: Case, Fedor, Schoffstall, & Davin [Page 22]
1235:
1236: RFC 1157 SNMP May 1990
1237:
1238:
1239: GetResponse-PDU represents the name and value of that object whose
1240: name is, in the lexicographical ordering of the names of all objects
1241: available for get operations in the relevant MIB view, together with
1242: the value of the name field of the given component, the immediate
1243: successor to that value. The value of the error-status field of the
1244: GetResponse-PDU is noError and the value of the errorindex field is
1245: zero. The value of the request-id field of the GetResponse-PDU is
1246: that of the received message.
1247:
1248: 4.1.3.1. Example of Table Traversal
1249:
1250: One important use of the GetNextRequest-PDU is the traversal of
1251: conceptual tables of information within the MIB. The semantics of
1252: this type of SNMP message, together with the protocol-specific
1253: mechanisms for identifying individual instances of object types in
1254: the MIB, affords access to related objects in the MIB as if they
1255: enjoyed a tabular organization.
1256:
1257: By the SNMP exchange sketched below, an SNMP application entity might
1258: extract the destination address and next hop gateway for each entry
1259: in the routing table of a particular network element. Suppose that
1260: this routing table has three entries:
1261:
1262: Destination NextHop Metric
1263:
1264: 10.0.0.99 89.1.1.42 5
1265: 9.1.2.3 99.0.0.3 3
1266: 10.0.0.51 89.1.1.42 5
1267:
1268:
1269: The management station sends to the SNMP agent a GetNextRequest-PDU
1270: containing the indicated OBJECT IDENTIFIER values as the requested
1271: variable names:
1272:
1273: GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
1274:
1275:
1276: The SNMP agent responds with a GetResponse-PDU:
1277:
1278: GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
1279: ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
1280: ( ipRouteMetric1.9.1.2.3 = 3 ))
1281:
1282:
1283: The management station continues with:
1284:
1285: GetNextRequest ( ipRouteDest.9.1.2.3,
1286: ipRouteNextHop.9.1.2.3,
1287:
1288:
1289:
1290: Case, Fedor, Schoffstall, & Davin [Page 23]
1291:
1292: RFC 1157 SNMP May 1990
1293:
1294:
1295: ipRouteMetric1.9.1.2.3 )
1296:
1297:
1298: The SNMP agent responds:
1299:
1300: GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
1301: ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
1302: ( ipRouteMetric1.10.0.0.51 = 5 ))
1303:
1304:
1305: The management station continues with:
1306:
1307: GetNextRequest ( ipRouteDest.10.0.0.51,
1308: ipRouteNextHop.10.0.0.51,
1309: ipRouteMetric1.10.0.0.51 )
1310:
1311:
1312: The SNMP agent responds:
1313:
1314: GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
1315: ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
1316: ( ipRouteMetric1.10.0.0.99 = 5 ))
1317:
1318:
1319: The management station continues with:
1320:
1321: GetNextRequest ( ipRouteDest.10.0.0.99,
1322: ipRouteNextHop.10.0.0.99,
1323: ipRouteMetric1.10.0.0.99 )
1324:
1325:
1326: As there are no further entries in the table, the SNMP agent returns
1327: those objects that are next in the lexicographical ordering of the
1328: known object names. This response signals the end of the routing
1329: table to the management station.
1330:
1331: 4.1.4. The GetResponse-PDU
1332:
1333: The form of the GetResponse-PDU is identical to that of the
1334: GetRequest-PDU except for the indication of the PDU type. In the
1335: ASN.1 language:
1336:
1337: GetResponse-PDU ::=
1338: [2]
1339: IMPLICIT SEQUENCE {
1340: request-id
1341: RequestID,
1342:
1343:
1344:
1345:
1346: Case, Fedor, Schoffstall, & Davin [Page 24]
1347:
1348: RFC 1157 SNMP May 1990
1349:
1350:
1351: error-status
1352: ErrorStatus,
1353:
1354: error-index
1355: ErrorIndex,
1356:
1357: variable-bindings
1358: VarBindList
1359: }
1360:
1361:
1362: The GetResponse-PDU is generated by a protocol entity only upon
1363: receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
1364: as described elsewhere in this document.
1365:
1366: Upon receipt of the GetResponse-PDU, the receiving protocol entity
1367: presents its contents to its SNMP application entity.
1368:
1369: 4.1.5. The SetRequest-PDU
1370:
1371: The form of the SetRequest-PDU is identical to that of the
1372: GetRequest-PDU except for the indication of the PDU type. In the
1373: ASN.1 language:
1374:
1375: SetRequest-PDU ::=
1376: [3]
1377: IMPLICIT SEQUENCE {
1378: request-id
1379: RequestID,
1380:
1381: error-status -- always 0
1382: ErrorStatus,
1383:
1384: error-index -- always 0
1385: ErrorIndex,
1386:
1387: variable-bindings
1388: VarBindList
1389: }
1390:
1391:
1392: The SetRequest-PDU is generated by a protocol entity only at the
1393: request of its SNMP application entity.
1394:
1395: Upon receipt of the SetRequest-PDU, the receiving entity responds
1396: according to any applicable rule in the list below:
1397:
1398: (1) If, for any object named in the variable-bindings field,
1399:
1400:
1401:
1402: Case, Fedor, Schoffstall, & Davin [Page 25]
1403:
1404: RFC 1157 SNMP May 1990
1405:
1406:
1407: the object is not available for set operations in the
1408: relevant MIB view, then the receiving entity sends to the
1409: originator of the received message the GetResponse-PDU of
1410: identical form, except that the value of the error-status
1411: field is noSuchName, and the value of the error-index
1412: field is the index of said object name component in the
1413: received message.
1414:
1415: (2) If, for any object named in the variable-bindings field,
1416: the contents of the value field does not, according to
1417: the ASN.1 language, manifest a type, length, and value
1418: that is consistent with that required for the variable,
1419: then the receiving entity sends to the originator of the
1420: received message the GetResponse-PDU of identical form,
1421: except that the value of the error-status field is
1422: badValue, and the value of the error-index field is the
1423: index of said object name in the received message.
1424:
1425: (3) If the size of the Get Response type message generated as
1426: described below would exceed a local limitation, then the
1427: receiving entity sends to the originator of the received
1428: message the GetResponse-PDU of identical form, except
1429: that the value of the error-status field is tooBig, and
1430: the value of the error-index field is zero.
1431:
1432: (4) If, for any object named in the variable-bindings field,
1433: the value of the named object cannot be altered for
1434: reasons not covered by any of the foregoing rules, then
1435: the receiving entity sends to the originator of the
1436: received message the GetResponse-PDU of identical form,
1437: except that the value of the error-status field is genErr
1438: and the value of the error-index field is the index of
1439: said object name component in the received message.
1440:
1441: If none of the foregoing rules apply, then for each object named in
1442: the variable-bindings field of the received message, the
1443: corresponding value is assigned to the variable. Each variable
1444: assignment specified by the SetRequest-PDU should be effected as if
1445: simultaneously set with respect to all other assignments specified in
1446: the same message.
1447:
1448: The receiving entity then sends to the originator of the received
1449: message the GetResponse-PDU of identical form except that the value
1450: of the error-status field of the generated message is noError and the
1451: value of the error-index field is zero.
1452:
1453:
1454:
1455:
1456:
1457:
1458: Case, Fedor, Schoffstall, & Davin [Page 26]
1459:
1460: RFC 1157 SNMP May 1990
1461:
1462:
1463: 4.1.6. The Trap-PDU
1464:
1465: The form of the Trap-PDU is:
1466:
1467: Trap-PDU ::=
1468: [4]
1469:
1470: IMPLICIT SEQUENCE {
1471: enterprise -- type of object generating
1472: -- trap, see sysObjectID in [5]
1473: OBJECT IDENTIFIER,
1474:
1475: agent-addr -- address of object generating
1476: NetworkAddress, -- trap
1477:
1478: generic-trap -- generic trap type
1479: INTEGER {
1480: coldStart(0),
1481: warmStart(1),
1482: linkDown(2),
1483: linkUp(3),
1484: authenticationFailure(4),
1485: egpNeighborLoss(5),
1486: enterpriseSpecific(6)
1487: },
1488:
1489: specific-trap -- specific code, present even
1490: INTEGER, -- if generic-trap is not
1491: -- enterpriseSpecific
1492:
1493: time-stamp -- time elapsed between the last
1494: TimeTicks, -- (re)initialization of the network
1495: -- entity and the generation of the
1496: trap
1497:
1498: variable-bindings -- "interesting" information
1499: VarBindList
1500: }
1501:
1502:
1503: The Trap-PDU is generated by a protocol entity only at the request of
1504: the SNMP application entity. The means by which an SNMP application
1505: entity selects the destination addresses of the SNMP application
1506: entities is implementation-specific.
1507:
1508: Upon receipt of the Trap-PDU, the receiving protocol entity presents
1509: its contents to its SNMP application entity.
1510:
1511:
1512:
1513:
1514: Case, Fedor, Schoffstall, & Davin [Page 27]
1515:
1516: RFC 1157 SNMP May 1990
1517:
1518:
1519: The significance of the variable-bindings component of the Trap-PDU
1520: is implementation-specific.
1521:
1522: Interpretations of the value of the generic-trap field are:
1523:
1524: 4.1.6.1. The coldStart Trap
1525:
1526: A coldStart(0) trap signifies that the sending protocol entity is
1527: reinitializing itself such that the agent's configuration or the
1528: protocol entity implementation may be altered.
1529:
1530: 4.1.6.2. The warmStart Trap
1531:
1532: A warmStart(1) trap signifies that the sending protocol entity is
1533: reinitializing itself such that neither the agent configuration nor
1534: the protocol entity implementation is altered.
1535:
1536: 4.1.6.3. The linkDown Trap
1537:
1538: A linkDown(2) trap signifies that the sending protocol entity
1539: recognizes a failure in one of the communication links represented in
1540: the agent's configuration.
1541:
1542: The Trap-PDU of type linkDown contains as the first element of its
1543: variable-bindings, the name and value of the ifIndex instance for the
1544: affected interface.
1545:
1546: 4.1.6.4. The linkUp Trap
1547:
1548: A linkUp(3) trap signifies that the sending protocol entity
1549: recognizes that one of the communication links represented in the
1550: agent's configuration has come up.
1551:
1552: The Trap-PDU of type linkUp contains as the first element of its
1553: variable-bindings, the name and value of the ifIndex instance for the
1554: affected interface.
1555:
1556: 4.1.6.5. The authenticationFailure Trap
1557:
1558: An authenticationFailure(4) trap signifies that the sending protocol
1559: entity is the addressee of a protocol message that is not properly
1560: authenticated. While implementations of the SNMP must be capable of
1561: generating this trap, they must also be capable of suppressing the
1562: emission of such traps via an implementation-specific mechanism.
1563:
1564: 4.1.6.6. The egpNeighborLoss Trap
1565:
1566: An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
1567:
1568:
1569:
1570: Case, Fedor, Schoffstall, & Davin [Page 28]
1571:
1572: RFC 1157 SNMP May 1990
1573:
1574:
1575: the sending protocol entity was an EGP peer has been marked down and
1576: the peer relationship no longer obtains.
1577:
1578: The Trap-PDU of type egpNeighborLoss contains as the first element of
1579: its variable-bindings, the name and value of the egpNeighAddr
1580: instance for the affected neighbor.
1581:
1582: 4.1.6.7. The enterpriseSpecific Trap
1583:
1584: A enterpriseSpecific(6) trap signifies that the sending protocol
1585: entity recognizes that some enterprise-specific event has occurred.
1586: The specific-trap field identifies the particular trap which
1587: occurred.
1588:
1589:
1590:
1591:
1592:
1593:
1594:
1595:
1596:
1597:
1598:
1599:
1600:
1601:
1602:
1603:
1604:
1605:
1606:
1607:
1608:
1609:
1610:
1611:
1612:
1613:
1614:
1615:
1616:
1617:
1618:
1619:
1620:
1621:
1622:
1623:
1624:
1625:
1626: Case, Fedor, Schoffstall, & Davin [Page 29]
1627:
1628: RFC 1157 SNMP May 1990
1629:
1630:
1631: 5. Definitions
1632:
1633: RFC1157-SNMP DEFINITIONS ::= BEGIN
1634:
1635: IMPORTS
1636: ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
1637: FROM RFC1155-SMI;
1638:
1639:
1640: -- top-level message
1641:
1642: Message ::=
1643: SEQUENCE {
1644: version -- version-1 for this RFC
1645: INTEGER {
1646: version-1(0)
1647: },
1648:
1649: community -- community name
1650: OCTET STRING,
1651:
1652: data -- e.g., PDUs if trivial
1653: ANY -- authentication is being used
1654: }
1655:
1656:
1657: -- protocol data units
1658:
1659: PDUs ::=
1660: CHOICE {
1661: get-request
1662: GetRequest-PDU,
1663:
1664: get-next-request
1665: GetNextRequest-PDU,
1666:
1667: get-response
1668: GetResponse-PDU,
1669:
1670: set-request
1671: SetRequest-PDU,
1672:
1673: trap
1674: Trap-PDU
1675: }
1676:
1677:
1678:
1679:
1680:
1681:
1682: Case, Fedor, Schoffstall, & Davin [Page 30]
1683:
1684: RFC 1157 SNMP May 1990
1685:
1686:
1687: -- PDUs
1688:
1689: GetRequest-PDU ::=
1690: [0]
1691: IMPLICIT PDU
1692:
1693: GetNextRequest-PDU ::=
1694: [1]
1695: IMPLICIT PDU
1696:
1697: GetResponse-PDU ::=
1698: [2]
1699: IMPLICIT PDU
1700:
1701: SetRequest-PDU ::=
1702: [3]
1703: IMPLICIT PDU
1704:
1705: PDU ::=
1706: SEQUENCE {
1707: request-id
1708: INTEGER,
1709:
1710: error-status -- sometimes ignored
1711: INTEGER {
1712: noError(0),
1713: tooBig(1),
1714: noSuchName(2),
1715: badValue(3),
1716: readOnly(4),
1717: genErr(5)
1718: },
1719:
1720: error-index -- sometimes ignored
1721: INTEGER,
1722:
1723: variable-bindings -- values are sometimes ignored
1724: VarBindList
1725: }
1726:
1727: Trap-PDU ::=
1728: [4]
1729: IMPLICIT SEQUENCE {
1730: enterprise -- type of object generating
1731: -- trap, see sysObjectID in [5]
1732:
1733:
1734: OBJECT IDENTIFIER,
1735:
1736:
1737:
1738: Case, Fedor, Schoffstall, & Davin [Page 31]
1739:
1740: RFC 1157 SNMP May 1990
1741:
1742:
1743: agent-addr -- address of object generating
1744: NetworkAddress, -- trap
1745:
1746: generic-trap -- generic trap type
1747: INTEGER {
1748: coldStart(0),
1749: warmStart(1),
1750: linkDown(2),
1751: linkUp(3),
1752: authenticationFailure(4),
1753: egpNeighborLoss(5),
1754: enterpriseSpecific(6)
1755: },
1756:
1757: specific-trap -- specific code, present even
1758: INTEGER, -- if generic-trap is not
1759: -- enterpriseSpecific
1760:
1761: time-stamp -- time elapsed between the last
1762: TimeTicks, -- (re)initialization of the
1763: network
1764: -- entity and the generation of the
1765: trap
1766:
1767: variable-bindings -- "interesting" information
1768: VarBindList
1769: }
1770:
1771:
1772: -- variable bindings
1773:
1774: VarBind ::=
1775: SEQUENCE {
1776: name
1777: ObjectName,
1778:
1779: value
1780: ObjectSyntax
1781: }
1782:
1783: VarBindList ::=
1784: SEQUENCE OF
1785: VarBind
1786:
1787: END
1788:
1789:
1790:
1791:
1792:
1793:
1794: Case, Fedor, Schoffstall, & Davin [Page 32]
1795:
1796: RFC 1157 SNMP May 1990
1797:
1798:
1799: 6. Acknowledgements
1800:
1801: This memo was influenced by the IETF SNMP Extensions working
1802: group:
1803:
1804: Karl Auerbach, Epilogue Technology
1805: K. Ramesh Babu, Excelan
1806: Amatzia Ben-Artzi, 3Com/Bridge
1807: Lawrence Besaw, Hewlett-Packard
1808: Jeffrey D. Case, University of Tennessee at Knoxville
1809: Anthony Chung, Sytek
1810: James Davidson, The Wollongong Group
1811: James R. Davin, MIT Laboratory for Computer Science
1812: Mark S. Fedor, NYSERNet
1813: Phill Gross, The MITRE Corporation
1814: Satish Joshi, ACC
1815: Dan Lynch, Advanced Computing Environments
1816: Keith McCloghrie, The Wollongong Group
1817: Marshall T. Rose, The Wollongong Group (chair)
1818: Greg Satz, cisco
1819: Martin Lee Schoffstall, Rensselaer Polytechnic Institute
1820: Wengyik Yeong, NYSERNet
1821:
1822:
1823:
1824:
1825:
1826:
1827:
1828:
1829:
1830:
1831:
1832:
1833:
1834:
1835:
1836:
1837:
1838:
1839:
1840:
1841:
1842:
1843:
1844:
1845:
1846:
1847:
1848:
1849:
1850: Case, Fedor, Schoffstall, & Davin [Page 33]
1851:
1852: RFC 1157 SNMP May 1990
1853:
1854:
1855: 7. References
1856:
1857: [1] Cerf, V., "IAB Recommendations for the Development of
1858: Internet Network Management Standards", RFC 1052, IAB,
1859: April 1988.
1860:
1861: [2] Rose, M., and K. McCloghrie, "Structure and Identification
1862: of Management Information for TCP/IP-based internets",
1863: RFC 1065, TWG, August 1988.
1864:
1865: [3] McCloghrie, K., and M. Rose, "Management Information Base
1866: for Network Management of TCP/IP-based internets",
1867: RFC 1066, TWG, August 1988.
1868:
1869: [4] Cerf, V., "Report of the Second Ad Hoc Network Management
1870: Review Group", RFC 1109, IAB, August 1989.
1871:
1872: [5] Rose, M., and K. McCloghrie, "Structure and Identification
1873: of Management Information for TCP/IP-based Internets",
1874: RFC 1155, Performance Systems International and Hughes LAN
1875: Systems, May 1990.
1876:
1877: [6] McCloghrie, K., and M. Rose, "Management Information Base
1878: for Network Management of TCP/IP-based Internets",
1879: RFC 1156, Hughes LAN Systems and Performance Systems
1880: International, May 1990.
1881:
1882: [7] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
1883: "A Simple Network Management Protocol", Internet
1884: Engineering Task Force working note, Network Information
1885: Center, SRI International, Menlo Park, California,
1886: March 1988.
1887:
1888: [8] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
1889: "A Simple Gateway Monitoring Protocol", RFC 1028,
1890: Proteon, University of Tennessee at Knoxville,
1891: Cornell University, and Rensselaer Polytechnic
1892: Institute, November 1987.
1893:
1894: [9] Information processing systems - Open Systems
1895: Interconnection, "Specification of Abstract Syntax
1896: Notation One (ASN.1)", International Organization for
1897: Standardization, International Standard 8824,
1898: December 1987.
1899:
1900: [10] Information processing systems - Open Systems
1901: Interconnection, "Specification of Basic Encoding Rules
1902: for Abstract Notation One (ASN.1)", International
1903:
1904:
1905:
1906: Case, Fedor, Schoffstall, & Davin [Page 34]
1907:
1908: RFC 1157 SNMP May 1990
1909:
1910:
1911: Organization for Standardization, International Standard
1912: 8825, December 1987.
1913:
1914: [11] Postel, J., "User Datagram Protocol", RFC 768,
1915: USC/Information Sciences Institute, November 1980.
1916:
1917: Security Considerations
1918:
1919: Security issues are not discussed in this memo.
1920:
1921: Authors' Addresses
1922:
1923: Jeffrey D. Case
1924: SNMP Research
1925: P.O. Box 8593
1926: Knoxville, TN 37996-4800
1927:
1928: Phone: (615) 573-1434
1929:
1930: Email: [email protected]
1931:
1932:
1933: Mark Fedor
1934: Performance Systems International
1935: Rensselaer Technology Park
1936: 125 Jordan Road
1937: Troy, NY 12180
1938:
1939: Phone: (518) 283-8860
1940:
1941: Email: [email protected]
1942:
1943:
1944: Martin Lee Schoffstall
1945: Performance Systems International
1946: Rensselaer Technology Park
1947: 165 Jordan Road
1948: Troy, NY 12180
1949:
1950: Phone: (518) 283-8860
1951:
1952: Email: [email protected]
1953:
1954:
1955:
1956:
1957:
1958:
1959:
1960:
1961:
1962: Case, Fedor, Schoffstall, & Davin [Page 35]
1963:
1964: RFC 1157 SNMP May 1990
1965:
1966:
1967: James R. Davin
1968: MIT Laboratory for Computer Science, NE43-507
1969: 545 Technology Square
1970: Cambridge, MA 02139
1971:
1972: Phone: (617) 253-6020
1973:
1974: EMail: [email protected]
1975:
1976:
1977:
1978:
1979:
1980:
1981:
1982:
1983:
1984:
1985:
1986:
1987:
1988:
1989:
1990:
1991:
1992:
1993:
1994:
1995:
1996:
1997:
1998:
1999:
2000:
2001:
2002:
2003:
2004:
2005:
2006:
2007:
2008:
2009:
2010:
2011:
2012:
2013:
2014:
2015:
2016:
2017:
2018: Case, Fedor, Schoffstall, & Davin [Page 36]
2019:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.