As per Relevance of the word register, we have this rfc below:
Network Working Group B.
Request for Comments: 1592 G.
Obsoletes: 1228 T.J. Watson Research Center, IBM Corp
Category: Experimental K.
A.
G.
Bell Northern Research, Ltd
March 1994
Simple Network Management
Distributed Protocol
Version 2.0
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Table of
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Summary of Changes . . . . . . . . . . . . . . . . . . . . 4
2. THEORY OF OPERATION . . . . . . . . . . . . . . . . . . . . . 5
2.1 Connection Establishment and Termination . . . . . . . . . 5
2.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Normal Operation . . . . . . . . . . . . . . . . . . . . . 6
2.4 DPI Architecture . . . . . . . . . . . . . . . . . . . . . 6
3. SNMP DPI PROTOCOL . . . . . . . . . . . . . . . . . . . . . 10
3.1 Connection Establishment . . . . . . . . . . . . . . . . 10
3.1.1 SNMP PDU to GET the Agent's DPI port . . . . . . . . . 11
3.1.2 SNMP PDU Containing the RESPONSE to the GET . . . . . 13
3.2 SNMP DPI Packet Formats . . . . . . . . . . . . . . . . 15
3.2.1 DPI Packet Header . . . . . . . . . . . . . . . . . . 15
3.2.2 OPEN . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 CLOSE . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 ARE_YOU_THERE . . . . . . . . . . . . . . . . . . . . 19
3.2.5 REGISTER . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.6 UNREGISTER . . . . . . . . . . . . . . . . . . . . . . 22
3.2.7 GET . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.8 GETNEXT . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.9 GETBULK . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.10 SET, COMMIT and UNDO . . . . . . . . . . . . . . . . 26
3.2.11 RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29
3.2.12 TRAP . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Constants and Values . . . . . . . . . . . . . . . . . . 33
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 1]
RFC 1592 SNMP-DPI March 1994
3.3.1 Protocol Version and Release Values . . . . . . . . . 33
3.3.2 Packet Type Values . . . . . . . . . . . . . . . . . . 34
3.3.3 Variable Type Values . . . . . . . . . . . . . . . . . 35
3.3.4 Value Representation . . . . . . . . . . . . . . . . . 36
3.3.5 Character set selection . . . . . . . . . . . . . . . 36
3.3.6 Error Code Values for SNMP DPI RESPONSE packets . . . 37
3.3.7 UNREGISTER Reason Codes . . . . . . . . . . . . . . . 40
3.3.8 CLOSE Reason Codes . . . . . . . . . . . . . . . . . . 41
4. DPI 2.0 MIB DEFINITION . . . . . . . . . . . . . . . . . . 41
5. SUBAGENT CONSIDERATIONS . . . . . . . . . . . . . . . . . . 42
5.1 DPI API . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Overview of Request Processing . . . . . . . . . . . . . 44
5.2.1 GET Processing . . . . . . . . . . . . . . . . . . . . 44
5.2.2 SET Processing . . . . . . . . . . . . . . . . . . . . 44
5.2.3 GETNEXT Processing . . . . . . . . . . . . . . . . . . 46
5.2.4 GETBULK Processing . . . . . . . . . . . . . . . . . . 47
5.2.5 OPEN Request . . . . . . . . . . . . . . . . . . . . . 48
5.2.6 CLOSE Request . . . . . . . . . . . . . . . . . . . . 49
5.2.7 REGISTER Request . . . . . . . . . . . . . . . . . . . 49
5.2.8 UNREGISTER Request . . . . . . . . . . . . . . . . . . 50
5.2.9 TRAP Request . . . . . . . . . . . . . . . . . . . . . 51
5.2.10 ARE_YOU_THERE request . . . . . . . . . . . . . . . . 51
5.2.11 How to query the DPI port. . . . . . . . . . . . . . 51
6. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . 51
7. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 52
8. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . 53
9. SAMPLE SOURCES FOR ANONYMOUS FTP . . . . . . . . . . . . . 54
1.
This RFC describes version 2.0 of a protocol that
Business Machines Corporation (IBM) has been implementing in most
its SNMP agents to allow dynamic extension of supported MIBs.
Northern Research (BNR) has also implemented a version of
protocol in some of its SNMP agents for the same reason
The Simple Network Management Protocol (SNMP [1])
Protocol Interface (DPI) is an extension to SNMP agents that
end-users to dynamically add, delete or replace management
in the local Management Information Base without
recompilation of the SNMP agent. This is achieved by writing a so
called sub-agent that communicates with the agent via the SNMP-DPI
For the author of a sub-agent, the SNMP-DPI eliminates the need
know the details of ASN.1 [2] or SNMP PDU (Protocol Data Unit
encoding/decoding [1, 3].
Versions 1.0 and 1.1 of this protocol have been in use within
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 2]
RFC 1592 SNMP-DPI March 1994
since 1989 and is included in the SNMP agents for VM, MVS and OS/2.
Version 1.2 of this protocol has been in use within BNR since 1992.
1.1
The Simple Network Management Protocol [1] defines a protocol
permits operations on a collection of variables. This set
variables is called the Management Information Base (MIB) and a
set of variables has previously been defined [4, 5]; however,
design of the MIB makes provision for extension of this core set
Thus, an enterprise or individual can define variables of their
which represent information of use to them. An example of
potentially interesting variable which is not in the core MIB
be CPU utilization (percent busy). Unfortunately, conventional
agent implementations provide no means for an end-user to
available new variables
Besides this, today there are many MIBs that people want to
on a system. Without a capability for sub-agents, this requires
the MIBs to be implemented in one big monolithic agent, which is
many cases undesirable
The SNMP DPI addresses these issues by providing a light-
mechanism by which a process can register the existence of a
variable or a MIB sub-tree with the SNMP agent. Requests for
variable(s) that are received by the SNMP agent are passed to
process acting as a sub-agent. The sub-agent then returns
appropriate answer to the SNMP agent. The SNMP agent
packages an SNMP response packet and sends the answer back to
remote network management station that initiated the request
Remote network management stations have no knowledge that the
agent calls on other processes to obtain an answer. As far as
can tell, there is only one network management application (agent
running on the host
At the San Diego IETF (March 1992) a BOF was held on
SNMP agent's requirements. Both the SMUX [6] and DPI [7]
were discussed, as well as other unpublished approaches. There
also discussion regarding a need for a standard for multiplexing
agents or sub-agent support. At the end of the BOF, however,
was not enough support for defining a standard. This was due,
least partially, to a few well known SNMP authors who stated that
proxy and party support for SNMPv2 (SMP at the time) would solve
problem
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 3]
RFC 1592 SNMP-DPI March 1994
Nevertheless, questions continue to be raised about sub-agent
(both in SNMP and SNMP2 mail lists) in spite of both SNMPv2 [8]
on the standard's track and SMUX being changed to a historic RFC
Furthermore, within IBM and BNR we continue to see a substantial
expanding use of the DPI protocol. with positive results
Therefore, we believe that there is a place for a sub-agent
and we again offer this new version as an experimental protocol.
encourage people to try it and send us feedback. Depending on
feedback, we may decide to try to get onto the standards track at
later time
During discussions about sub-agent interfaces at the San Diego BOF
also became clear that we should reduce the focus on the API for
sub-agent programmers. This RFC, therefore, specifies only
protocol to distribute SNMP requests from the main SNMP agent to
sub-agents. Programmers can build one or more Programming APIs
top of that protocol as needed, and sample API code is available
the authors of this document
1.2 SUMMARY OF
The following changes have been made since the initial definition
SNMP-DPI [7]. Some of these resulted from comparing the SMUX [6]
DPI [7] protocols
o Documentation changes to cleanup and be more specific in
areas. Among other things, this includes
- Defining that integers are in network byte
- Defining the character set used for
- Defining how DisplayStrings are handled
- Including DPI20 MIB definition
o Removal of the Programming API from the document
o Addition of new DPI packet types
- SNMP_DPI_OPEN for a sub-agent to open a "connection"
the DPI SNMP capable agent. The sub-agent must
identify itself and optionally provide a "password" for
connection
- SNMP_DPI_CLOSE for the agent or sub-agent to close
connection in a graceful way
- SNMP_DPI_ARE_YOU_THERE for the sub-agent to verify that
agent still knows about the sub-agent
- SNMP_DPI_UNREGISTER for the agent or sub-agent to
the registration of a MIB variable or MIB sub-tree
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 4]
RFC 1592 SNMP-DPI March 1994
- SNMP_DPI_COMMIT which instructs the sub-agent to
commit a previous SNMP_DPI_SET request. This,
with the UNDO, allows DPI sub-agents to be compliant
SNMP in the sense that we can now handle the "as
simultaneous" requirement
- SNMP_DPI_UNDO which instructs the sub-agent to UNDO a
or COMMIT if such is needed
o Changes to DPI packets
- Multiple varBinds can now be exchanged in one DPI
(for GET, GETNEXT, SET, TRAP). The sub-agent can
the maximum it wants to handle per packet
- The packet headers now contain a packet-ID (similar to
request ID in SNMP PDU). This allows to match
packets to REQUESTS, which is important for UDP
DPI-connections
- The SNMP_DPI_REGISTER packet has new fields for time_
and for requested priority
- The SNMP_DPI_TRAP packet allows to specify an
OID. In addition, the generic and specific trap types
now 4 octets, so that we can pass the types correctly
- In general, the packets have a more consistent layout
o The agent now sends a RESPONSE to a REGISTER
o Addition of SNMPv2 error codes and value types
2. THEORY OF
2.1 CONNECTION ESTABLISHMENT AND
Communication between the SNMP Agent and its clients (sub-agents
takes place via a communication mechanism. The communication
can be either a logical stream connection (via TCP, for instance)
an unreliable datagram connection (UDP, for instance). It should
noted that other stream oriented transport communication
can also be used. For example, the VM SNMP agent allows
connections over IUCV (Inter-User Communications Vehicle) [9, 10].
Other than the connection establishment procedure, the protocol
is identical in these environments
In Unix the number of processes is limited by the number of file
descriptors that can be opened. Since each TCP socket represents
file-descriptor, restricting SNMP-DPI protocol to TCP
connections would limit the number of sub-agents an agent
support. As a result, the some SNMP-DPI agents support both TCP
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-
agent is referred simply as the agent
Once the transport connection has been set up, the sub-agent
also initialize the logical connection with the agent. To do so
issues an OPEN request to the agent in which the sub-agent
identifies itself and passes some other parameters to the agent,
as, the maximum number of varBinds per interaction it is prepared
handle, and the timeout the agent should use when waiting for
response from the sub-agent
When the sub-agent prepares to stop or cease operations, it
issues a CLOSE to shut down the logical connection with the agent
and then closes the transport connection
2.2
A sub-agent supports a collection of MIB variables or
identifiers (object IDs) that constitute its MIB (sub)tree. Each
these object IDs consists of a group ID and an instance ID.
group ID is the root of the sub-agent's MIB tree that it supports
the point of registration to the agent's MIB tree. The instance
is the piece of the Object Identifier that follows the group
(registration point), so it is not an instance in the terms of
SNMP definition of an instance
Regardless of the transport mechanism used, after establishing
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
timeout value for this specific sub-tree
The agent sends back a response to indicate success or failure of
registration request
2.3 NORMAL
Once the sub-agent has set up both the physical and
connection to the agent, and once it has successfully registered
sub-tree(s) of the MIB(s) that it supports, it waits for
from the SNMP agent or generates traps as required
2.4 DPI
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
network management station can make (By default a GETBULK
will be translated into multiple GETNEXT requests by the agent, but
sub-agent may request that the GETBULK be passed to it). The COMMIT
UNDO, UNREGISTER, ARE_YOU_THERE and CLOSE requests are
SNMP-DPI requests. The sub-agent normally responds to a request
a RESPONSE packet. The CLOSE request is an exception for which
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_
with a RESPONSE packet. The TRAP packet is just accepted
forwarded by the agent without returning any information to the sub
agent. The CLOSE packet is also just accepted by the agent
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
| | GetNext |
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
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
standard SNMP protocol
o The SNMP agent communicates with some statically linked-
instrumentation (potentially for the MIB II), which in
talks to the TCP/IP layers and kernel (operating system) in
implementation-dependent manner
o An SNMP sub-agent, running as a separate process (
on another machine), can set up a connection with the agent
The sub-agent has an option to communicate with the SNMP
through UDP or TCP sockets, or even through other mechanisms
o Once the connection is established, the sub-agent issues a
OPEN and one or more REGISTER requests to register one or
MIB sub-trees with the SNMP agent
o The SNMP agent responds to DPI OPEN and REGISTER requests
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
object in a sub-tree registered by a sub-agent, it sends
corresponding DPI packet to the sub-agent
If the request is for a GetBulk, then the agent translates
into multiple DPI GETNEXT packets and sends those to
sub-agent. However, the sub-agent can request (in the
packet) that a GETBULK be passed to the sub-agent
If the request is for a Set, then the agent uses a 2-
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
sends it back to the requesting SNMP manager
o If the sub-agent wants to report an important state change,
sends a DPI TRAP packet to the SNMP agent which will encode
into an SNMP trap packet and send it to the manager(s).
o If the sub-agent wants to stop operations, it sends a
UNREGISTER and a DPI CLOSE packet to the agent. The
sends a response to an UNREGISTER request
o There is no RESPONSE to a CLOSE, the agent just closes the
connection. A CLOSE implies an UNREGISTER for
registrations that exist for the DPI connection being CLOSED
o An agent can send DPI UNREGISTER (if a higher
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
indicate it is terminating the DPI connection
o A sub-agent can send an ARE_YOU_THERE to verify that
"connection" is still open. If so, the agent sends a
with no error, otherwise, it may send a RESPONSE with an
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 9]
RFC 1592 SNMP-DPI March 1994
indication, or not react at all
3. SNMP DPI
This section describes the actual protocol used between the
agent and sub-agents
3.1 CONNECTION
In a TCP/IP environment, the SNMP agent listens on an
TCP/UDP port for a connection request from a sub-agent. It
important to realize that a well-known port is not used:
invocation of the SNMP agent will potentially result in a
TCP/UDP port being used
A sub-agent needs to determine this port number to establish
connection. The sub-agent learns the port number from the agent
sending it one conventional SNMP get-request PDU. The port
are maintained by the SNMP agent as the objects whose
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-
tree. See 4, "DPI 2.0 MIB definition" for more information.
SNMP agent replies with a conventional SNMP response PDU
contains the port number to be used. This response is examined
the sub-agent and the port number is extracted. The sub-agent
establishes the connection to the specified port
On the surface, this procedure appears to mean that the sub-
must be able to create and parse SNMP packets, but this is not
case. A DPI Application Programming Interface (API)
provides a library routine, query_DPI_port(), which can be used
generate and parse the required SNMP packets. This very
routine (under 100 lines of C), does not greatly increase the size
any sub-agent
NOTE: Since this RFC does not define an API, the actual code of
interface to a query_DPI_port() type of function depends on
implementation
For completeness, byte-by-byte descriptions of the packets to
generated by an SNMP DPI API routine query_DPI_port() are
below. This is probably of little interest to most readers
reading the source of a query_DPI_port() function provides much
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 10]
RFC 1592 SNMP-DPI March 1994
the same information
3.1.1 SNMP PDU TO GET THE AGENT'S DPI
As noted, before a TCP/UDP connection to the SNMP agent can be made
the sub-agent must learn which port that the agent is listening on
To do so, it can issue an SNMP GET for the variable dpiPortForTCP.0
(1.3.6.1.4.1.2.2.1.1.1.0) or variable dpiPortForUDP.0
(1.3.6.1.4.1.2.2.1.1.2.0).
The SNMP PDU can be constructed as shown below. This PDU must
sent to UDP port 161 on the host where the agent runs (probably
same host where the sub-agent runs).
The (SNMPv1) packet shown below is for the TCP port
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 11]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 1 (Page 1 of 2). SNMP GET PDU for dpiPortForTCP.0 |
+---------------+----------------+--------------------------------+
| OFFSET | VALUE | FIELD |
+---------------+----------------+--------------------------------+
| 0 | 0x30 | ASN.1 header |
+---------------+----------------+--------------------------------+
| 1 | 37 + len | PDU_length, see formula below |
+---------------+----------------+--------------------------------+
| 2 | 0x02 0x01 0x00 | SNMP version: |
| | | (integer,length=1,value=0) |
+---------------+----------------+--------------------------------+
| 5 | 0x04 | community name (string) |
+---------------+----------------+--------------------------------+
| 6 | len | length of community name |
+---------------+----------------+--------------------------------+
| 7 | community name | varies |
+---------------+----------------+--------------------------------+
| 7 + len | 0xa0 0x1c | SNMP GET request: |
| | | request_type=0xa0,length=0x1c |
+---------------+----------------+--------------------------------+
| 7 + len + 2 | 0x02 0x01 0x01 | SNMP request ID: |
| | | integer,length=1,ID=1 |
+---------------+----------------+--------------------------------+
| 7 + len + 5 | 0x02 0x01 0x00 | SNMP error status: |
| | | integer,length=1,error=0 |
+---------------+----------------+--------------------------------+
| 7 + len + 8 | 0x02 0x01 0x00 | SNMP index: |
| | | integer,length=1,index=0 |
+---------------+----------------+--------------------------------+
| 7 + len + 11 | 0x30 0x11 | varBind list, length=0x11 |
+---------------+----------------+--------------------------------+
| 7 + len + 13 | 0x30 0x0f | varBind, length=0x0f |
+---------------+----------------+--------------------------------+
| 7 + len + 15 | 0x06 0x0b | Object ID, length=0x0b |
+---------------+----------------+--------------------------------+
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 12]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 1 (Page 2 of 2). SNMP GET PDU for dpiPortForTCP.0 |
+---------------+----------------+--------------------------------+
| OFFSET | VALUE | FIELD |
+---------------+----------------+--------------------------------+
| 7 + len + 17 | 0x2b 0x06 0x01 | Object-ID: |
| | 0x04 0x01 0x02 | 1.3.6.1.4.1.2.2.1.1.1 |
| | 0x02 0x01 0x01 | Object-instance: 0 |
| | 0x01 0x00 | |
+---------------+----------------+--------------------------------+
| 7 + len + 28 | 0x05 0x00 | null value, length=0 |
+---------------+----------------+--------------------------------+
| NOTE: Formula to calculate "PDU_length": |
| |
| PDU_length = length of version field and string tag (4 bytes)|
| + length of community length field (1 byte) |
| + length of community name (depends...) |
| + length of SNMP GET request (32 bytes) |
| |
| = 37 + length of community name |
+-----------------------------------------------------------------+
3.1.2 SNMP PDU CONTAINING THE RESPONSE TO THE
Assuming that no errors occurred, the port is returned in the
few octets of the received packet. In the simple case, where
port number will be between 1024 and 16,385, the format of the
is shown below
Note: In practice, the port number can be any positive number in
range from 1 through 65,535. A port number of 0 means that the
does not have a dpiPort defined for the requested protocol. So
actual port value maybe in the last 1, 2 or 3 octets. The
implementation code shows how to handle the response to cover
those cases, including error conditions
Note: The (SNMPv1) packet shown below is for the TCP port
+-----------------------------------------------------------------+
| Table 2 (Page 1 of 3). SNMP RESPONSE PDU for dpiPortForTCP.0 |
+---------------+----------------+--------------------------------+
| OFFSET | VALUE | FIELD |
+---------------+----------------+--------------------------------+
| 0 | 0x30 | ASN.1 header |
+---------------+----------------+--------------------------------+
| 1 | 39 + len | length, see formula below |
+---------------+----------------+--------------------------------+
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 13]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 2 (Page 2 of 3). SNMP RESPONSE PDU for dpiPortForTCP.0 |
+---------------+----------------+--------------------------------+
| OFFSET | VALUE | FIELD |
+---------------+----------------+--------------------------------+
| 2 | 0x02 0x01 0x00 | version |
| | | (integer,length=1,value=0) |
+---------------+----------------+--------------------------------+
| 5 | 0x04 | community name (string) |
+---------------+----------------+--------------------------------+
| 6 | len | length of community name |
+---------------+----------------+--------------------------------+
| 7 | community name | |
+---------------+----------------+--------------------------------+
| 7 + len | 0xa2 0x1e | SNMP RESPONSE: |
| | | request_type=0xa2,length=0x1e |
+---------------+----------------+--------------------------------+
| 7 + len + 2 | 0x02 0x01 0x01 | SNMP request ID: |
| | | integer,length=1,ID=1 |
+---------------+----------------+--------------------------------+
| 7 + len + 5 | 0x02 0x01 0x00 | SNMP error status: |
| | | integer,length=1,error=0 |
+---------------+----------------+--------------------------------+
| 7 + len + 8 | 0x02 0x01 0x00 | SNMP index: |
| | | integer,length=1,index=0 |
+---------------+----------------+--------------------------------+
| 7 + len + 11 | 0x30 0x13 | varBind list, length=0x13 |
+---------------+----------------+--------------------------------+
| 7 + len + 13 | 0x30 0x11 | varBind, length=0x11 |
+---------------+----------------+--------------------------------+
| 7 + len + 15 | 0x06 0x0b | Object ID, length=0x0b |
+---------------+----------------+--------------------------------+
| 7 + len + 17 | 0x2b 0x06 0x01 | Object-ID: |
| | 0x04 0x01 0x02 | 1.3.6.1.4.1.2.2.1.1.1 |
| | 0x02 0x01 0x01 | Object-instance: 0 |
| | 0x01 0x00 | |
+---------------+----------------+--------------------------------+
| 7 + len + 28 | 0x02 0x02 | integer, length=2 |
+---------------+----------------+--------------------------------+
| 7 + len + 30 | MSB LSB | port number (MSB, LSB) |
+---------------+----------------+--------------------------------+
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 14]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 2 (Page 3 of 3). SNMP RESPONSE PDU for dpiPortForTCP.0 |
+---------------+----------------+--------------------------------+
| NOTE: Formula to calculate "PDU_length": |
| |
| PDU_length = length of version field and string tag (4 bytes)|
| + length of community length field (1 byte) |
| + length of community name (depends...) |
| + length of SNMP RESPONSE (34 bytes) |
| |
| = 39 + length of community name |
+-----------------------------------------------------------------+
3.2 SNMP DPI PACKET
Each request to, or response from, the agent or sub-agent
constructed as a "packet" and is written to the stream
Each packet is prefaced with the length of the data remaining in
packet. The length is stored in network byte order, the
significant byte (MSB) first, least significant byte (LSB) last.
we consider a stream connection (like TCP), the receiving side
read the packet by doing something similar to
unsigned char len_bfr[2];
unsigned char *bfr
int len
read(fd,len_bfr,2);
len = len_bfr[0] * 256 + len_bfr[1];
bfr = malloc(len);
read(fd,bfr,len);
Note: The above example makes no provisions for error handling or
read returning less than the requested amount of data,and it is
intended to be used literally
3.2.1 DPI PACKET
The first part of every packet identifies the application
being used as well as some version information. The protocol
version is intended to indicate, in broad terms, what version of
protocol is used. The protocol minor version is intended to
major incompatible versions of the protocol. The protocol release
intended to indicate incremental modifications to the protocol.
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.
contains packet identification that can help an agent or sub-
match responses with request. This is useful with UDP
over which packets can be lost. The packet ID is a
increasing unsigned 16-bit integer which wraps at its maximum value
The next field, present in all packets, is the packet type.
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
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
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
In order for a sub-agent to communicate with a DPI capable
agent, it must first send an SNMP DPI OPEN request to the agent
setup the "connection" with that agent
Such a packet contains the standard SNMP DPI header plus
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
for objects for which there is no timeout value specified
the sub-tree under which the object is registered. If
specify a zero timeout value, then the agent will use its
default timeout value. If you want a larger value than
default value, then you can specify it here. However, the
may have a maximum value that you can never exceed. If you
ask for a larger timeout than that maximum, the agent will
it at the maximum it accepts
o the maximum number of varBinds per DPI packet that
sub-agent is prepared to handle
o Selected character set to be used for the representation of
OBJECT ID strings and DisplayStrings
The choices are the native character set (0) or the
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
identifier, so in dotted ASN.1 notation. This string
represented in the selected character set
o null terminated sub-agent description, which is a
describing the sub-agent. This string is represented in
selected character set. This may be the null-string if
is no description
o optionally a password that the agent uses to validate
sub-agent. It depends on the agent implementation if
password is required. If no password is passed, the
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
request
If the error_code in the RESPONSE is not SNMP_ERROR_DPI_noError,
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
In order for a sub-agent to close the "connection" with the
capable SNMP agent, it must send an SNMP DPI CLOSE request to
agent. The agent will not send a response, but closes the
connection and implicitly unregisters any sub-trees related to
connection
An agent may also send to the sub-agent an SNMP DPI CLOSE packet
contains the standard SNMP DPI header plus CLOSE specific data.
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
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_
An ARE_YOU_THERE packet allows a sub-agent to determine if it
has a DPI connection with the agent. This packet is
because a sub-agent passively awaits requests from an agent
normally will not detect problems with an agent connection in
timely manner. (In contrast, an agent becomes aware of any sub-
connection problem in a timely manner because it sets a timeout
sending request).
A sub-agent can send a SNMP DPI ARE_YOU_THERE packet to an
which will then return a RESPONSE with a zero error code and a a
error index if the connection is healthy. Otherwise, the agent
return a RESPONSE with an error indication. If the connection
broken, the sub-agent will see no response at all
An ARE_YOU_THERE packet contains the standard SNMP DPI header with
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
In order to register a branch in the MIB tree, an SNMP sub-
sends an SNMP DPI REGISTER packet to the agent
Such a packet contains the standard SNMP DPI header plus
specific data. This data consists of
o a requested priority
There are 2 special values, namely minus one (-1, requests
available priority) and zero (0, requests next better
than the highest priority in use). Any other value requests
specific priority or the next best priority if already in use).
The lower the number, the better the priority. An agent
send requests to only the one sub-agent that has
with the best priority. The agent returns the actual
assigned in the RESPONSE packet in the error_index field
o a requested timeout
If a zero value is specified, then the agent uses the
value specified in the DPI OPEN request
If you want a shorter or longer timeout value for this
sub-tree, then you specify it here. The agent has a
timeout it will allow in this field. The agent will use
value (or its maximum) to await a response to requests for
sub-tree
o an indication as to whether the sub-agent wishes to handle
view selection (SNMPv1 community string authentication
in subsequent GET, GETNEXT or SET, COMMIT, UNDO requests.
all DPI capable agents need to support this feature, but
must at least recognize this indication and give an
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 20]
RFC 1592 SNMP-DPI March 1994
response if they do not support it
o an indication as to whether the sub-agent wishes to handle
GETBULK itself. If not, then the agent will translate
GETBULK into multiple GETNEXT requests
Not all DPI capable agents need to support this feature.
may opt to always translate a GETBULK into multiple
requests. In this case the agent will send the
RESPONSE to indicate this
o the group ID (sub-tree) to be registered (with trailing dot).
The group ID is represented in the selected character set
specified in DPI OPEN packet
The agent will respond with an SNMP DPI RESPONSE packet
registration error or success. The packet ID of the response will
the same as that for the REGISTER request to which this is
response
The group ID will be the same as that specified in the
request. There will be no instance returned (e.g. NULL string
instance ID). The value will be an SNMP_TYPE_NULL value with a
length
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 21]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 7. Layout SNMP DPI REGISTER 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_REGISTER |
+------------+----------------------------------------------------+
| 8 | requested priority (MSB to LSB) |
+------------+----------------------------------------------------+
| 12 | timeout in seconds (MSB to LSB) |
+------------+----------------------------------------------------+
| 14 | view selection (0 = you (agent) do, 1 = I do) |
+------------+----------------------------------------------------+
| 15 | getbulk selection (0=use GetNext, 1=use GetBulk) |
+------------+----------------------------------------------------+
| 16 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o group ID string uses selected character set |
+-----------------------------------------------------------------+
3.2.6
In order to unregister a branch in the MIB tree, an SNMP sub-
sends an SNMP DPI UNREGISTER packet to the agent
Such a packet contains the standard SNMP DPI header plus
specific data: a null terminated string (represented in the
character set) representing the group ID in ASN.1 dotted notation
an indication as to the reason for the unregister (see table 14).
The agent will respond with an SNMP DPI RESPONSE packet
error or success. The packet ID of the response will be the same
that for the UNREGISTER request to which this is a response
The group ID will be the same as that specified in the
request. There will be no instance returned (e.g. NULL string
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 22]
RFC 1592 SNMP-DPI March 1994
instance ID). The value will be an SNMP_TYPE_NULL value with a
length
+-----------------------------------------------------------------+
| Table 8. Layout SNMP DPI UNREGISTER 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_UNREGISTER |
+------------+----------------------------------------------------+
| 8 | reason code |
+------------+----------------------------------------------------+
| 9 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o group ID string uses selected character set |
+-----------------------------------------------------------------+
3.2.7
When the SNMP agent receives a PDU containing an SNMP GET request
a variable that resides in a sub-tree registered by a sub-agent,
passes an SNMP DPI GET packet to the sub-agent
Such a packet contains the standard SNMP DPI header plus GET
data
o the community name used in the SNMP PDU. The length is
unless view handling was selected by the sub-agent. The
is also zero if the SNMP PDU was not in SNMPv1 format
o per varBind two null terminated strings (in the
character set) representing the group and instance ID in ASN.1
dotted notation
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 23]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 9. Layout SNMP DPI GET 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_GET |
+------------+----------------------------------------------------+
| 8 | community name length (MSB to LSB) |
+------------+----------------------------------------------------+
| 10 | community name (if any) |
+------------+----------------------------------------------------+
| 10+L1 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| 10+L2 | null terminated instance ID (no trailing dot) |
+------------+----------------------------------------------------+
| 10+L3 | optionally more varBinds (group/instance ID pairs) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o L1 = length of community name |
| o L2 = L1 + strlen(group ID) + 1 |
| o L3 = L2 + strlen(instance ID) + 1 |
| o group and instance ID strings use selected character set |
+-----------------------------------------------------------------+
3.2.8
When the SNMP agent receives a PDU containing an SNMP GETNEXT
for a variable for which a sub-agent may be authoritative, it
an SNMP DPI GETNEXT packet to the sub-agent
Such a packet contains the standard SNMP DPI header plus
specific data
o the community name used in the SNMP PDU. The length is
unless view handling was selected by the sub-agent. The
is also zero if the SNMP PDU was not in SNMPv1 format
o per varBind two null terminated strings (in the
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 24]
RFC 1592 SNMP-DPI March 1994
character set) representing the group and instance ID in ASN.1
dotted notation
+-----------------------------------------------------------------+
| Table 10. Layout SNMP DPI GETNEXT 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_GETNEXT |
+------------+----------------------------------------------------+
| 8 | community name length (MSB to LSB) |
+------------+----------------------------------------------------+
| 10 | community name |
+------------+----------------------------------------------------+
| 10+L1 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| 10+L2 | null terminated instance ID (no trailing dot) |
+------------+----------------------------------------------------+
| 10+L3 | optionally more varBinds (group/instance ID pairs) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o L1 = length of community name |
| o L2 = L1 + strlen(group ID) + 1 |
| o L3 = L2 + strlen(instance ID) + 1 |
| o group and instance ID strings use selected character set |
+-----------------------------------------------------------------+
3.2.9
When the SNMP agent receives a PDU containing an SNMP GETBULK
that includes variables for which a sub-agent may be authoritative
it checks if the sub-agent wants to handle the GETBULK itself (
specified at registration time). If so, it sends an SNMP DPI
packet to the sub-agent
Such a packet contains the standard SNMP DPI header plus
specific data
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 25]
RFC 1592 SNMP-DPI March 1994
o non-
o max
o per varBind two null terminated strings (in the
character set) representing the group and instance ID in ASN.1
dotted notation
+-----------------------------------------------------------------+
| Table 11. Layout SNMP DPI GETBULK 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_GETBULK |
+------------+----------------------------------------------------+
| 8 | non-repeaters (4 octets, MSB to LSB) |
+------------+----------------------------------------------------+
| 12 | max-repetitions (4 octets, MSB to LSB) |
+------------+----------------------------------------------------+
| 16 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| 16+L1 | null terminated instance ID (no trailing dot) |
+------------+----------------------------------------------------+
| 16+L2 | optionally more varBinds (group/instance ID pairs) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o L1 = strlen(group ID) + 1 |
| o L2 = L1 + strlen(instance ID) + 1 |
| o group and instance ID strings use selected character set |
+-----------------------------------------------------------------+
3.2.10 SET, COMMIT AND
When the SNMP agent receives a PDU containing an SNMP SET request
a variable that is in a sub-tree registered by a sub-agent, it
one of 3 sequences of SNMP DPI packets to the sub-agent
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 26]
RFC 1592 SNMP-DPI March 1994
o SET,
This is the normal sequence. The SET request is the
phase. The sub-agent must verify that the SET request is
and that the resources needed are available. The
request comes next. The sub-agent must now effectuate the
request
o SET,
If an SNMP packet has a SET request for multiple varBinds
reside in different sub-trees, then the agent first sends a
to all sub-agents. If any sub-agent returns an error on
SET, then the agent sends UNDO to those sub-agents
returned no error on the SET, meaning the SET is
canceled
o SET, COMMIT,
In the very rare circumstance where all sub-agents
responded error-free to a SET and where one of them fails
perform the COMMIT, then the agent sends an UNDO to
involved sub-agents (also those who completed COMMIT).
Sub-agents should try, to the best of their ability, to
let a commit fail and to undo an already committed set if
to do so
Such packets contain the standard SNMP DPI header plus SET
data
o the community name used in the SNMP PDU. The length is
unless view handling was selected by the sub-agent. The
is also zero if the SNMP PDU was not in SNMPv1 format
o per varBind
- two null terminated strings (in the selected character set
representing the group and instance ID in ASN.1
notation
- the type, value length and value to be set
The permitted types for the type field are defined in Table 17.
See 3.3.4, "Value Representation" for information on how
value data is represented in the packet value field
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 27]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 12. Layout SNMP DPI SET, COMMIT, UNDO 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_SET/COMMIT/UNDO |
+------------+----------------------------------------------------+
| 8 | community name length (MSB to LSB) |
+------------+----------------------------------------------------+
| 10 | community name |
+------------+----------------------------------------------------+
| 10+L1 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| 10+L2 | null terminated instance ID (no trailing dot) |
+------------+----------------------------------------------------+
| 10+L3 | SNMP Variable Type Value |
+------------+----------------------------------------------------+
| 10+L3+1 | Length of value (2 octets, MSB to LSB) |
+------------+----------------------------------------------------+
| 10+L3+3 | Value |
+------------+----------------------------------------------------+
| 10+L4 | optionally more varBinds (sequences of group ID, |
| | instance ID, Type, Length and Value) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o L1 = length of community name |
| o L2 = L1 + strlen(group ID) + 1 |
| o L3 = L2 + strlen(instance ID) + 1 |
| o L4 = L3 + 3 + length of value |
| o group and instance ID strings use selected character set |
| o OID and DisplayString values use selected character set |
| o Integer values are in network byte order |
+-----------------------------------------------------------------+
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 28]
RFC 1592 SNMP-DPI March 1994
3.2.11
An SNMP sub-agent must respond to a GET, GETNEXT, GETBULK, SET
COMMIT, UNDO or UNREGISTER request that it has received from
agent (unless it fails or has a bug ;-)). To do so, it sends an
DPI RESPONSE packet to the agent
Such a packet contains the standard SNMP DPI header plus
specific data
o an error_code
o an error_index
o plus for a successful GET, GETNEXT, or GETBULK,
name/type/length/value tuple(s) representing the
object(s). For each varBind this is described as
- two null terminated strings (in the selected character set
representing the group and instance ID in ASN.1
notation
- the type, value length and value of the object that
returned
The permitted types for the type field are defined in Table 17.
See 3.3.4, "Value Representation" for information on how
value data is represented in the packet value field
For an unsuccessful GET, GETNEXT or GETBULK, the sub-agent does
need to return any name/type/length/value tuple(s), because
definition, the varBind information is the same as in the request
which this is a response, and the agent still has that information
The group ID and the packet ID must always be the same as
corresponding fields in request PDU which has prompted the RESPONSE
If the response is to a SET, COMMIT or UNDO request, there is no
to return any varBind information, because by definition, the
information is the same as in the request to which this is
response, and the agent still has that information
If the response is to a REGISTER or UNREGISTER, no
(instance) is being returned, so the instance ID is the NULL
(one 0x00 byte). In the response to a REGISTER request
success, the error index contains the priority assigned by the agent
If the response is to an OPEN, ARE_YOU_THERE or CLOSE, no
data will be passed, so no group ID, instance ID or value data.
packet will only include the header, the error code and the
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 29]
RFC 1592 SNMP-DPI March 1994
index
+-----------------------------------------------------------------+
| Table 13. Layout SNMP DPI RESPONSE 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_RESPONSE |
+------------+----------------------------------------------------+
| 8 | error code (1 octet) |
+------------+----------------------------------------------------+
| 9 | error index (4 octets, MSB to LSB) |
+------------+----------------------------------------------------+
| 15 | null terminated group ID (with trailing dot) |
+------------+----------------------------------------------------+
| 15+L1 | null terminated instance ID (no trailing dot) |
+------------+----------------------------------------------------+
| 15+L2 | SNMP Variable Type Value |
+------------+----------------------------------------------------+
| 15+L2+1 | Length of value (MSB to LSB) |
+------------+----------------------------------------------------+
| 15+L2+3 | Value |
+------------+----------------------------------------------------+
| 15+L3 | optionally more varBinds (sequences of group ID, |
| | instance ID, Type, Length and Value) |
+------------+----------------------------------------------------+
| NOTE: |
| |
| o L1 = strlen(group ID) + 1 |
| o L2 = L1 + strlen(instance ID) + 1 |
| o L3 = L2 + 3 + length of value |
| o group and instance ID strings use selected character set |
| o OID and DisplayString values use selected character set |
| o Integer values are in network byte order |
+-----------------------------------------------------------------+
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 30]
RFC 1592 SNMP-DPI March 1994
3.2.12
An SNMP sub-agent can request the agent to generate an SNMPv1
SNMPv2 TRAP (depending on the trap destinations defined at the agent
by sending an SNMP DPI TRAP packet to the agent
Such a packet contains the standard SNMP DPI header plus
specific data
o the generic and specific trap
o optionally a null terminated string (in the selected
set) representing the enterprise ID in ASN.1 dotted notation
This enterprise ID will be sent with the TRAP. If the
string is passed, then the agent uses the sub-agent
(OID as passed with the DPI OPEN packet) as the Enterprise ID
o optionally a set of one or more name/type/length/value tuples
representing varBinds to be sent with the trap. Each
consists of
- two null terminated strings (in the selected character set
representing the group and instance ID in ASN.1
notation
- the type, value length and value of the object that
returned
The permitted types for the type field are defined in Table 17.
See 3.3.4, "Value Representation" for information on how
value data is represented in the packet value field
Wijnen, Carpenter, Curran, Sehgal & Waters [Page 31]
RFC 1592 SNMP-DPI March 1994
+-----------------------------------------------------------------+
| Table 14. Layout SNMP DPI TRAP packet |
+------------+----------------------------------------------------+
| OFFSET | FIELD |
+------------+----------------------------------------------------+
| 0 | packet length to follow (MSB to LSB) |
+------------+----------------------------------------------------+
| 2 | protocol major version |
+------------+----------------------------------------------------+
| 3 | protocol minor version |
+------------+----------------------------------------------------+
| 4 | protocol release |
+------------+----------------------------------------------------+
