As per Relevance of the word response, we have this rfc below:
Network Working Group B.
Request for Comments: 2089
Category: Informational D.
SNMP Research,
January 1997
V2ToV
Mapping SNMPv2 onto SNMPv
within a bi-lingual SNMP
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The goal of this memo is to document a common way of mapping
SNMPv2 response into an SNMPv1 response within a bi-lingual
agent (one that supports both SNMPv1 and SNMPv2).
Table of
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Mapping SNMPv2 into SNMPv1 . . . . . . . . . . . . . . . . 2
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status . . . 3
2.2 Mapping SNMPv2 exceptions into SNMPv1 . . . . . . . . . . 3
2.3 Mapping noSuchObject and noSuchInstance . . . . . . . . . 4
2.4 Mapping endOfMibView . . . . . . . . . . . . . . . . . . . 5
2.5 Mapping SNMPv2 SMI into SNMPv1 . . . . . . . . . . . . . . 5
3.0 Processing SNMPv1 requests . . . . . . . . . . . . . . . . 6
3.1 Processing an SNMPv1 GET request . . . . . . . . . . . . . 6
3.2 Processing an SNMPv1 GETNEXT request . . . . . . . . . . . 7
3.3 Processing an outgoing SNMPv2 trap . . . . . . . . . . . . 8
4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
5.0 References . . . . . . . . . . . . . . . . . . . . . . . . 10
6.0 Security Considerations . . . . . . . . . . . . . . . . . 10
7.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Background Information . . . . . . . . . . . . . 12
A.1 Mapping of error-status Values . . . . . . . . . . . . . 12
A.2 SNMPv1 traps without Counter64 varBinds. . . . . . . . . 12
Wijnen & Levi Informational [Page 1]
RFC 2089 V2toV1 January 1997
1.0
We now have the SNMPv1 protocol (RFC1157 [1]) as a full standard
the SNMPv2 protocol (RFC1905 [1]) as a DRAFT standard. It can
expected that many agent implementations will support both SNMPv1
SNMPv2 requests coming from SNMP management entities. In many
the underlying instrumentation will be implemented using the
SNMPv2 SMI and SNMPv2 protocol. The SNMP engine then gets the
to ensure that any SNMPv2 response data coming from such SNMPv
compliant instrumentation gets converted to a proper SNMPv1
if the original request came in as an SNMPv1 request. The
engine should also deal with mapping SNMPv2 traps which are
by an application or by the SNMPv2 compliant instrumentation
SNMPv1 traps if the agent has been configured to send traps to
SNMPv1 manager
It seems beneficial if all such agents do this mapping in the
way. This document describes such a mapping based on discussions
perceived consensus on the various mailing lists. The authors
this document have also compared their own implementations of
mappings. They had a few minor differences and decided to make
implementation behave the same and document this mapping so
can benefit from it
We recommend that all agents implement this same mapping
Note that the mapping described in this document should also
followed by SNMP proxies that provide a mapping between SNMPv
management applications and SNMPv2 agents
2.0 Mapping SNMPv2 into SNMPv
These are the type of mappings that we need
o Mapping of the SNMPv2 error-status into SNMPv1 error-
o Mapping of the SNMPv2 exceptions into SNMPv1 error-
o Skipping object instances that have a non-SNMPv1
(specifically Counter64)
o Mapping of SNMPv2 traps into SNMPv1
Wijnen & Levi Informational [Page 2]
RFC 2089 V2toV1 January 1997
2.1 Mapping SNMPv2 error-status into SNMPv1 error-
With the new SNMPv2 protocol (RFC1905 [1]) we get a set of error
status values that return the cause of an error in much more detail
But an SNMPv1 manager does not understand such error-status values
So, when the instrumentation code returns response data and uses
SNMPv2 error-status to report on the success or failure of
requested operation and if the original SNMP request is an SNMPv
request, then we must map such an error-status into an SNMPv1 error
status when composing the SNMP response PDU
The SNMPv2 error status is mapped to an SNMPv1 error-status
this table
SNMPv2 error-status SNMPv1 error-
=================== ===================
noError
tooBig
noSuchName
badValue
readOnly
genErr
wrongValue
wrongEncoding
wrongType
wrongLength
inconsistentValue
noAccess
notWritable
noCreation
inconsistentName
resourceUnavailable
commitFailed
undoFailed
authorizationError
2.2 Mapping SNMPv2 exceptions into SNMPv
In SNMPv2 we have so called exception values. These will allow
SNMPv2 response PDU to return as much management information
possible, even if one or more of the requested variables do
exist. SNMPv1 does not support exception values, and thus does
return the value of management information when any error occurs
When multiple variables do not exist, an SNMPv1 agent can return
a single error and index of a single variable. The agent
by its implementation strategy which variable to identify as
Wijnen & Levi Informational [Page 3]
RFC 2089 V2toV1 January 1997
cause of the error via the value of the error-index field. Thus,
SNMPv1 manager may make no assumption on the validity of the
variables in the request
So, when an SNMPv1 request is received, we must check the
returned from SNMPv2 compliant instrumentation for exception values
and convert these exception values into SNMPv1 error codes
The type of exception we can get back and the action we must
depends on the SNMP operation that is requested
o For SNMP GET requests we can get back noSuchObject
noSuchInstance
o For SNMP GETNEXT requests we can get back endOfMibView
o For SNMP SET requests we cannot get back any exceptions
o For SNMP GETBULK requests we can get back endOfMibView,
such a request should only come in as an SNMPv2 request, so
do not have to worry about any mapping onto SNMPv1. If
GETBULK comes in as an SNMPv1 request, it is treated as
error and the packet is dropped
2.3 Mapping noSuchObject and
A noSuchObject or noSuchInstance exception generated by SNMPv
compliant instrumentation indicates that the requested
instance can not be returned. The SNMPv1 error code for
condition is noSuchName, and so the error-status field of
response PDU should be set to noSuchName. Also, the error-
field is set to the index of the varBind for which an
occurred, and the varBind list from the original request is
with the response PDU
Note that when the response contains multiple exceptions, that
agent may pick any one to be returned
Wijnen & Levi Informational [Page 4]
RFC 2089 V2toV1 January 1997
2.4 Mapping
When SNMPv2 compliant instrumentation returns a varBind containing
endOfMibView exception in response to a GETNEXT request, it
that there are no object instances available which
follow the object in the request. In an SNMPv1 agent, this
normally results in a noSuchName error, and so the error-status
of the response PDU should be set to noSuchName. Also, the error
index field is set to the index of the varBind for which an
occurred, and the varBind list from the original request is
with the response PDU
Note that when the response contains multiple exceptions, that
agent may pick any one to be returned
2.5 Mapping SNMPv2 SMI into SNMPv
The SNMPv2 SMI (RFC1902 [2]) defines basically one new syntax that
problematic for SNMPv1 managers. That is the syntax Counter64.
the others can be handled by SNMPv1 managers
The net impact on bi-lingual agents is that they should make
that they never return a varBind with a Counter64 value to an SNMPv
manager
The best accepted practice is to consider such object
implicitly excluded from the view. So
o On an SNMPv1 GET request, we return an error-status
noSuchName and the error-index is set to the varBind
causes this error
o On an SNMPv1 GETNEXT request, we skip the object instance
fetch the next object instance that follows the one with
syntax of Counter64.
o Any SET request that has a varBind with a Counter64 value
have come from a SNMPv2 manager, and so it should not cause
problem. If we do receive a Counter64 value in an SNMPv1
packet, it should result in an ASN.1 parse error
Counter64 is not valid in the SNMPv1 protocol. When an ASN.1
parse error occurs, the counter snmpInASNParseErrs
incremented and no response is returned
o The GETBULK is an SNMPv2 operation, so it should never
from an SNMPv1 manager. If we do receive a GETBULK PDU from
an SNMPv1 packet, then we consider it an invalid PDU-type
we drop the packet
Wijnen & Levi Informational [Page 5]
RFC 2089 V2toV1 January 1997
3.0 Processing SNMPv1
This sections contains a step by step description of how to
SNMPv1 requests in an agent where the underlying instrumentation
is SNMPv2 compliant
3.1 Processing an SNMPv1 GET
First, the request is converted into a call to the
instrumentation. This is implementation specific
When such instrumentation returns response data using SNMPv2
and error-status values, then
1. If the error-status is anything other than noError
a. The error status is translated to an SNMPv1 error-
using the table from 2.1, "Mapping SNMPv2 error-status
SNMPv1 error-status" on page 2
b. The error-index is set to the position (in the
request) of the varBind that caused the error-status
c. The varBindList of the response PDU is made exactly
same as the varBindList that was received in the
request
2. If the error-status is noError, then find any varBind
contains an SNMPv2 exception (noSuchObject or noSuchInstance
or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64).
(Note that if there are more than one, the agent may choose
such varBind.) If there are any such varBinds, then for
one chosen
a. Set the error-status to
b. Set the error-index to the position (in the varBindList
the original request) of the varBind that returned such
SNMPv2 exception or syntax
c. Make the varBindList of the response PDU exactly the
as the varBindList that was received in the
request
Wijnen & Levi Informational [Page 6]
RFC 2089 V2toV1 January 1997
3. If there are no such varBinds, then
a. Set the error-status to
b. Set the error-index to
c. Compose the varBindList of the response, using the data
it is returned by the instrumentation code
3.2 Processing an SNMPv1 GETNEXT
First, the request is converted into a call to the
instrumentation. This is implementation specific. There may
repetitive calls to (possibly different pieces of)
code to try to find the first object which lexicographically
each of the objects in the request. Again, this is
specific
When the instrumentation finally returns response data using SNMPv
syntax and error-status values, then
1. If the error-status is anything other than noError
a. The error status is translated to an SNMPv1 error-
using the table from 2.1, "Mapping SNMPv2 error-status
SNMPv1 error-status" on page 2
b. The error-index is set to the position (in the
request) of the varBind that caused the error-status
c. The varBindList of the response PDU is made exactly
same as the varBindList that was received in the
request
2. If the error-status is noError, then
a. If there are any varBinds containing an SNMPv2 syntax
Counter64, then consider these varBinds to be not in
and repeat the call to the instrumentation code as often
needed till a value other than Counter64 is returned
b. Find any varBind that contains an SNMPv2
endOfMibView. (Note that if there are more than one,
agent may choose any such varBind.) If there are any
varBinds, then for the one chosen
1) Set the error-status to
Wijnen & Levi Informational [Page 7]
RFC 2089 V2toV1 January 1997
2) Set the error-index to the position (in the
of the original request) of the varBind that
such an SNMPv2 exception
3) Make the varBindList of the response PDU exactly
same as the varBindList that was received in
original request
c. If there are no such varBinds, then
1) Set the error-status to
2) Set the error-index to
3) Compose the varBindList of the response, using the
as it is returned by the instrumentation code
3.3 Processing an outgoing SNMPv2
If SNMPv2 compliant instrumentation presents an SNMPv2 trap to
SNMP engine and such a trap passes all regular checking and then
to be sent to an SNMPv1 destination, then the following steps must
followed to convert such a trap to an SNMPv1 trap. This is
the reverse of the SNMPv1 to SNMPv2 mapping as described in RFC1908
[3].
1. If any of the varBinds in the varBindList has an SNMPv2
of Counter64, then such varBinds are implicitly considered
be not in view, and so they are removed from the varBindList
be sent with the SNMPv1 trap
2. The 3 special varBinds in the varBindList of an SNMPv2
(sysUpTime.0 (TimeTicks), snmpTrapOID.0 (OBJECT IDENTIFIER)
optionally snmpTrapEnterprise.0 (OBJECT IDENTIFIER))
removed from the varBindList to be sent with the SNMPv1 trap
These 2 (or 3) varBinds are used to decide how to set
fields in the SNMPv1 trap PDU as follows
a. The value of sysUpTime.0 is copied into the timestamp
of the SNMPv1 trap
Wijnen & Levi Informational [Page 8]
RFC 2089 V2toV1 January 1997
b. If the snmpTrapOID.0 value is one of the standard traps
specific-trap field is set to zero and the generic
field is set according to this mapping
value of snmpTrapOID.0 generic-
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
The enterprise field is set to the value
snmpTrapEnterprise.0 if this varBind is present,
it is set to the value snmpTraps as defined in RFC1907 [4].
c. If the snmpTrapOID.0 value is not one of the
traps, then the generic-trap field is set to 6 and
specific-trap field is set to the last subid of
snmpTrapOID.0 value
o If the next to last subid of snmpTrapOID.0 is zero
then the enterprise field is set to snmpTrapOID.0
and the last 2 subids are truncated from that value
o If the next to last subid of snmpTrapOID.0 is not zero
then the enterprise field is set to snmpTrapOID.0
and the last 1 subid is truncated from that value
In any event, the snmpTrapEnterprise.0 varBind (if present
is ignored in this case
3. The agent-addr field is set with the appropriate address of
the sending SNMP entity, which is the IP address of the
entity of the trap goes out over UDP; otherwise the agent-
field is set to address 0.0.0.0.
Wijnen & Levi Informational [Page 9]
RFC 2089 V2toV1 January 1997
4.0
The authors wish to thank the contributions of the SNMPv2
Group in general. Special thanks for their detailed review
comments goes to these individuals
Mike Daniele (DEC
Dave Harrington (Cabletron
Brian O'Keefe (Hewlett Packard
Keith McCloghrie (Cisco Systems
Dave Perkins (independent
Shawn Routhier (Epilogue
Juergen Schoenwaelder (University of Twente
5.0
[1] Jeffrey D. Case, Mark Fedor, Martin Lee Schoffstall and
R. Davin, Simple Network Management Protocol (SNMP),
Research, Performance Systems International, MIT
for Computer Science, RFC 1157, May 1990.
[2] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and
Waldbusser, Structure of Managment Information for Version 2
of the Simple Network Management Protocol (SNMPv2),
Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc
International Network Services, RFC1902, January 1996.
[3] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and
Waldbusser, Coexistence between Version 1 and Version 2 of
Internet-standard Network Management Framework, SNMP
Inc, Cisco Systems Inc, Dover Beach Consulting Inc
International Network Services, RFC1908, January 1996.
[4] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and
Waldbusser, Management Information Base for Version 2 of
Simple Network Management Protocol (SNMPv2), SNMP
Inc, Cisco Systems Inc, Dover Beach Consulting Inc
International Network Services, RFC1907, January 1996.
6.0 Security
Security considerations are not discussed in this memo
Wijnen & Levi Informational [Page 10]
RFC 2089 V2toV1 January 1997
7.0 Authors'
Bert
IBM International
Watsonweg 2
1423 ND
The
Phone: +31-079-322-8316
E-mail: wijnen@vnet.ibm.
David
SNMP Research,
3001 Kimberlin Heights Rd
Knoxville, TN 37920-9716
Phone: +1-615-573-1434
E-mail: levi@snmp.
Wijnen & Levi Informational [Page 11]
RFC 2089 V2toV1 January 1997
APPENDIX A. Background
Here follows some reasoning as to why some choices were made
A.1 Mapping of error-status
The mapping of SNMPv2 error-status values to SNMPv1 error-
values is based on the common interpretation of how an SNMPv1
should create an error-status value based on the elements
procedure defined in RFC1157 [1].
There was a suggestion to map wrongEncoding into genErr, because
could be caused by an ASN.1 parsing error. Such maybe true, but
most cases when we detect the ASN.1 parsing error, we do not yet
about the PDU data yet. Most people who responded to our
have implemented the mapping to a badValue. So we "agreed" on
mapping to badValue
A.2 SNMPv1 Traps without Counter64 varBinds
RFC1448 says that if one of the objects in the varBindList is
included in the view, then the trap is NOT sent. Current SNMPv2u
SNMPv2* documents make the same statement. However, the "
consensus" is that it is better to send partial information than
information at all. Besides
o RFC1448 does not allow for a TRAP to be sent with the
that are not included in the view removed, so it is an all
nothing decision
o We do NOT include the Counter64 varBinds... so the "not
view" varBinds are not sent to the trap destination
o The Counter64 objects are "implicit" not in view. If
objects are explicit not in view, then this is checked
we do the conversion from an SNMPv2 trap to an SNMPv1 trap,
so the trap is not sent at all
Wijnen & Levi Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
