rfc1592.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,376 行 · 第 1/5 页
TXT
1,376 行
support. As a result, the some SNMP-DPI agents support both TCP and
UDP socket type communication mechanisms for the SNMP-DPI protocol.
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 5]
RFC 1592 SNMP-DPI March 1994
Please note that in the following portion of this text the SNMP-DPI
agent is referred simply as the agent.
Once the transport connection has been set up, the sub-agent must
also initialize the logical connection with the agent. To do so it
issues an OPEN request to the agent in which the sub-agent uniquely
identifies itself and passes some other parameters to the agent, such
as, the maximum number of varBinds per interaction it is prepared to
handle, and the timeout the agent should use when waiting for a
response from the sub-agent.
When the sub-agent prepares to stop or cease operations, it first
issues a CLOSE to shut down the logical connection with the agent,
and then closes the transport connection.
2.2 REGISTRATION
A sub-agent supports a collection of MIB variables or object
identifiers (object IDs) that constitute its MIB (sub)tree. Each of
these object IDs consists of a group ID and an instance ID. The
group ID is the root of the sub-agent's MIB tree that it supports and
the point of registration to the agent's MIB tree. The instance ID
is the piece of the Object Identifier that follows the group ID
(registration point), so it is not an instance in the terms of the
SNMP definition of an instance.
Regardless of the transport mechanism used, after establishing a
connection to the agent, the sub-agent registers a branch (group ID)
to the Agent's MIB tree. With the registration request, the sub-
agent passes some parameters, such as, requested priority and a
timeout value for this specific sub-tree.
The agent sends back a response to indicate success or failure of the
registration request.
2.3 NORMAL OPERATION
Once the sub-agent has set up both the physical and logical
connection to the agent, and once it has successfully registered the
sub-tree(s) of the MIB(s) that it supports, it waits for requests
from the SNMP agent or generates traps as required.
2.4 DPI ARCHITECTURE
These are the requests that can be initiated by the SNMP agent:
GET, GETNEXT, GETBULK, SET, COMMIT, UNDO, UNREGISTER, and CLOSE.
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 6]
RFC 1592 SNMP-DPI March 1994
The first four of these correspond directly to SNMP requests that a
network management station can make (By default a GETBULK request
will be translated into multiple GETNEXT requests by the agent, but a
sub-agent may request that the GETBULK be passed to it). The COMMIT,
UNDO, UNREGISTER, ARE_YOU_THERE and CLOSE requests are specific
SNMP-DPI requests. The sub-agent normally responds to a request with
a RESPONSE packet. The CLOSE request is an exception for which the
sub-agent only closes the physical connection.
These are the requests that can be initiated by a sub-agent:
OPEN, REGISTER, TRAP, UNREGISTER, ARE_YOU_THERE and CLOSE.
The agent responds to OPEN, REGISTER, UNREGISTER and ARE_YOU_THERE
with a RESPONSE packet. The TRAP packet is just accepted and
forwarded by the agent without returning any information to the sub-
agent. The CLOSE packet is also just accepted by the agent upon
which it closes the physical connection.
See Figure 1 for an overview of the DPI packet flow.
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 7]
RFC 1592 SNMP-DPI March 1994
-------------------------------------------------------------------
*---------------------------------*
| |
| SNMP Network |
| Management Station |
| |
|---------------------------------|
| SNMP Protocol |
*---------------------------------*
A | Get A
| | GetNext | GetResponse
Trap | | GetBulk |
| | Set |
| V |
*------------------------------* *-------------------*
| SNMP Protocol | | DPI Interface |
|------------------------------| Response | *--------------|
| | |<----------->| | |
| | | | | |
| SNMP Agent | | | | |
| | | Get,GetNext | | |
| | | (GetBulk) | | Client |
| | | Set,Commit | | |
| A *-----------+-> | Undo | | |
| | | Get/Set | |------------>| | or |
| Trap| | info | | | | |
| | | | SNMP | | | |
|-----+-----+-------* | | trap | | SNMP |
| | V | | DPI |<------------| | Sub-Agent |
| | | | | | |
| Statically Linked | | | | | |
| Instrumentation | | | | | |
| (like MIB II) | | | | | |
| | | | close | | |
| A | | | unregister | | |
|-------+-----------| | |<----------->| | |
| V | | | | | |
| | | | | | |
| | | | AreYouThere | | |
| TCP/IP layers | | | open | | |
| Kernel | | | register | | |
| | | |<------------| | |
*------------------------------* *-------------------*
-------------------------------------------------------------------
Figure 1. SNMP DPI overview
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 8]
RFC 1592 SNMP-DPI March 1994
Remarks for Figure 1:
o The SNMP agent communicates with the SNMP manager via the
standard SNMP protocol.
o The SNMP agent communicates with some statically linked-in
instrumentation (potentially for the MIB II), which in turn
talks to the TCP/IP layers and kernel (operating system) in an
implementation-dependent manner.
o An SNMP sub-agent, running as a separate process (potentially
on another machine), can set up a connection with the agent.
The sub-agent has an option to communicate with the SNMP agent
through UDP or TCP sockets, or even through other mechanisms.
o Once the connection is established, the sub-agent issues a DPI
OPEN and one or more REGISTER requests to register one or more
MIB sub-trees with the SNMP agent.
o The SNMP agent responds to DPI OPEN and REGISTER requests with
a RESPONSE packet, indicating success or failure.
o The SNMP agent will decode SNMP packets.
If such a packet contains a Get or GetNext request for an
object in a sub-tree registered by a sub-agent, it sends a
corresponding DPI packet to the sub-agent.
If the request is for a GetBulk, then the agent translates it
into multiple DPI GETNEXT packets and sends those to the
sub-agent. However, the sub-agent can request (in the REGISTER
packet) that a GETBULK be passed to the sub-agent.
If the request is for a Set, then the agent uses a 2-phase
commit scheme and sends the sub-agent a sequence of SET/COMMIT,
SET/UNDO or SET/COMMIT/UNDO DPI packets.
o The SNMP sub-agent sends responses back via a RESPONSE packet.
o The SNMP agent then encodes the reply into an SNMP packet and
sends it back to the requesting SNMP manager.
o If the sub-agent wants to report an important state change, it
sends a DPI TRAP packet to the SNMP agent which will encode it
into an SNMP trap packet and send it to the manager(s).
o If the sub-agent wants to stop operations, it sends a DPI
UNREGISTER and a DPI CLOSE packet to the agent. The agent
sends a response to an UNREGISTER request.
o There is no RESPONSE to a CLOSE, the agent just closes the DPI
connection. A CLOSE implies an UNREGISTER for all
registrations that exist for the DPI connection being CLOSED.
o An agent can send DPI UNREGISTER (if a higher priority
registration comes in or for other reasons) to the sub-agent,
the sub-agent then responds with a DPI RESPONSE packet.
o An agent can also (for whatever reason) send a DPI CLOSE to
indicate it is terminating the DPI connection.
o A sub-agent can send an ARE_YOU_THERE to verify that the
"connection" is still open. If so, the agent sends a RESPONSE
with no error, otherwise, it may send a RESPONSE with an error
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 9]
RFC 1592 SNMP-DPI March 1994
indication, or not react at all.
3. SNMP DPI PROTOCOL
This section describes the actual protocol used between the SNMP
agent and sub-agents.
3.1 CONNECTION ESTABLISHMENT
In a TCP/IP environment, the SNMP agent listens on an arbitrary
TCP/UDP port for a connection request from a sub-agent. It is
important to realize that a well-known port is not used: every
invocation of the SNMP agent will potentially result in a different
TCP/UDP port being used.
A sub-agent needs to determine this port number to establish a
connection. The sub-agent learns the port number from the agent by
sending it one conventional SNMP get-request PDU. The port numbers
are maintained by the SNMP agent as the objects whose identifiers
are:
1.3.6.1.4.1.2.2.1.1.0 dpiPort.0 (old DPI 1.x form)
1.3.6.1.4.1.2.2.1.1.1.0 dpiPortForTCP.0
1.3.6.1.4.1.2.2.1.1.2.0 dpiPortForUDP.0
These variables are registered under the IBM enterprise-specific
tree. See 4, "DPI 2.0 MIB definition" for more information. The
SNMP agent replies with a conventional SNMP response PDU that
contains the port number to be used. This response is examined by
the sub-agent and the port number is extracted. The sub-agent then
establishes the connection to the specified port.
On the surface, this procedure appears to mean that the sub-agent
must be able to create and parse SNMP packets, but this is not the
case. A DPI Application Programming Interface (API) normally
provides a library routine, query_DPI_port(), which can be used to
generate and parse the required SNMP packets. This very small
routine (under 100 lines of C), does not greatly increase the size of
any sub-agent.
NOTE: Since this RFC does not define an API, the actual code of and
interface to a query_DPI_port() type of function depends on the
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?