标识域指明数据的类型,占用1个字节,常见的类型有:BOOL(0x01);INT(0x02);OCTSTR(0x04);NULL(0x05);OBJID(0x06);ENUM(0x0A);SEQ(0x30);SETOF(0x31);IPADDR(0x40);COUNTER(0x41);GAUGE(0x42);TIMETICKS(0x43);OPAQUE(0x44)。
长度域指明值域的长度,不定长,一般为一到三个字节。其格式可分为短格式（后面的值域没有超过127长）和长格式,如下所示
短格式的表示方法：
|
0（1bit） |
长度（7bit） |
长格式的表示方法：
|
1（1bit） |
K（7bit） |
K个八位组长度（K Byte） |
例:
length=30=>1E（30没有超过127，长度域为0001 1110）
length=169=>81 A9（169超过127，长度域为 1000 0001 1010 1001，169是后9位的值，前八位的第一个1表示这是长格式的表示方法，前八位的后七位表示后面有多少个字节表示针对的长度，这里，是000 0001，后面有一个字节表示真正的长度，1010 1001是169，后面的值有169个字节长。）
length=1500=>82 05 DC（1000 0010 0000 0101 1101 1100，先看第一个字节，表示长格式，后面有2个字节表示长度，这两个字节是0000 0101 1101 1100 表示1500）
integer::=0x02 length{byte}*(*表示重复)
整型数据值域用补码表示,去掉多余的零(正数)或一(负数)。值域最高位为符号位。例:
1500=>02 02 05 DC21500=>02 02 FA 24
SNMP服务器维护的所有管理信息库(MIB)对象采用ObjectID表示,如,1.3.6.1.2.1.1.1表示MIB库中的设备描述SysDesc变量,其编码规则如下:
objectID::=0x06 length {subidentifier}* (1)
subidentifier::= {leadingbyte}* lastbyte (2)
leadingbyte::=1 7bitvalue (3)
lastbyte::=0 7bitvalue (4)
首两个ID被合并为一个字节X*40+Y (5)
虽然规则很多,但由于大多数子对象标识在0～127,只需按规则(1)、(5)即可;
当子对象标识大于127,则按规则(2)、(3)、(4)将其分解为多个字节,最后一个字节的高位为零,其余字节的高位为一。如:1.3.6.1.810.1,根据规则(5),首两个子对象标识1.3被合并为2B(1 3 40+3=43);
子对象标识810超过127,根据规则(2)、(3)、(4)将其拆分为两个字节86 2A (810=11 0010 1010==>1000 0110 0010 1010);
整个MIB被编码为:0x06 0x06 0x2b 0x06 0x01
0x86 0x2a 0x01。
sequence::=0x30 length{asndata}*
如:30 05 02 01 10 05 00表示一个sequence结构,内含两个成员,其中一个为整型,另一个为空类型(NULL)。
null::=0x05 0x00
string::=0x04 length{byte}*
例如：04 06 70 75 62 6c 69 63表示字符串public
实例：
30 3c 02 01 00 04
06 70 75 62 6c 69 63 a2 2f 02 01 10 02 01 00 02
01 00 30 24 30 22 06 08 2b 06 01 02 01 01 01 00
04 16 53 54 41 52 20 53 77 69 74 63 68 20 53 32
38 30 30 20 56 34 2e 30
根据第2节BER编码规则和3.1节SNMP数据报格式,我们对数据进行分解:
SNMP Length=60<=30 3c
Version=1<=02 01 00
Community=public<=04 06 70 75 62 6c 69 63
PDU Type=Get response length=2f<=a2 2f
Request ID=6<=02 01 10
Error status=(No error)<=02 01 00
Error index=0<=02 01 00
Variable List length=24<=30 24
Item1 Length=22<=30 22
Object={1.3.6.1.2.1.1.1.0}<=06 08 2b 06 01 02 01 01 01 00
Value=STAR Switch S2800 V4.0<=04 16 53 54 41 52 20…
整个报文的含义为SNMP GetReply sysDescr=
STAR Switch S2800 V4.0
驻留在被管设备上的AGENT从UDP端口161接受来自网管站的串行化报文，经解码、团体名验证、分析得到管理变量在MIB树中对应的节点，从相应的模块中得到管理变量的值，再形成响应报文，编码发送回网管站。网管站得到响应报文后，再经同样的处理，最终显示结果。
下面根据RFC1157详细介绍Agent接受到报文后采取的动作：
首先解码生成用内部数据结构表示的报文，解码依据ASN.1的基本编码规则，如果在此过程中出现错误导致解码失败则丢弃该报文，不做进一步处理。
第二步：将报文中的版本号取出，如果与本Agent支持的SNMP版本不一致，则丢弃该报文，不做进一步处理。当前北研的数据通信产品只支持SNMP版本1。
第三步：将报文中的团体名取出，此团体名由发出请求的网管站填写。如与本设备认可的团体名不符，则丢弃该报文，不做进一步处理，同时产生一个陷阱报文。SNMPv1只提供了较弱的安全措施，在版本3中这一功能将大大加强。
第四步：从通过验证的ASN.1对象中提出协议数据单元PDU，如果失败，丢弃报文，不做进一不处理。否则处理PDU，结果将产生一个报文，该报文的发送目的地址应同收到报文的源地址一致。
第一种情况：如果PDU中的变量名在本地维护的MIB树中不存在,则接受到这个PDU的协议实体将向发出者发送一个GetResponse报文，其中的PDU与源PDU只有一点不同：将ERROR-STATUS置为noSuchName,并在ERROR-INDEX中指出产生该变量在变量LIST中的位置。
第二种情况：如果本地协议实体将产生的响应报文的长度大于本地长度限制，将向该PDU的发出者发送一个GetResponse报文，该PDU除了ERROR-STATUS置为tooBig，ERROR-INDEX置为0以外，与源PDU相同。
第三种情况：如果本地协议实体因为其他原因不能产生正确的响应报文，将向该PDU的发出者发送一个GetResponse报文，该PDU除了ERROR-STATUS置为genErr，ERROR-INDEX置为出错变量在变量LIST中的位置，其余与源PDU相同。
第四中情况：如果上面的情况都没有发生，则本地协议实体向该PDU的发出者发送一个GetResponse报文，该PDU中将包含变量名和相应值的对偶表，ERROR-STATUS为noError,ERROR-INDEX为0，request-id域的值应与收到PDU的request-id相同。
GetNextRequest PDU的最重要的功能是表的遍历，这种操作受到了前面所说的管理变量的表示方法的支持，从而可以访问一组相关的变量，就好象他们在一个表内。
下面通过一个例子解释表遍历的过程：
被管设备维护如下路由表：
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
假设网管站欲取得这张路由表的信息，该表的索引是目的网络地址。
网管站向被管设备发送一个GetNextRequest PDU,其中的受管对象的标识如下
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
SNMP agent响应如下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 ))
网管站继续：
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
agent响应：
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 ))
值得注意的是agent必须能够确定下一个管理变量名，以保证所有变量能被取到且只被取到一次。
网管站继续：
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
agent 响应：
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 ))
网管站继续
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
这时因为路由表中所有的行都被取遍，agent因返回路由表对象的下一字典后继即该管理对象在MIB树中的后序遍历的直接后继。这里应是nettoMediaIndex，管理对象的OBJECT IDENTIFIER。这个响应通知网管站对表的遍历已经完成。
GetResponse PDU只有当受到getRequest GetNextRequest SetRequest才由协议实体产生，网管站收到这个PDU后，应显示其结果。
SetRequest PDU除了PDU类型标识以外，和GetRequest相同，当需要对被管变量进行写操作时，网管站侧的协议实体将生成该PDU。
对SetRequest的响应将根据下面情况分别处理：
1． 如果是关于一个只读变量的设置请求，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为noSuchName, error index的值是错误变量在变量list中的位置。
2． 如果被管设备上的协议实体收到的PDU中的变量对偶中的值，类型、长度不符和要求，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为badValue, error index的值是错误变量在变量list中的位置。
3． 如果需要产生的GetReponse报文长度超过了本地限制，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为tooBig, error index的值是0。
4． 如果是其他原因导致SET失败，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为genErr, error index的值是错误变量在变量list中的位置。
如果不符合上面任何情况，则agent将把管理变量设置收到的PDU中的相应值，这往往可以改变被管设备的运行状态。同时产生一个GetResponse PDU，其中error status置为noError,error index的值为0。
Trap PDU的有如下的形式
|
产生trap的系统的OBJECT IDENTIFIER |
|
系统的IP地址 |
|
普通类型 |
|
特定类型 |
|
时戳 |
|
变量对偶表 |
Trap是被管设备遇到紧急情况时主动向网管站发送的消息。网管站收到trap PDU后要将起变量对偶表中的内容显示出来。一些常用的trap类型有冷、热启动，链路状态发生变化等。