123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851 |
-
-
-
-
-
-
- Network Working Group J. Case
- Request for Comments: 1067 University of Tennessee at Knoxville
- M. Fedor
- NYSERNet, Inc.
- M. Schoffstall
- Rensselaer Polytechnic Institute
- J. Davin
- Proteon, Inc.
- August 1988
-
-
- A Simple Network Management Protocol
-
- Table of Contents
-
- 1. Status of this Memo ................................... 2
- 2. Introduction .......................................... 2
- 3. The SNMP Architecture ................................. 4
- 3.1 Goals of the Architecture ............................ 4
- 3.2 Elements of the Architecture ......................... 4
- 3.2.1 Scope of Management Information .................... 5
- 3.2.2 Representation of Management Information ........... 5
- 3.2.3 Operations Supported on Management Information ..... 6
- 3.2.4 Form and Meaning of Protocol Exchanges ............. 7
- 3.2.5 Definition of Administrative Relationships ......... 7
- 3.2.6 Form and Meaning of References to Managed Objects .. 11
- 3.2.6.1 Resolution of Ambiguous MIB References ........... 11
- 3.2.6.2 Resolution of References across MIB Versions...... 11
- 3.2.6.3 Identification of Object Instances ............... 11
- 3.2.6.3.1 ifTable Object Type Names ...................... 12
- 3.2.6.3.2 atTable Object Type Names ...................... 12
- 3.2.6.3.3 ipAddrTable Object Type Names .................. 13
- 3.2.6.3.4 ipRoutingTable Object Type Names ............... 13
- 3.2.6.3.5 tcpConnTable Object Type Names ................. 13
- 3.2.6.3.6 egpNeighTable Object Type Names ................ 14
- 4. Protocol Specification ................................ 15
- 4.1 Elements of Procedure ................................ 16
- 4.1.1 Common Constructs .................................. 18
- 4.1.2 The GetRequest-PDU ................................. 19
- 4.1.3 The GetNextRequest-PDU ............................. 20
- 4.1.3.1 Example of Table Traversal ....................... 22
- 4.1.4 The GetResponse-PDU ................................ 23
- 4.1.5 The SetRequest-PDU ................................. 24
- 4.1.6 The Trap-PDU ....................................... 26
- 4.1.6.1 The coldStart Trap ............................... 27
- 4.1.6.2 The warmStart Trap ............................... 27
- 4.1.6.3 The linkDown Trap ................................ 27
- 4.1.6.4 The linkUp Trap .................................. 27
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 1]
-
- RFC 1067 SNMP August 1988
-
-
- 4.1.6.5 The authenticationFailure Trap ................... 27
- 4.1.6.6 The egpNeighborLoss Trap ......................... 27
- 4.1.6.7 The enterpriseSpecific Trap ...................... 28
- 5. Definitions ........................................... 29
- 6. Acknowledgements ...................................... 32
- 7. References ............................................ 33
-
- 1. Status of this Memo
-
- This memo defines a simple protocol by which management information
- for a network element may be inspected or altered by logically remote
- users. In particular, together with its companion memos which
- describe the structure of management information along with the
- initial management information base, these documents provide a
- simple, workable architecture and system for managing TCP/IP-based
- internets and in particular the Internet.
-
- This memo specifies a draft standard for the Internet community.
- TCP/IP implementations in the Internet which are network manageable
- are expected to adopt and implement this specification.
-
- Distribution of this memo is unlimited.
-
- 2. Introduction
-
- As reported in RFC 1052, IAB Recommendations for the Development of
- Internet Network Management Standards [1], the Internet Activities
- Board has directed the Internet Engineering Task Force (IETF) to
- create two new working groups in the area of network management. One
- group is charged with the further specification and definition of
- elements to be included in the Management Information Base (MIB).
- The other is charged with defining the modifications to the Simple
- Network Management Protocol (SNMP) to accommodate the short-term
- needs of the network vendor and operations communities, and to align
- with the output of the MIB working group.
-
- The MIB working group has produced two memos, one which defines a
- Structure for Management Information (SMI) [2] for use by the managed
- objects contained in the MIB. A second memo [3] defines the list of
- managed objects.
-
- The output of the SNMP Extensions working group is this memo, which
- incorporates changes to the initial SNMP definition [4] required to
- attain alignment with the output of the MIB working group. The
- changes should be minimal in order to be consistent with the IAB's
- directive that the working groups be "extremely sensitive to the need
- to keep the SNMP simple." Although considerable care and debate has
- gone into the changes to the SNMP which are reflected in this memo,
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 2]
-
- RFC 1067 SNMP August 1988
-
-
- the resulting protocol is not backwardly-compatible with its
- predecessor, the Simple Gateway Monitoring Protocol (SGMP) [5].
- Although the syntax of the protocol has been altered, the original
- philosophy, design decisions, and architecture remain intact. In
- order to avoid confusion, new UDP ports have been allocated for use
- by the protocol described in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 3]
-
- RFC 1067 SNMP August 1988
-
-
- 3. The SNMP Architecture
-
- Implicit in the SNMP architectural model is a collection of network
- management stations and network elements. Network management
- stations execute management applications which monitor and control
- network elements. Network elements are devices such as hosts,
- gateways, terminal servers, and the like, which have management
- agents responsible for performing the network management functions
- requested by the network management stations. The Simple Network
- Management Protocol (SNMP) is used to communicate management
- information between the network management stations and the agents in
- the network elements.
-
- 3.1. Goals of the Architecture
-
- The SNMP explicitly minimizes the number and complexity of management
- functions realized by the management agent itself. This goal is
- attractive in at least four respects:
-
- (1) The development cost for management agent software
- necessary to support the protocol is accordingly reduced.
-
- (2) The degree of management function that is remotely
- supported is accordingly increased, thereby admitting
- fullest use of internet resources in the management task.
-
- (3) The degree of management function that is remotely
- supported is accordingly increased, thereby imposing the
- fewest possible restrictions on the form and
- sophistication of management tools.
-
- (4) Simplified sets of management functions are easily
- understood and used by developers of network management
- tools.
-
- A second goal of the protocol is that the functional paradigm for
- monitoring and control be sufficiently extensible to accommodate
- additional, possibly unanticipated aspects of network operation and
- management.
-
- A third goal is that the architecture be, as much as possible,
- independent of the architecture and mechanisms of particular hosts or
- particular gateways.
-
- 3.2. Elements of the Architecture
-
- The SNMP architecture articulates a solution to the network
- management problem in terms of:
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 4]
-
- RFC 1067 SNMP August 1988
-
-
- (1) the scope of the management information communicated by
- the protocol,
-
- (2) the representation of the management information
- communicated by the protocol,
-
- (3) operations on management information supported by the
- protocol,
-
- (4) the form and meaning of exchanges among management
- entities,
-
- (5) the definition of administrative relationships among
- management entities, and
-
- (6) the form and meaning of references to management
- information.
-
- 3.2.1. Scope of Management Information
-
- The scope of the management information communicated by operation of
- the SNMP is exactly that represented by instances of all non-
- aggregate object types either defined in Internet-standard MIB or
- defined elsewhere according to the conventions set forth in
- Internet-standard SMI [2].
-
- Support for aggregate object types in the MIB is neither required for
- conformance with the SMI nor realized by the SNMP.
-
- 3.2.2. Representation of Management Information
-
- Management information communicated by operation of the SNMP is
- represented according to the subset of the ASN.1 language [6] that is
- specified for the definition of non-aggregate types in the SMI.
-
- The SGMP adopted the convention of using a well-defined subset of the
- ASN.1 language [6]. The SNMP continues and extends this tradition by
- utilizing a moderately more complex subset of ASN.1 for describing
- managed objects and for describing the protocol data units used for
- managing those objects. In addition, the desire to ease eventual
- transition to OSI-based network management protocols led to the
- definition in the ASN.1 language of an Internet-standard Structure of
- Management Information (SMI) [2] and Management Information Base
- (MIB) [3]. The use of the ASN.1 language, was, in part, encouraged
- by the successful use of ASN.1 in earlier efforts, in particular, the
- SGMP. The restrictions on the use of ASN.1 that are part of the SMI
- contribute to the simplicity espoused and validated by experience
- with the SGMP.
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 5]
-
- RFC 1067 SNMP August 1988
-
-
- Also for the sake of simplicity, the SNMP uses only a subset of the
- basic encoding rules of ASN.1 [7]. Namely, all encodings use the
- definite-length form. Further, whenever permissible, non-constructor
- encodings are used rather than constructor encodings. This
- restriction applies to all aspects of ASN.1 encoding, both for the
- top-level protocol data units and the data objects they contain.
-
- 3.2.3. Operations Supported on Management Information
-
- The SNMP models all management agent functions as alterations or
- inspections of variables. Thus, a protocol entity on a logically
- remote host (possibly the network element itself) interacts with the
- management agent resident on the network element in order to retrieve
- (get) or alter (set) variables. This strategy has at least two
- positive consequences:
-
- (1) It has the effect of limiting the number of essential
- management functions realized by the management agent to
- two: one operation to assign a value to a specified
- configuration or other parameter and another to retrieve
- such a value.
-
- (2) A second effect of this decision is to avoid introducing
- into the protocol definition support for imperative
- management commands: the number of such commands is in
- practice ever-increasing, and the semantics of such
- commands are in general arbitrarily complex.
-
- The strategy implicit in the SNMP is that the monitoring of network
- state at any significant level of detail is accomplished primarily by
- polling for appropriate information on the part of the monitoring
- center(s). A limited number of unsolicited messages (traps) guide
- the timing and focus of the polling. Limiting the number of
- unsolicited messages is consistent with the goal of simplicity and
- minimizing the amount of traffic generated by the network management
- function.
-
- The exclusion of imperative commands from the set of explicitly
- supported management functions is unlikely to preclude any desirable
- management agent operation. Currently, most commands are requests
- either to set the value of some parameter or to retrieve such a
- value, and the function of the few imperative commands currently
- supported is easily accommodated in an asynchronous mode by this
- management model. In this scheme, an imperative command might be
- realized as the setting of a parameter value that subsequently
- triggers the desired action. For example, rather than implementing a
- "reboot command," this action might be invoked by simply setting a
- parameter indicating the number of seconds until system reboot.
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 6]
-
- RFC 1067 SNMP August 1988
-
-
- 3.2.4. Form and Meaning of Protocol Exchanges
-
- The communication of management information among management entities
- is realized in the SNMP through the exchange of protocol messages.
- The form and meaning of those messages is defined below in Section 4.
-
- Consistent with the goal of minimizing complexity of the management
- agent, the exchange of SNMP messages requires only an unreliable
- datagram service, and every message is entirely and independently
- represented by a single transport datagram. While this document
- specifies the exchange of messages via the UDP protocol [8], the
- mechanisms of the SNMP are generally suitable for use with a wide
- variety of transport services.
-
- 3.2.5. Definition of Administrative Relationships
-
- The SNMP architecture admits a variety of administrative
- relationships among entities that participate in the protocol. The
- entities residing at management stations and network elements which
- communicate with one another using the SNMP are termed SNMP
- application entities. The peer processes which implement the SNMP,
- and thus support the SNMP application entities, are termed protocol
- entities.
-
- A pairing of an SNMP agent with some arbitrary set of SNMP
- application entities is called an SNMP community. Each SNMP
- community is named by a string of octets, that is called the
- community name for said community.
-
- An SNMP message originated by an SNMP application entity that in fact
- belongs to the SNMP community named by the community component of
- said message is called an authentic SNMP message. The set of rules
- by which an SNMP message is identified as an authentic SNMP message
- for a particular SNMP community is called an authentication scheme.
- An implementation of a function that identifies authentic SNMP
- messages according to one or more authentication schemes is called an
- authentication service.
-
- Clearly, effective management of administrative relationships among
- SNMP application entities requires authentication services that (by
- the use of encryption or other techniques) are able to identify
- authentic SNMP messages with a high degree of certainty. Some SNMP
- implementations may wish to support only a trivial authentication
- service that identifies all SNMP messages as authentic SNMP messages.
-
- For any network element, a subset of objects in the MIB that pertain
- to that element is called a SNMP MIB view. Note that the names of
- the object types represented in a SNMP MIB view need not belong to a
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 7]
-
- RFC 1067 SNMP August 1988
-
-
- single sub-tree of the object type name space.
-
- An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
- access mode.
-
- A pairing of a SNMP access mode with a SNMP MIB view is called an
- SNMP community profile. A SNMP community profile represents
- specified access privileges to variables in a specified MIB view. For
- every variable in the MIB view in a given SNMP community profile,
- access to that variable is represented by the profile according to
- the following conventions:
-
- (1) if said variable is defined in the MIB with "Access:" of
- "none," it is unavailable as an operand for any operator;
-
- (2) if said variable is defined in the MIB with "Access:" of
- "read-write" or "write-only" and the access mode of the
- given profile is READ-WRITE, that variable is available
- as an operand for the get, set, and trap operations;
-
- (3) otherwise, the variable is available as an operand for
- the get and trap operations.
-
- (4) In those cases where a "write-only" variable is an
- operand used for the get or trap operations, the value
- given for the variable is implementation-specific.
-
- A pairing of a SNMP community with a SNMP community profile is called
- a SNMP access policy. An access policy represents a specified
- community profile afforded by the SNMP agent of a specified SNMP
- community to other members of that community. All administrative
- relationships among SNMP application entities are architecturally
- defined in terms of SNMP access policies.
-
- For every SNMP access policy, if the network element on which the
- SNMP agent for the specified SNMP community resides is not that to
- which the MIB view for the specified profile pertains, then that
- policy is called a SNMP proxy access policy. The SNMP agent
- associated with a proxy access policy is called a SNMP proxy agent.
- While careless definition of proxy access policies can result in
- management loops, prudent definition of proxy policies is useful in
- at least two ways:
-
- (1) It permits the monitoring and control of network elements
- which are otherwise not addressable using the management
- protocol and the transport protocol. That is, a proxy
- agent may provide a protocol conversion function allowing
- a management station to apply a consistent management
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 8]
-
- RFC 1067 SNMP August 1988
-
-
- framework to all network elements, including devices such
- as modems, multiplexors, and other devices which support
- different management frameworks.
-
- (2) It potentially shields network elements from elaborate
- access control policies. For example, a proxy agent may
- implement sophisticated access control whereby diverse
- subsets of variables within the MIB are made accessible
- to different management stations without increasing the
- complexity of the network element.
-
- By way of example, Figure 1 illustrates the relationship between
- management stations, proxy agents, and management agents. In this
- example, the proxy agent is envisioned to be a normal Internet
- Network Operations Center (INOC) of some administrative domain which
- has a standard managerial relationship with a set of management
- agents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 9]
-
- RFC 1067 SNMP August 1988
-
-
- +------------------+ +----------------+ +----------------+
- | Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
- | | | | | |
- |Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
- |CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
- |PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
- | | | | | |
- +------------------+ +----------------+ +----------------+
- /|\ /|\ /|\
- | | |
- | | |
- | \|/ |
- | +-----------------+ |
- +-------------->| Region #3 INOC |<-------------+
- | |
- |Domain=Region #3 |
- |CPU=super-mini-2 |
- |PCommunity=pub, |
- | slate |
- |DCommunity=secret|
- +-------------->| |<-------------+
- | +-----------------+ |
- | /|\ |
- | | |
- | | |
- \|/ \|/ \|/
- +-----------------+ +-----------------+ +-----------------+
- |Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
- |CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
- |DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
- +-----------------+ +-----------------+ +-----------------+
-
-
- Domain: the administrative domain of the element
- PCommunity: the name of a community utilizing a proxy agent
- DCommunity: the name of a direct community
-
-
- Figure 1
- Example Network Management Configuration
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 10]
-
- RFC 1067 SNMP August 1988
-
-
- 3.2.6. Form and Meaning of References to Managed Objects
-
- The SMI requires that the definition of a conformant management
- protocol address:
-
- (1) the resolution of ambiguous MIB references,
-
- (2) the resolution of MIB references in the presence multiple
- MIB versions, and
-
- (3) the identification of particular instances of object
- types defined in the MIB.
-
- 3.2.6.1. Resolution of Ambiguous MIB References
-
- Because the scope of any SNMP operation is conceptually confined to
- objects relevant to a single network element, and because all SNMP
- references to MIB objects are (implicitly or explicitly) by unique
- variable names, there is no possibility that any SNMP reference to
- any object type defined in the MIB could resolve to multiple
- instances of that type.
-
- 3.2.6.2. Resolution of References across MIB Versions
-
- The object instance referred to by any SNMP operation is exactly that
- specified as part of the operation request or (in the case of a get-
- next operation) its immediate successor in the MIB as a whole. In
- particular, a reference to an object as part of some version of the
- Internet-standard MIB does not resolve to any object that is not part
- of said version of the Internet-standard MIB, except in the case that
- the requested operation is get-next and the specified object name is
- lexicographically last among the names of all objects presented as
- part of said version of the Internet-Standard MIB.
-
- 3.2.6.3. Identification of Object Instances
-
- The names for all object types in the MIB are defined explicitly
- either in the Internet-standard MIB or in other documents which
- conform to the naming conventions of the SMI. The SMI requires that
- conformant management protocols define mechanisms for identifying
- individual instances of those object types for a particular network
- element.
-
- Each instance of any object type defined in the MIB is identified in
- SNMP operations by a unique name called its "variable name." In
- general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
- form x.y, where x is the name of a non-aggregate object type defined
- in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 11]
-
- RFC 1067 SNMP August 1988
-
-
- specific to the named object type, identifies the desired instance.
-
- This naming strategy admits the fullest exploitation of the semantics
- of the GetNextRequest-PDU (see Section 4), because it assigns names
- for related variables so as to be contiguous in the lexicographical
- ordering of all variable names known in the MIB.
-
- The type-specific naming of object instances is defined below for a
- number of classes of object types. Instances of an object type to
- which none of the following naming conventions are applicable are
- named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
- said object type in the MIB definition.
-
- For example, suppose one wanted to identify an instance of the
- variable sysDescr The object class for sysDescr is:
-
- iso org dod internet mgmt mib system sysDescr
- 1 3 6 1 2 1 1 1
-
- Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
- appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0
- identifies the one and only instance of sysDescr.
-
- 3.2.6.3.1. ifTable Object Type Names
-
- The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
- the form i, where i has the value of that instance of the ifIndex
- object type associated with s.
-
- For each object type, t, for which the defined name, n, has a prefix
- of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
- the form n.s, where s is the name of the subnet interface about which
- i represents information.
-
- For example, suppose one wanted to identify the instance of the
- variable ifType associated with interface 2. Accordingly, ifType.2
- would identify the desired instance.
-
- 3.2.6.3.2. atTable Object Type Names
-
- The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
- of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
- "dot" notation) of the atNetAddress object type associated with x.
-
- The name of an address translation equivalence e is an OBJECT
- IDENTIFIER value of the form s.w, such that s is the value of that
- instance of the atIndex object type associated with e and such that w
- is the name of the AT-cached network address associated with e.
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 12]
-
- RFC 1067 SNMP August 1988
-
-
- For each object type, t, for which the defined name, n, has a prefix
- of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
- the form n.y, where y is the name of the address translation
- equivalence about which i represents information.
-
- For example, suppose one wanted to find the physical address of an
- entry in the address translation table (ARP cache) associated with an
- IP address of 89.1.1.42 and interface 3. Accordingly,
- atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
-
- 3.2.6.3.3. ipAddrTable Object Type Names
-
- The name of an IP-addressable network element, x, is the OBJECT
- IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
- familiar "dot" notation) of that instance of the ipAdEntAddr object
- type associated with x.
-
- For each object type, t, for which the defined name, n, has a prefix
- of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
- of the form n.y, where y is the name of the IP-addressable network
- element about which i represents information.
-
- For example, suppose one wanted to find the network mask of an entry
- in the IP interface table associated with an IP address of 89.1.1.42.
- Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
- instance.
-
- 3.2.6.3.4. ipRoutingTable Object Type Names
-
- The name of an IP route, x, is the OBJECT IDENTIFIER of the form
- a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
- notation) of that instance of the ipRouteDest object type associated
- with x.
-
- For each object type, t, for which the defined name, n, has a prefix
- of ipRoutingEntry, an instance, i, of t is named by an OBJECT
- IDENTIFIER of the form n.y, where y is the name of the IP route about
- which i represents information.
-
- For example, suppose one wanted to find the next hop of an entry in
- the IP routing table associated with the destination of 89.1.1.42.
- Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
- instance.
-
- 3.2.6.3.5. tcpConnTable Object Type Names
-
- The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
- a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 13]
-
- RFC 1067 SNMP August 1988
-
-
- "dot" notation) of that instance of the tcpConnLocalAddress object
- type associated with x and such that f.g.h.i is the value (in the
- familiar "dot" notation) of that instance of the tcpConnRemoteAddress
- object type associated with x and such that e is the value of that
- instance of the tcpConnLocalPort object type associated with x and
- such that j is the value of that instance of the tcpConnRemotePort
- object type associated with x.
-
- For each object type, t, for which the defined name, n, has a prefix
- of tcpConnEntry, an instance, i, of t is named by an OBJECT
- IDENTIFIER of the form n.y, where y is the name of the TCP connection
- about which i represents information.
-
- For example, suppose one wanted to find the state of a TCP connection
- between the local address of 89.1.1.42 on TCP port 21 and the remote
- address of 10.0.0.51 on TCP port 2059. Accordingly,
- tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
- instance.
-
- 3.2.6.3.6. egpNeighTable Object Type Names
-
- The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
- a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
- notation) of that instance of the egpNeighAddr object type associated
- with x.
-
- For each object type, t, for which the defined name, n, has a prefix
- of egpNeighEntry, an instance, i, of t is named by an OBJECT
- IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
- about which i represents information.
-
- For example, suppose one wanted to find the neighbor state for the IP
- address of 89.1.1.42. Accordingly, egpNeighState.89.1.1.42 would
- identify the desired instance.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 14]
-
- RFC 1067 SNMP August 1988
-
-
- 4. Protocol Specification
-
- The network management protocol is an application protocol by which
- the variables of an agent's MIB may be inspected or altered.
-
- Communication among protocol entities is accomplished by the exchange
- of messages, each of which is entirely and independently represented
- within a single UDP datagram using the basic encoding rules of ASN.1
- (as discussed in Section 3.2.2). A message consists of a version
- identifier, an SNMP community name, and a protocol data unit (PDU).
- A protocol entity receives messages at UDP port 161 on the host with
- which it is associated for all messages except for those which report
- traps (i.e., all messages except those which contain the Trap-PDU).
- Messages which report traps should be received on UDP port 162 for
- further processing. An implementation of this protocol need not
- accept messages whose length exceeds 484 octets. However, it is
- recommended that implementations support larger datagrams whenever
- feasible.
-
- It is mandatory that all implementations of the SNMP support the five
- PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
- SetRequest-PDU, and Trap-PDU.
-
- RFC1067-SNMP DEFINITIONS ::= BEGIN
-
- IMPORTS
- ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
- FROM RFC1065-SMI;
-
-
- -- top-level message
-
- Message ::=
- SEQUENCE {
- version -- version-1 for this RFC
- INTEGER {
- version-1(0)
- },
-
- community -- community name
- OCTET STRING,
-
- data -- e.g., PDUs if trivial
- ANY -- authentication is being used
- }
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 15]
-
- RFC 1067 SNMP August 1988
-
-
- -- protocol data units
-
- PDUs ::=
- CHOICE {
- get-request
- GetRequest-PDU,
-
- get-next-request
- GetNextRequest-PDU,
-
- get-response
- GetResponse-PDU,
-
- set-request
- SetRequest-PDU,
-
- trap
- Trap-PDU
- }
-
- -- the individual PDUs and commonly used
- -- data types will be defined later
-
- END
-
-
- 4.1. Elements of Procedure
-
- This section describes the actions of a protocol entity implementing
- the SNMP. Note, however, that it is not intended to constrain the
- internal architecture of any conformant implementation.
-
- In the text that follows, the term transport address is used. In the
- case of the UDP, a transport address consists of an IP address along
- with a UDP port. Other transport services may be used to support the
- SNMP. In these cases, the definition of a transport address should
- be made accordingly.
-
- The top-level actions of a protocol entity which generates a message
- are as follows:
-
- (1) It first constructs the appropriate PDU, e.g., the
- GetRequest-PDU, as an ASN.1 object.
-
- (2) It then passes this ASN.1 object along with a community
- name its source transport address and the destination
- transport address, to the service which implements the
- desired authentication scheme. This authentication
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 16]
-
- RFC 1067 SNMP August 1988
-
-
- service returns another ASN.1 object.
-
- (3) The protocol entity then constructs an ASN.1 Message
- object, using the community name and the resulting ASN.1
- object.
-
- (4) This new ASN.1 object is then serialized, using the basic
- encoding rules of ASN.1, and then sent using a transport
- service to the peer protocol entity.
-
- Similarly, the top-level actions of a protocol entity which receives
- a message are as follows:
-
- (1) It performs a rudimentary parse of the incoming datagram
- to build an ASN.1 object corresponding to an ASN.1
- Message object. If the parse fails, it discards the
- datagram and performs no further actions.
-
- (2) It then verifies the version number of the SNMP message.
- If there is a mismatch, it discards the datagram and
- performs no further actions.
-
- (3) The protocol entity then passes the community name and
- user data found in the ASN.1 Message object, along with
- the datagram's source and destination transport addresses
- to the service which implements the desired
- authentication scheme. This entity returns another ASN.1
- object, or signals an authentication failure. In the
- latter case, the protocol entity notes this failure,
- (possibly) generates a trap, and discards the datagram
- and performs no further actions.
-
- (4) The protocol entity then performs a rudimentary parse on
- the ASN.1 object returned from the authentication service
- to build an ASN.1 object corresponding to an ASN.1 PDUs
- object. If the parse fails, it discards the datagram and
- performs no further actions. Otherwise, using the named
- SNMP community, the appropriate profile is selected, and
- the PDU is processed accordingly. If, as a result of
- this processing, a message is returned then the source
- transport address that the response message is sent from
- shall be identical to the destination transport address
- that the original request message was sent to.
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 17]
-
- RFC 1067 SNMP August 1988
-
-
- 4.1.1. Common Constructs
-
- Before introducing the six PDU types of the protocol, it is
- appropriate to consider some of the ASN.1 constructs used frequently:
-
- -- request/response information
-
- RequestID ::=
- INTEGER
-
- ErrorStatus ::=
- INTEGER {
- noError(0),
- tooBig(1),
- noSuchName(2),
- badValue(3),
- readOnly(4)
- genErr(5)
- }
-
- ErrorIndex ::=
- INTEGER
-
-
- -- variable bindings
-
- VarBind ::=
- SEQUENCE {
- name
- ObjectName,
-
- value
- ObjectSyntax
- }
-
- VarBindList ::=
- SEQUENCE OF
- VarBind
-
-
- RequestIDs are used to distinguish among outstanding requests. By
- use of the RequestID, an SNMP application entity can correlate
- incoming responses with outstanding requests. In cases where an
- unreliable datagram service is being used, the RequestID also
- provides a simple means of identifying messages duplicated by the
- network.
-
- A non-zero instance of ErrorStatus is used to indicate that an
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 18]
-
- RFC 1067 SNMP August 1988
-
-
- exception occurred while processing a request. In these cases,
- ErrorIndex may provide additional information by indicating which
- variable in a list caused the exception.
-
- The term variable refers to an instance of a managed object. A
- variable binding, or VarBind, refers to the pairing of the name of a
- variable to the variable's value. A VarBindList is a simple list of
- variable names and corresponding values. Some PDUs are concerned
- only with the name of a variable and not its value (e.g., the
- GetRequest-PDU). In this case, the value portion of the binding is
- ignored by the protocol entity. However, the value portion must
- still have valid ASN.1 syntax and encoding. It is recommended that
- the ASN.1 value NULL be used for the value portion of such bindings.
-
- 4.1.2. The GetRequest-PDU
-
- The form of the GetRequest-PDU is:
- GetRequest-PDU ::=
- [0]
- IMPLICIT SEQUENCE {
- request-id
- RequestID,
-
- error-status -- always 0
- ErrorStatus,
-
- error-index -- always 0
- ErrorIndex,
-
- variable-bindings
- VarBindList
- }
-
-
- The GetRequest-PDU is generated by a protocol entity only at the
- request of its SNMP application entity.
-
- Upon receipt of the GetRequest-PDU, the receiving protocol entity
- responds according to any applicable rule in the list below:
-
- (1) If, for any object named in the variable-bindings field,
- the object's name does not exactly match the name of some
- object available for get operations in the relevant MIB
- view, then the receiving entity sends to the originator
- of the received message the GetResponse-PDU of identical
- form, except that the value of the error-status field is
- noSuchName, and the value of the error-index field is the
- index of said object name component in the received
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 19]
-
- RFC 1067 SNMP August 1988
-
-
- message.
-
- (2) If, for any object named in the variable-bindings field,
- the object is an aggregate type (as defined in the SMI),
- then the receiving entity sends to the originator of the
- received message the GetResponse-PDU of identical form,
- except that the value of the error-status field is
- noSuchName, and the value of the error-index field is the
- index of said object name component in the received
- message.
-
- (3) If the size of the GetResponse-PDU generated as described
- below would exceed a local limitation, then the receiving
- entity sends to the originator of the received message
- the GetResponse-PDU of identical form, except that the
- value of the error-status field is tooBig, and the value
- of the error-index field is zero.
-
- (4) If, for any object named in the variable-bindings field,
- the value of the object cannot be retrieved for reasons
- not covered by any of the foregoing rules, then the
- receiving entity sends to the originator of the received
- message the GetResponse-PDU of identical form, except
- that the value of the error-status field is genErr and
- the value of the error-index field is the index of said
- object name component in the received message.
-
- If none of the foregoing rules apply, then the receiving protocol
- entity sends to the originator of the received message the
- GetResponse-PDU such that, for each object named in the variable-
- bindings field of the received message, the corresponding component
- of the GetResponse-PDU represents the name and value of that
- variable. The value of the error- status field of the GetResponse-
- PDU is noError and the value of the error-index field is zero. The
- value of the request-id field of the GetResponse-PDU is that of the
- received message.
-
- 4.1.3. The GetNextRequest-PDU
-
- The form of the GetNextRequest-PDU is identical to that of the
- GetRequest-PDU except for the indication of the PDU type. In the
- ASN.1 language:
-
- GetNextRequest-PDU ::=
- [1]
- IMPLICIT SEQUENCE {
- request-id
- RequestID,
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 20]
-
- RFC 1067 SNMP August 1988
-
-
- error-status -- always 0
- ErrorStatus,
-
- error-index -- always 0
- ErrorIndex,
-
- variable-bindings
- VarBindList
- }
-
-
- The GetNextRequest-PDU is generated by a protocol entity only at the
- request of its SNMP application entity.
-
- Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
- responds according to any applicable rule in the list below:
-
- (1) If, for any object name in the variable-bindings field,
- that name does not lexicographically precede the name of
- some object available for get operations in the relevant
- MIB view, then the receiving entity sends to the
- originator of the received message the GetResponse-PDU of
- identical form, except that the value of the error-status
- field is noSuchName, and the value of the error-index
- field is the index of said object name component in the
- received message.
-
- (2) If the size of the GetResponse-PDU generated as described
- below would exceed a local limitation, then the receiving
- entity sends to the originator of the received message
- the GetResponse-PDU of identical form, except that the
- value of the error-status field is tooBig, and the value
- of the error-index field is zero.
-
- (3) If, for any object named in the variable-bindings field,
- the value of the lexicographical successor to the named
- object cannot be retrieved for reasons not covered by any
- of the foregoing rules, then the receiving entity sends
- to the originator of the received message the
- GetResponse-PDU of identical form, except that the value
- of the error-status field is genErr and the value of the
- error-index field is the index of said object name
- component in the received message.
-
- If none of the foregoing rules apply, then the receiving protocol
- entity sends to the originator of the received message the
- GetResponse-PDU such that, for each name in the variable-bindings
- field of the received message, the corresponding component of the
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 21]
-
- RFC 1067 SNMP August 1988
-
-
- GetResponse-PDU represents the name and value of that object whose
- name is, in the lexicographical ordering of the names of all objects
- available for get operations in the relevant MIB view, together with
- the value of the name field of the given component, the immediate
- successor to that value. The value of the error-status field of the
- GetResponse-PDU is noError and the value of the errorindex field is
- zero. The value of the request-id field of the GetResponse-PDU is
- that of the received message.
-
- 4.1.3.1. Example of Table Traversal
-
- One important use of the GetNextRequest-PDU is the traversal of
- conceptual tables of information within the MIB. The semantics of
- this type of SNMP message, together with the protocol-specific
- mechanisms for identifying individual instances of object types in
- the MIB, affords access to related objects in the MIB as if they
- enjoyed a tabular organization.
-
- By the SNMP exchange sketched below, an SNMP application entity might
- extract the destination address and next hop gateway for each entry
- in the routing table of a particular network element. Suppose that
- this routing table has three entries:
-
- Destination NextHop Metric
-
- 10.0.0.99 89.1.1.42 5
- 9.1.2.3 99.0.0.3 3
- 10.0.0.51 89.1.1.42 5
-
-
- The management station sends to the SNMP agent a GetNextRequest-PDU
- containing the indicated OBJECT IDENTIFIER values as the requested
- variable names:
-
- GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
-
-
- The SNMP agent responds with a GetResponse-PDU:
-
- GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
- ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
- ( ipRouteMetric1.9.1.2.3 = 3 ))
-
-
- The management station continues with:
-
- GetNextRequest ( ipRouteDest.9.1.2.3,
- ipRouteNextHop.9.1.2.3,
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 22]
-
- RFC 1067 SNMP August 1988
-
-
- ipRouteMetric1.9.1.2.3 )
-
-
- The SNMP agent responds:
-
- GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
- ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
- ( ipRouteMetric1.10.0.0.51 = 5 ))
-
-
- The management station continues with:
-
- GetNextRequest ( ipRouteDest.10.0.0.51,
- ipRouteNextHop.10.0.0.51,
- ipRouteMetric1.10.0.0.51 )
-
-
- The SNMP agent responds:
-
- GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
- ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
- ( ipRouteMetric1.10.0.0.99 = 5 ))
-
-
- The management station continues with:
-
- GetNextRequest ( ipRouteDest.10.0.0.99,
- ipRouteNextHop.10.0.0.99,
- ipRouteMetric1.10.0.0.99 )
-
-
- As there are no further entries in the table, the SNMP agent returns
- those objects that are next in the lexicographical ordering of the
- known object names. This response signals the end of the routing
- table to the management station.
-
- 4.1.4. The GetResponse-PDU
-
- The form of the GetResponse-PDU is identical to that of the
- GetRequest-PDU except for the indication of the PDU type. In the
- ASN.1 language:
-
- GetResponse-PDU ::=
- [2]
- IMPLICIT SEQUENCE {
- request-id
- RequestID,
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 23]
-
- RFC 1067 SNMP August 1988
-
-
- error-status
- ErrorStatus,
-
- error-index
- ErrorIndex,
-
- variable-bindings
- VarBindList
- }
-
-
- The GetResponse-PDU is generated by a protocol entity only upon
- receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
- as described elsewhere in this document.
-
- Upon receipt of the GetResponse-PDU, the receiving protocol entity
- presents its contents to its SNMP application entity.
-
- 4.1.5. The SetRequest-PDU
-
- The form of the SetRequest-PDU is identical to that of the
- GetRequest-PDU except for the indication of the PDU type. In the
- ASN.1 language:
-
- SetRequest-PDU ::=
- [3]
- IMPLICIT SEQUENCE {
- request-id
- RequestID,
-
- error-status -- always 0
- ErrorStatus,
-
- error-index -- always 0
- ErrorIndex,
-
- variable-bindings
- VarBindList
- }
-
-
- The SetRequest-PDU is generated by a protocol entity only at the
- request of its SNMP application entity.
-
- Upon receipt of the SetRequest-PDU, the receiving entity responds
- according to any applicable rule in the list below:
-
- (1) If, for any object named in the variable-bindings field,
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 24]
-
- RFC 1067 SNMP August 1988
-
-
- the object is not available for set operations in the
- relevant MIB view, then the receiving entity sends to the
- originator of the received message the GetResponse-PDU of
- identical form, except that the value of the error-status
- field is noSuchName, and the value of the error-index
- field is the index of said object name component in the
- received message.
-
- (2) If, for any object named in the variable-bindings field,
- the contents of the value field does not, according to
- the ASN.1 language, manifest a type, length, and value
- that is consistent with that required for the variable,
- then the receiving entity sends to the originator of the
- received message the GetResponse-PDU of identical form,
- except that the value of the error-status field is
- badValue, and the value of the error-index field is the
- index of said object name in the received message.
-
- (3) If the size of the Get Response type message generated as
- described below would exceed a local limitation, then the
- receiving entity sends to the originator of the received
- message the GetResponse-PDU of identical form, except
- that the value of the error-status field is tooBig, and
- the value of the error-index field is zero.
-
- (4) If, for any object named in the variable-bindings field,
- the value of the named object cannot be altered for
- reasons not covered by any of the foregoing rules, then
- the receiving entity sends to the originator of the
- received message the GetResponse-PDU of identical form,
- except that the value of the error-status field is genErr
- and the value of the error-index field is the index of
- said object name component in the received message.
-
- If none of the foregoing rules apply, then for each object named in
- the variable-bindings field of the received message, the
- corresponding value is assigned to the variable. Each variable
- assignment specified by the SetRequest-PDU should be effected as if
- simultaneously set with respect to all other assignments specified in
- the same message.
-
- The receiving entity then sends to the originator of the received
- message the GetResponse-PDU of identical form except that the value
- of the error-status field of the generated message is noError and the
- value of the error-index field is zero.
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 25]
-
- RFC 1067 SNMP August 1988
-
-
- 4.1.6. The Trap-PDU
-
- The form of the Trap-PDU is:
-
- Trap-PDU ::=
- [4]
-
- IMPLICIT SEQUENCE {
- enterprise -- type of object generating
- -- trap, see sysObjectID in [2]
- OBJECT IDENTIFIER,
-
- agent-addr -- address of object generating
- NetworkAddress, -- trap
-
- generic-trap -- generic trap type
- INTEGER {
- coldStart(0),
- warmStart(1),
- linkDown(2),
- linkUp(3),
- authenticationFailure(4),
- egpNeighborLoss(5),
- enterpriseSpecific(6)
- },
-
- specific-trap -- specific code, present even
- INTEGER, -- if generic-trap is not
- -- enterpriseSpecific
-
- time-stamp -- time elapsed between the last
- TimeTicks, -- (re)initialization of the network
- -- entity and the generation of the
- trap
-
- variable-bindings -- "interesting" information
- VarBindList
- }
-
-
- The Trap-PDU is generated by a protocol entity only at the request of
- the SNMP application entity. The means by which an SNMP application
- entity selects the destination addresses of the SNMP application
- entities is implementation-specific.
-
- Upon receipt of the Trap-PDU, the receiving protocol entity presents
- its contents to its SNMP application entity.
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 26]
-
- RFC 1067 SNMP August 1988
-
-
- The significance of the variable-bindings component of the Trap-PDU
- is implementation-specific.
-
- Interpretations of the value of the generic-trap field are:
-
- 4.1.6.1. The coldStart Trap
-
- A coldStart(0) trap signifies that the sending protocol entity is
- reinitializing itself such that the agent's configuration or the
- protocol entity implementation may be altered.
-
- 4.1.6.2. The warmStart Trap
-
- A warmStart(1) trap signifies that the sending protocol entity is
- reinitializing itself such that neither the agent configuration nor
- the protocol entity implementation is altered.
-
- 4.1.6.3. The linkDown Trap
-
- A linkDown(2) trap signifies that the sending protocol entity
- recognizes a failure in one of the communication links represented in
- the agent's configuration.
-
- The Trap-PDU of type linkDown contains as the first element of its
- variable-bindings, the name and value of the ifIndex instance for the
- affected interface.
-
- 4.1.6.4. The linkUp Trap
-
- A linkUp(3) trap signifies that the sending protocol entity
- recognizes that one of the communication links represented in the
- agent's configuration has come up.
-
- The Trap-PDU of type linkUp contains as the first element of its
- variable-bindings, the name and value of the ifIndex instance for the
- affected interface.
-
- 4.1.6.5. The authenticationFailure Trap
-
- An authenticationFailure(4) trap signifies that the sending protocol
- entity is the addressee of a protocol message that is not properly
- authenticated. While implementations of the SNMP must be capable of
- generating this trap, they must also be capable of suppressing the
- emission of such traps via an implementation-specific mechanism.
-
- 4.1.6.6. The egpNeighborLoss Trap
-
- An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 27]
-
- RFC 1067 SNMP August 1988
-
-
- the sending protocol entity was an EGP peer has been marked down and
- the peer relationship no longer obtains.
-
- The Trap-PDU of type egpNeighborLoss contains as the first element of
- its variable-bindings, the name and value of the egpNeighAddr
- instance for the affected neighbor.
-
- 4.1.6.7. The enterpriseSpecific Trap
-
- A enterpriseSpecific(6) trap signifies that the sending protocol
- entity recognizes that some enterprise-specific event has occurred.
- The specific-trap field identifies the particular trap which
- occurred.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 28]
-
- RFC 1067 SNMP August 1988
-
-
- 5. Definitions
-
- RFC1067-SNMP DEFINITIONS ::= BEGIN
-
- IMPORTS
- ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
- FROM RFC1065-SMI;
-
-
- -- top-level message
-
- Message ::=
- SEQUENCE {
- version -- version-1 for this RFC
- INTEGER {
- version-1(0)
- },
-
- community -- community name
- OCTET STRING,
-
- data -- e.g., PDUs if trivial
- ANY -- authentication is being used
- }
-
-
- -- protocol data units
-
- PDUs ::=
- CHOICE {
- get-request
- GetRequest-PDU,
-
- get-next-request
- GetNextRequest-PDU,
-
- get-response
- GetResponse-PDU,
-
- set-request
- SetRequest-PDU,
-
- trap
- Trap-PDU
- }
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 29]
-
- RFC 1067 SNMP August 1988
-
-
- -- PDUs
-
- GetRequest-PDU ::=
- [0]
- IMPLICIT PDU
-
- GetNextRequest-PDU ::=
- [1]
- IMPLICIT PDU
-
- GetResponse-PDU ::=
- [2]
- IMPLICIT PDU
-
- SetRequest-PDU ::=
- [3]
- IMPLICIT PDU
-
- PDU ::=
- SEQUENCE {
- request-id
- INTEGER,
-
- error-status -- sometimes ignored
- INTEGER {
- noError(0),
- tooBig(1),
- noSuchName(2),
- badValue(3),
- readOnly(4),
- genErr(5)
- },
-
- error-index -- sometimes ignored
- INTEGER,
-
- variable-bindings -- values are sometimes ignored
- VarBindList
- }
-
- Trap-PDU ::=
- [4]
- IMPLICIT SEQUENCE {
- enterprise -- type of object generating
- -- trap, see sysObjectID in [2]
-
-
- OBJECT IDENTIFIER,
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 30]
-
- RFC 1067 SNMP August 1988
-
-
- agent-addr -- address of object generating
- NetworkAddress, -- trap
-
- generic-trap -- generic trap type
- INTEGER {
- coldStart(0),
- warmStart(1),
- linkDown(2),
- linkUp(3),
- authenticationFailure(4),
- egpNeighborLoss(5),
- enterpriseSpecific(6)
- },
-
- specific-trap -- specific code, present even
- INTEGER, -- if generic-trap is not
- -- enterpriseSpecific
-
- time-stamp -- time elapsed between the last
- TimeTicks, -- (re)initialization of the
- network
- -- entity and the generation of the
- trap
-
- variable-bindings -- "interesting" information
- VarBindList
- }
-
-
- -- variable bindings
-
- VarBind ::=
- SEQUENCE {
- name
- ObjectName,
-
- value
- ObjectSyntax
- }
-
- VarBindList ::=
- SEQUENCE OF
- VarBind
-
- END
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 31]
-
- RFC 1067 SNMP August 1988
-
-
- 6. Acknowledgements
-
- This memo was influenced by the IETF SNMP Extensions working
- group:
-
- Karl Auerbach, Epilogue Technology
- K. Ramesh Babu, Excelan
- Amatzia Ben-Artzi, 3Com/Bridge
- Lawrence Besaw, Hewlett-Packard
- Jeffrey D. Case, University of Tennessee at Knoxville
- Anthony Chung, Sytek
- James Davidson, The Wollongong Group
- James R. Davin, Proteon
- Mark S. Fedor, NYSERNet
- Phill Gross, The MITRE Corporation
- Satish Joshi, ACC
- Dan Lynch, Advanced Computing Environments
- Keith McCloghrie, The Wollongong Group
- Marshall T. Rose, The Wollongong Group (chair)
- Greg Satz, cisco
- Martin Lee Schoffstall, Rensselaer Polytechnic Institute
- Wengyik Yeong, NYSERNet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 32]
-
- RFC 1067 SNMP August 1988
-
-
- 7. References
-
- [1] Cerf, V., "IAB Recommendations for the Development of
- Internet Network Management Standards", RFC 1052, IAB,
- April 1988.
-
- [2] Rose, M., and K. McCloghrie, "Structure and Identification
- of Management Information for TCP/IP-based internets",
- RFC 1065, TWG, August 1988.
-
- [3] McCloghrie, K., and M. Rose, "Management Information Base
- for Network Management of TCP/IP-based internets",
- RFC 1066, TWG, August 1988.
-
- [4] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
- "A Simple Network Management Protocol", Internet
- Engineering Task Force working note, Network Information
- Center, SRI International, Menlo Park, California,
- March 1988.
-
- [5] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
- "A Simple Gateway Monitoring Protocol", RFC 1028,
- Proteon, University of Tennessee at Knoxville,
- Cornell University, and Rensselaer Polytechnic
- Institute, November 1987.
-
- [6] Information processing systems - Open Systems
- Interconnection, "Specification of Abstract Syntax
- Notation One (ASN.1)", International Organization for
- Standardization, International Standard 8824,
- December 1987.
-
- [7] Information processing systems - Open Systems
- Interconnection, "Specification of Basic Encoding Rules
- for Abstract Notation One (ASN.1)", International
- Organization for Standardization, International Standard
- 8825, December 1987.
-
- [8] Postel, J., "User Datagram Protocol", RFC 768,
- USC/Information Sciences Institute, November 1980.
-
-
-
-
-
-
-
-
-
-
-
- Case, Fedor, Schoffstall, & Davin [Page 33]
|