rfc1098.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,682 行 · 第 1/5 页
TXT
1,682 行
RFC 1098 SNMP April 1989
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 1098 SNMP April 1989
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 1098 SNMP April 1989
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 1098 SNMP April 1989
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 1098 SNMP April 1989
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 1098 SNMP April 1989
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 1098 SNMP April 1989
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?