]> git.ipfire.org Git - thirdparty/cups.git/blame - standards/rfc1157.txt
projects / thirdparty / cups.git / blame
? search:
summary | shortlog | log | commit | commitdiff | tree
blob | blame (incremental) | history | HEAD
Load cups into easysw/current.
[thirdparty/cups.git] / standards / rfc1157.txt
CommitLineData
89d46774 1
2
3
4
5
6
7Network Working Group J. Case
8Request for Comments: 1157 SNMP Research
9Obsoletes: 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
58Case, Fedor, Schoffstall, & Davin [Page 1]
59\f
60RFC 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
721. 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
992. 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
114Case, Fedor, Schoffstall, & Davin [Page 2]
115\f
116RFC 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
170Case, Fedor, Schoffstall, & Davin [Page 3]
171\f
172RFC 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
226Case, Fedor, Schoffstall, & Davin [Page 4]
227\f
228RFC 1157 SNMP May 1990
229
230
2313. 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
2443.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
2753.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
282Case, Fedor, Schoffstall, & Davin [Page 5]
283\f
284RFC 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
3053.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
3163.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
338Case, Fedor, Schoffstall, & Davin [Page 6]
339\f
340RFC 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
3503.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
394Case, Fedor, Schoffstall, & Davin [Page 7]
395\f
396RFC 1157 SNMP May 1990
397
398
3993.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
4133.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
450Case, Fedor, Schoffstall, & Davin [Page 8]
451\f
452RFC 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
506Case, Fedor, Schoffstall, & Davin [Page 9]
507\f
508RFC 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
562Case, Fedor, Schoffstall, & Davin [Page 10]
563\f
564RFC 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
618Case, Fedor, Schoffstall, & Davin [Page 11]
619\f
620RFC 1157 SNMP May 1990
621
622
6233.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
6363.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
6453.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
6573.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
674Case, Fedor, Schoffstall, & Davin [Page 12]
675\f
676RFC 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
7023.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
7173.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
730Case, Fedor, Schoffstall, & Davin [Page 13]
731\f
732RFC 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
7453.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
7623.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
7793.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
786Case, Fedor, Schoffstall, & Davin [Page 14]
787\f
788RFC 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
8103.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
842Case, Fedor, Schoffstall, & Davin [Page 15]
843\f
844RFC 1157 SNMP May 1990
845
846
8474. 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
898Case, Fedor, Schoffstall, & Davin [Page 16]
899\f
900RFC 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
9294.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
954Case, Fedor, Schoffstall, & Davin [Page 17]
955\f
956RFC 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
1010Case, Fedor, Schoffstall, & Davin [Page 18]
1011\f
1012RFC 1157 SNMP May 1990
1013
1014
10154.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
1066Case, Fedor, Schoffstall, & Davin [Page 19]
1067\f
1068RFC 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
10854.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
1122Case, Fedor, Schoffstall, & Davin [Page 20]
1123\f
1124RFC 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
11644.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
1178Case, Fedor, Schoffstall, & Davin [Page 21]
1179\f
1180RFC 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
1234Case, Fedor, Schoffstall, & Davin [Page 22]
1235\f
1236RFC 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
12484.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
1290Case, Fedor, Schoffstall, & Davin [Page 23]
1291\f
1292RFC 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
13314.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
1346Case, Fedor, Schoffstall, & Davin [Page 24]
1347\f
1348RFC 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
13694.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
1402Case, Fedor, Schoffstall, & Davin [Page 25]
1403\f
1404RFC 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
1458Case, Fedor, Schoffstall, & Davin [Page 26]
1459\f
1460RFC 1157 SNMP May 1990
1461
1462
14634.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
1514Case, Fedor, Schoffstall, & Davin [Page 27]
1515\f
1516RFC 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
15244.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
15304.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
15364.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
15464.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
15564.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
15644.1.6.6. The egpNeighborLoss Trap
1565
1566 An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
1567
1568
1569
1570Case, Fedor, Schoffstall, & Davin [Page 28]
1571\f
1572RFC 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
15824.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
1626Case, Fedor, Schoffstall, & Davin [Page 29]
1627\f
1628RFC 1157 SNMP May 1990
1629
1630
16315. 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
1682Case, Fedor, Schoffstall, & Davin [Page 30]
1683\f
1684RFC 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
1738Case, Fedor, Schoffstall, & Davin [Page 31]
1739\f
1740RFC 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
1794Case, Fedor, Schoffstall, & Davin [Page 32]
1795\f
1796RFC 1157 SNMP May 1990
1797
1798
17996. 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
1850Case, Fedor, Schoffstall, & Davin [Page 33]
1851\f
1852RFC 1157 SNMP May 1990
1853
1854
18557. 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
1906Case, Fedor, Schoffstall, & Davin [Page 34]
1907\f
1908RFC 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
1917Security Considerations
1918
1919 Security issues are not discussed in this memo.
1920
1921Authors' 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: case@CS.UTK.EDU
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: fedor@patton.NYSER.NET
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: schoff@NISC.NYSER.NET
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962Case, Fedor, Schoffstall, & Davin [Page 35]
1963\f
1964RFC 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: jrd@ptt.lcs.mit.edu
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
2018Case, Fedor, Schoffstall, & Davin [Page 36]
2019\f
Unnamed repository; edit this file 'description' to name the repository.