rfc1592.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,376 行 · 第 1/5 页
TXT
1,376 行
The first part of every packet identifies the application protocol
being used as well as some version information. The protocol major
version is intended to indicate, in broad terms, what version of the
protocol is used. The protocol minor version is intended to identify
major incompatible versions of the protocol. The protocol release is
intended to indicate incremental modifications to the protocol. The
constants that are valid for these fields are defined in Table 15.
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 15]
RFC 1592 SNMP-DPI March 1994
The next field, present in all packets, is the packet ID. It
contains packet identification that can help an agent or sub-agent
match responses with request. This is useful with UDP connections
over which packets can be lost. The packet ID is a monotonically
increasing unsigned 16-bit integer which wraps at its maximum value.
The next field, present in all packets, is the packet type. It
indicates what kind of packet we're dealing with (OPEN, REGISTER,
GET, GETNEXT, GETBULK, SET, COMMIT, UNDO, TRAP, RESPONSE, UNREGISTER,
or CLOSE). The permitted values for this field are defined in Table
16.
+-----------------------------------------------------------------+
| Table 3. SNMP DPI packet header. Present in all packets. |
+------------+----------------------------------------------------+
| OFFSET | FIELD |
+------------+----------------------------------------------------+
| 0 | packet length to follow (MSB to LSB) |
+------------+----------------------------------------------------+
| 2 | protocol major version |
+------------+----------------------------------------------------+
| 3 | protocol minor version |
+------------+----------------------------------------------------+
| 4 | protocol release |
+------------+----------------------------------------------------+
| 5 | packet id (MSB to LSB) |
+------------+----------------------------------------------------+
| 7 | packet type |
+------------+----------------------------------------------------+
From this point onwards, the contents of the packet are defined by
the protocol being used. The remainder of this section describes:
o Layout of packets for the SNMP DPI protocol, version 2.0.
o Constants as defined with this version of the protocol.
3.2.2 OPEN
In order for a sub-agent to communicate with a DPI capable SNMP
agent, it must first send an SNMP DPI OPEN request to the agent to
setup the "connection" with that agent.
Such a packet contains the standard SNMP DPI header plus OPEN
specific data. This data consists of:
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 16]
RFC 1592 SNMP-DPI March 1994
o a timeout value (in seconds).
This is a requested timeout value to be used for all requests
for objects for which there is no timeout value specified for
the sub-tree under which the object is registered. If you
specify a zero timeout value, then the agent will use its own
default timeout value. If you want a larger value than the
default value, then you can specify it here. However, the agent
may have a maximum value that you can never exceed. If you do
ask for a larger timeout than that maximum, the agent will set
it at the maximum it accepts.
o the maximum number of varBinds per DPI packet that the
sub-agent is prepared to handle.
o Selected character set to be used for the representation of the
OBJECT ID strings and DisplayStrings.
The choices are the native character set (0) or the ASCII
character set (1). See 3.3.5, "Character set selection"
for more information in character set selection.
An agent may choose to support only the native character set.
o null terminated sub-agent ID, which is a unique ASN.1 OBJECT
identifier, so in dotted ASN.1 notation. This string is
represented in the selected character set.
o null terminated sub-agent description, which is a DisplayString
describing the sub-agent. This string is represented in the
selected character set. This may be the null-string if there
is no description.
o optionally a password that the agent uses to validate the
sub-agent. It depends on the agent implementation if a
password is required. If no password is passed, the length
must be specified as zero.
The sub-agent must expect a response indicating success or failure.
See Table 19 for the valid codes in a DPI RESPONSE to a DPI OPEN
request.
If the error_code in the RESPONSE is not SNMP_ERROR_DPI_noError, then
the agent closes the connection.
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 17]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 4. Layout SNMP DPI OPEN packet |
+------------+----------------------------------------------------+
| OFFSET | FIELD |
+------------+----------------------------------------------------+
| 0 | packet length to follow (MSB to LSB) |
+------------+----------------------------------------------------+
| 2 | protocol major version |
+------------+----------------------------------------------------+
| 3 | protocol minor version |
+------------+----------------------------------------------------+
| 4 | protocol release |
+------------+----------------------------------------------------+
| 5 | packet id (MSB to LSB) |
+------------+----------------------------------------------------+
| 7 | packet type = SNMP_DPI_OPEN |
+------------+----------------------------------------------------+
| 8 | requested overall timeout (seconds, MSB to LSB) |
+------------+----------------------------------------------------+
| 10 | max varBinds per DPI packet (MSB to LSB) |
+------------+----------------------------------------------------+
| 12 | Selected character set (0=Native, 1=ASCII) |
+------------+----------------------------------------------------+
| 13 | null terminated sub-agent ID (OID) |
+------------+----------------------------------------------------+
| 13+L1 | null terminated sub-agent Description |
+------------+----------------------------------------------------+
| 13+L2 | password length (zero if no password, MSB to LSB) |
+------------+----------------------------------------------------+
| 15+L2 | password (if any) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o L1 = strlen(sub-agent ID) + 1 |
| o L2 = L1 + strlen(sub-agent Description) + 1 |
| o OID and Description strings use selected character set |
+-----------------------------------------------------------------+
3.2.3 CLOSE
In order for a sub-agent to close the "connection" with the DPI
capable SNMP agent, it must send an SNMP DPI CLOSE request to the
agent. The agent will not send a response, but closes the physical
connection and implicitly unregisters any sub-trees related to the
connection.
An agent may also send to the sub-agent an SNMP DPI CLOSE packet that
contains the standard SNMP DPI header plus CLOSE specific data. This
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 18]
RFC 1592 SNMP-DPI March 1994
data consists of:
o a reason code for closing. See Table 21 for a list
of valid reason codes.
+-----------------------------------------------------------------+
| Table 5. Layout SNMP DPI CLOSE packet |
+------------+----------------------------------------------------+
| OFFSET | FIELD |
+------------+----------------------------------------------------+
| 0 | packet length to follow (MSB to LSB) |
+------------+----------------------------------------------------+
| 2 | protocol major version |
+------------+----------------------------------------------------+
| 3 | protocol minor version |
+------------+----------------------------------------------------+
| 4 | protocol release |
+------------+----------------------------------------------------+
| 5 | packet id (MSB to LSB) |
+------------+----------------------------------------------------+
| 7 | packet type = SNMP_DPI_CLOSE |
+------------+----------------------------------------------------+
| 8 | reason code (1 octet) |
+------------+----------------------------------------------------+
3.2.4 ARE_YOU_THERE
An ARE_YOU_THERE packet allows a sub-agent to determine if it still
has a DPI connection with the agent. This packet is necessary
because a sub-agent passively awaits requests from an agent and
normally will not detect problems with an agent connection in a
timely manner. (In contrast, an agent becomes aware of any sub-agent
connection problem in a timely manner because it sets a timeout when
sending request).
A sub-agent can send a SNMP DPI ARE_YOU_THERE packet to an agent
which will then return a RESPONSE with a zero error code and a a zero
error index if the connection is healthy. Otherwise, the agent may
return a RESPONSE with an error indication. If the connection is
broken, the sub-agent will see no response at all.
An ARE_YOU_THERE packet contains the standard SNMP DPI header with no
additional data.
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 19]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 6. Layout SNMP DPI ARE_YOU_THERE packet |
+------------+----------------------------------------------------+
| OFFSET | FIELD |
+------------+----------------------------------------------------+
| 0 | packet length to follow (MSB to LSB) |
+------------+----------------------------------------------------+
| 2 | protocol major version |
+------------+----------------------------------------------------+
| 3 | protocol minor version |
+------------+----------------------------------------------------+
| 4 | protocol release |
+------------+----------------------------------------------------+
| 5 | packet id (MSB to LSB) |
+------------+----------------------------------------------------+
| 7 | packet type = SNMP_DPI_ARE_YOU_THERE |
+------------+----------------------------------------------------+
3.2.5 REGISTER
In order to register a branch in the MIB tree, an SNMP sub-agent
sends an SNMP DPI REGISTER packet to the agent.
Such a packet contains the standard SNMP DPI header plus REGISTER
specific data. This data consists of:
o a requested priority.
There are 2 special values, namely minus one (-1, requests best
available priority) and zero (0, requests next better priority
than the highest priority in use). Any other value requests a
specific priority or the next best priority if already in use).
The lower the number, the better the priority. An agent will
send requests to only the one sub-agent that has registered
with the best priority. The agent returns the actual priority
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?