📄 rfc2257.txt
字号:
the byte ordering of all multi-byte integer values in the PDU,
including those which follow in the header itself. This is described
in more detail in Section 6.1, "AgentX PDU Header", below.
PDUs are depicted in this memo using the following convention (where
byte 1 is the first transmitted byte):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte 1 | byte 2 | byte 3 | byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte 5 | byte 6 | byte 7 | byte 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
标记有“<reserved>”是保留域，必须用0填补
Fields marked "<reserved>" are reserved for future use and must be
zero-filled.
5.1. Object Identifier
对象标识符是一个有4byte的头的编码，这样的可变长度的4个byte的矩阵是可以连续
的有很多个的。如下：
An object identifier is encoded as a 4-byte header, followed by a
variable number of contiguous 4-byte fields representing sub-
identifiers. This representation (termed Object Identifier) is as
follows:
Object Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
标题字段解释：
Object Identifier header fields:
n_subid
标识sub-identifier有多少个。（0~128之间）
The number (0-128) of sub-identifiers in the object identifier.
An ordered list of "n_subid" 4-byte sub-identifiers follows the
4-byte header.
prefix
这位如果为0那么标识没有前缀。如果非0那么假设为“x”那么要加上默认的
“internet”前缀（1.3.6.1）1.3.6.1.x在这之后在加上sub-identifier
An unsigned value used to reduce the length of object
identifier encodings. A non-zero value "x" is interpreted as
the first sub-identifier after "internet" (1.3.6.1), and
indicates an implicit prefix "internet.x" to the actual sub-
identifiers encoded in the Object Identifier. For example, a
prefix field value 2 indicates an implicit prefix "1.3.6.1.2".
A value of 0 in the prefix field indicates there is no prefix
to the sub-identifiers.
include
仅用于当对象标识符用到SearchRange用到具体描述见5.2
Used only when the Object Identifier is the start of a
SearchRange, as described in section 5.2.
A null Object Identifier consists of the 4-byte header with all bytes
set to 0.
Examples:
sysDescr.0 (1.3.6.1.2.1.1.1.0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.2.3.4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 12]
RFC 2257 AgentX January 1998
5.2. SearchRange
SearchRange用于连接两个对象标识符，在与subagent建立通讯的时候，
master agent用SearchRange来确定请求比那两的绑定，并在GetNext和Getbulk
命令中，设置上一级托管对象的名字
A SearchRange consists of two Object Identifiers. In its
communication with a subagent, the master agent uses a SearchRange to
identify a requested variable binding, and, in GetNext and GetBulk
operations, to set an upper bound on the names of managed object
instances the subagent may send in reply.
第一对象标识符在一个searchrange （所谓的初始
的OID ）表示开始的范围。这是经常（但不包括
一定）的名称，要求的变量绑定。
The first Object Identifier in a SearchRange (called the starting
OID) indicates the beginning of the range. It is frequently (but not
necessarily) the name of a requested variable binding.
include值为0表示不包含，为1表示包含
The "include" field in this OID's header is a boolean value (0 or 1)
indicating whether or not the starting OID is included in the range.
The second object identifier indicates the non-inclusive end of the
range, and its "include" field is always 0.
Example: To indicate a search range from 1.3.6.1.2.1.25.2
(inclusive) to 1.3.6.1.2.1.25.2.1 (exclusive), the SearchRange would
be
(start)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 2 | 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A SearchRangeList is a contiguous list of SearchRanges.
Daniele, et. al. Standards Track [Page 13]
RFC 2257 AgentX January 1998
5.3. Octet String
An octet string is represented by a contiguous series of bytes,
beginning with a 4-byte integer whose value is the number of octets
in the octet string, followed by the octets themselves. This
representation is termed an Octet String. If the last octet does not
end on a 4-byte offset from the start of the Octet String, padding
bytes are appended to achieve alignment of following data. This
padding must be added even if the Octet String is the last item in
the PDU. Padding bytes must be zero filled.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A null Octet String consists of a 4-byte length field set to 0.
5.4. Value Representation
Variable bindings may be encoded within the variable-length portion
of some PDUs. The representation of a variable binding (termed a
VarBind) consists of a 2-byte type field, a name (Object Identifier),
and the actual value data.
VarBind
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v.type | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(v.name)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et. al. Standards Track [Page 14]
RFC 2257 AgentX January 1998
(v.data)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VarBind fields:
v.type
Indicates the variable binding's syntax, and must be one of
the following values:
Integer (2),
Octet String (4),
Null (5),
Object Identifier (6),
IpAddress (64),
Counter32 (65),
Gauge32 (66),
TimeTicks (67),
Opaque (68),
Counter64 (70),
noSuchObject (128),
noSuchInstance (129),
endOfMibView (130)
v.name
The Object Identifier which names the variable.
v.data
The actual value, encoded as follows:
- Integer, Counter32, Gauge32, and TimeTicks are encoded as
4 contiguous bytes. If the NETWORK_BYTE_ORDER bit is set
in h.flags, the bytes are ordered most significant to least
significant, otherwise they are ordered least significant
to most significant.
- Counter64 is encoded as 8 contiguous bytes. If the
NETWORK_BYTE_ORDER bit is set in h.flags, the bytes are
ordered most significant to least significant, otherwise
they are ordered least significant to most significant.
Daniele, et. al. Standards Track [Page 15]
RFC 2257 AgentX January 1998
- Object Identifiers are encoded as described in section
5.1, Object Identifier.
- IpAddress, Opaque, and Octet String are all octet strings
and are encoded as described in section 5.3, Octet String.
Value data always follows v.name whenever v.type is one
of the above types. These data bytes are present even if
they will not be used (as, for example, in certain types
of index allocation).
- Null, noSuchObject, noSuchInstance, and endOfMibView do not
contain any encoded value. Value data never follows
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -