CN101035133A

CN101035133A - 网络管理的方法、系统及设备

Info

Publication number: CN101035133A
Application number: CN 200710090876
Authority: CN
Inventors: 杨涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-04-09
Filing date: 2007-04-09
Publication date: 2007-09-12
Anticipated expiration: 2027-04-09
Also published as: CN101035133B

Abstract

本发明涉及一种网络管理的方法、系统及设备。该方法包括：接收简单网络管理协议消息；根据该简单网络管理协议消息中携带场景信息的对象识别符确定要访问的场景；在所述确定的场景内执行与该简单网络管理协议消息相应的操作。本发明能够应用于使用SNMP各种版本的网络管理系统，使得管理站通过代理对各种类型的多个网元实现有效管理。

Description

网络管理的方法、系统及设备

技术领域

本发明涉及通信技术领域，尤其涉及一种网络管理的方法、系统及设备。

背景技术

随着网络技术的飞速发展，网络中设备的数量也越来越多，而网络设备来自各个不同的厂家，如何管理这些设备就变得十分重要。

SNMP(Simple Network Management Protocol，简单网络管理协议)是由IETF(Internet Engineering Task Force，互联网工程任务组)定义的一套网络管理协议。利用SNMP，一个管理站可以远程管理所有支持这种协议的网络设备，包括监视网络状态、修改网络设备配置、接收网络警告等。

如图1所示，在SNMP管理模型中有三个基本组成部分：管理站(SNMPManager)100，代理(SNMP Agent)101和MIB(Management Information Base，管理信息库)102。SNMP Manager一般是一个单机设备或一个共享网络中的一员，将网络管理员的命令转换成对远程网络设备的监视和控制。SNMP Agent指的是用于跟踪监测被管理设备状态的特殊软件或硬件，每个SNMP Agent都拥有自己本地的MIB。MIB是一个树形结构，定义了可访问的网络设备及其属性，并通过OID(Object Identifier，对象识别符)唯一标识。实际上，SNMPManager的管理任务是移交给SNMP Agent来执行的。SNMP Agent翻译来自SNMP Manager的请求，验证操作的可执行性，通过对MIB树形目录中的节点即OID的读写来访问网络中的设备，执行信息处理任务，同时向SNMPManager返回响应信息。

SNMP Agent和SNMP Manager之间通过SNMP消息进行通信，每个SNMP消息都是一个单独的数据报。但是SNMP消息的格式随着SNMP版本的不同而不同。例如SNMP V1或者V2c(SNMP第一版或者第二版)消息包含三个部分：版本域201、团体域202、以及PDU(Protocol Data Unit，协议数据单元)域203，如图2所示。其中，版本域201，用于说明现在使用的是哪个版本的SNMP协议；团体域202，用于实现SNMP Manager访问SNMPAgent时的身份验证；PDU 203指明了SNMP消息的类型及其相关参数。再例如SNMP V3(SNMP第三版)消息包含两个部分：消息头和PDU，消息头中包含更丰富的信息，例如加密参数、认证参数、场景名等，以实现复杂的加密、认证和权限控制等功能。而PDU的类型也随着SNMP版本的不同而不同。例如，SNMP V1的PDU有五种类型，即Get-request(从代理进程处提取一个或多个参数值)、Get-next-request(从代理进程处提取一个或多个参数的下一个参数值)、Set-request(设置代理进程的一个或多个参数值)、Get-response(返回一个或多个参数值)和Trap(代理进程主动发出的报文)。SNMP V2c的PDU在SNMP V1基础上增加了两种类型，即Get-bulk-request(批量查询)和inform-request(代理之间的通信)。而SNMP V3的PDU与SNMP V2c的PDU是一样的。

在实现本发明过程中，发明人发现现有技术是对相同SNMP版本单一网元进行简单管理，而对于能够应用SNMP各个版本的复杂而庞大的通信系统而言，一个SNMP Agent往往要管理多个独立的系统或者设备(以下统称为ME(Managed Element，网元))，由于受到被管理的网元类型复杂、数量繁多，以及不同SNMP版本的MIB结构也不尽相同等诸多因素的影响，现有技术无法实现对众多网元的有效管理。

发明内容

本发明实施例提供一种网络管理的方法、系统及设备，能够对应用SNMP各个版本的通信系统中各种类型的多个网元实现有效的管理。

本发明实施例提供以下技术方案：

一种网络代理设备，包括：

接收单元，用于接收来自网络管理设备的简单网络管理协议消息；

第一识别单元，用于根据所述接收单元接收的简单网络管理协议消息中携带场景信息的对象识别符确定要访问的场景；

执行单元，用于在所述第一识别单元确定的场景内执行与该简单网络管理协议消息相应的操作。

一种网络管理设备，包括：

消息生成单元，用于生成简单网络管理协议消息，该简单网络管理协议消息中携带场景信息的对象识别符；

发送单元，用于将所述消息生成单元生成的简单网络管理协议消息发送出去。

一种网络管理的方法，包括以下步骤：

接收简单网络管理协议消息；

根据该简单网络管理协议消息中携带场景信息的对象识别符确定要访问的场景；

在所述确定的场景内执行与该简单网络管理协议消息相应的操作。

一种网络管理的方法，包括以下步骤：

生成简单网络管理协议消息，该简单网络管理协议消息中携带场景信息的对象识别符；

将所述的简单网络管理协议消息发送出去。

一种网络管理的系统，包括网络管理设备和网络代理设备，其中：

所述网络管理设备包括：

发送单元，用于将所述消息生成单元生成的简单网络管理协议消息发送出去；

所述网络代理设备包括：

本发明实施例能够应用于使用简单网络管理协议各种版本的通信系统，网络代理设备根据网络管理设备发送的简单网络管理协议消息中携带场景信息的对象识别符确定要访问的场景，进而在该场景内执行与该简单网络管理协议消息相应的操作，从而可以实现对各种类型各个版本的多个网元进行有效管理。

下面结合附图和具体实施方式对本发明作进一步描述。

附图说明

图1为现有技术中SNMP管理模型示意图；

图2为现有技术中SNMP V1或者V2c消息结构示意图；

图3为本发明实施例网络管理的系统示意图；

图4为本发明实施例Context的划分示意图；

图5为本发明实施例SNMP Manager与SNMP Agent之间通过SNMP V3消息通信的示意图；

图6为本发明实施例网络管理的方法流程图；

图7A、B分别为本发明实施例ME表和MODULE表的结构图；

图8为本发明实施例网络管理的系统框图；

图9为本发明实施例网络管理的应用示意图。

具体实施方式

本发明实施例提供一种网络管理的方法、系统及设备，能够应用于使用SNMP各种版本的通信系统，使得SNMP Manager通过SNMP Agent对各种类型的多个网元实现有效管理。

如图3所示，为本发明实施例网络管理的系统示意图，包括NMS(NetworkManagement System，网络管理系统)上的SNMP Manager 310，及EMS(ElementManagement System，网元管理系统)上的SNMP Agent 320。其中，SNMP Agent320管理n个网元330。

为实现对网元330的管理，在SNMP Agent 320中具有MIB 340。SNMPAgent 320支持的整个MIB 340是一棵树，可以包括以下三种类型：

A、框架MIB 341：定义这棵树的根部节点，决定这棵树的基本框架。

B、EMS本身MIB 342：是这棵树一个分支，存放EMS本身的被管信息。

C、各个类型各个版本的网元MIB 343：每类网元是这棵树的一个分支，存放各个网元的被管对象的属性信息。

其中，各个类型各个版本的网元MIB 343中，同一类型的网元MIB是一棵子树，主要包含一些表格，一个表格对应一类对象，表格中可包含该对象的各个实例，而表格的各列(叶子节点)对应这类对象的各个属性。这样，对于不同类型的网元，其MIB的结构不同；对于同一类型不同版本的网元，其MIB的结构可能不一样；此外，SNMP Manager一次请求一般只会访问同一个网元的对象信息，基于这些因素，本发明实施例都统一将SNMP Agent 320支持的MIB 340按照信息的类别划分成若干个Context(场景)。具体如图4所示，MIB划分成以下几个Context：

omsFm 410是一个Context，存放跟故障管理相关的一类MIB信息，例如告警表等。这些信息在框架MIB中某个分支下定义。

omsPm 420是一个Context，存放跟性能管理相关的一类MIB信息。这些信息在框架MIB中某个分支下定义。

omsCmCommon 430是一个Context，存放配置管理框架的一类信息，该Context中包含一个网元表，存放所有网元的基本信息。该网元表是所有对象表的父表，其索引为网元标识，例如，网元ID或者网元名等。这些信息在框架MIB中某个分支下定义。

EMSems 440是一个Context，存放EMS本身的对象信息。这些信息在EMS本身MIB中定义。

ME-1-ME-n 450分别对应一个Context，即：Context1-Contextn，分别存放某个网元的对象信息，即一个Context存放一个网元的所有对象信息。这些信息在各个类型各个版本的网元MIB中定义。

其中ME为网元(Managed Element)，1-n用于标识该网元。可以采用网元ID或者网元名称或者其他信息来标识网元。Context1-Contextn的所有表都是网元表的子表，都以网元表的索引作为自身的第一个索引。

由于将MIB树中所有叶子节点按照类别划分成若干个Context是在不考虑SNMP协议版本的情况下进行的(Context是SNMP V3的术语，SNMP V1和V2c没有Context这个概念)，因此，在SNMP Manager与SNMP Agent之间通过SNMP消息进行通信时，某些版本，例如SNMP V3，SNMP Manager向SNMP Agent下发SNMP V3消息时，可以携带与要访问Context相对应的参数，SNMP Agent可以根据该参数获知SNMP Manager具体要访问哪个Context。如图5所示，SNMP Manager 310下发SNMP V3消息时，在该SNMPV3消息的消息头部分携带ContextName(场景名)为Context1的参数，表示要访问Context1；而SNMP Agent 320根据ContextName可以获知SNMPManager要访问Context1，则会将访问场景界定在Context1中，即在该Context1内进行相关操作，而不会超越Context1这个场景。

而某些版本，例如SNMP V1或者V2c，SNMP Manager向SNMP Agent下发SNMP V1或者V2c消息时，由于该消息的格式不同于SNMP V3消息的格式，故该消息中不可以携带ContextName参数，这样，SNMP Agent不能通过该ContextName参数获知SNMP Manager具体要访问哪个Context，而是在SNMP Manager构建SNMP V1或者V2c消息时，如果要访问某个网元的信息，需要在PDU中的第一个VB(Variable Binding，SNMP消息携带的变量)的OID中携带该网元的标识信息(例如网元ID)，SNMP Agent接收到消息后，通过第一个VB的OID中的网元标识，就可以获知SNMP Manager要访问哪个Context；如果要访问非网元信息，不需要携带任何标识，SNMP Agent可以根据第一个VB的OID所属的MIB分支，确定要访问的Context。

如图6所示，为本发明实施例网络管理的方法流程图，包括以下步骤：

601、SNMP Manager生成SNMP消息并发送给SNMP Agent；

首先是SNMP Manager构造PDU，然后将相关信息组成SNMP消息，最后将该SNMP消息发送给SNMP Agent。

602、SNMP Agent接收SNMP消息、确定SNMP Manager要访问的Context，根据该SNMP消息在该Context内进行相关操作。

当SNMPAgent接收到SNMP消息时，首先分离出PDU，根据SNMP消息进行相应的处理后，向SNMP Manager返回应答消息。

需要说明的是，由于划分的Context是互不相通的，故SNMP Agent只能将访问场景界定在某个Context中，而不会超越这个场景。例如，如果SNMPManager使用Get-next-request访问某个Context，输入一个VB，即寻找该VB对应MIB节点的下一个节点；SNMP Agent只会在该VB对应的Context内查找，如果找不到，会向SNMP Manager返回endOfMibView(MIB访问结束)，而不会继续在其他Context中查找。又例如，如果SNMP Manager访问omsFm中的告警表信息，就不能同时访问EMS中的EMS对象信息；如果访问ME-1的信息，就不能同时访问ME-2的信息。再例如，通过Get-next-request或者Get-bulk-request遍历对象信息时，不会在不同的访问场景之间跳转。

对于SNMP V3，由于SNMP V3消息中有ContextName参数，可以表示要访问的Context，SNMP Agent可以直接确定SNMP Manager要访问的具体Context；而对于SNMP V1或者V2c而言，其消息中没有该参数，本发明实施例中，SNMP Agent根据SNMP V1或者V2c消息的第一个VB来确定SNMPManager要访问的Context。

A、SNMP Manager发送SNMP V1或者V2c消息时，当要访问某个网元的对象属性信息，则在第一个VB的OID中携带该网元在网元表中的索引，即第一个VB的OID中必须携带该网元的标识信息；而SNMP Agent接收消息后，通过消息中的第一个VB的OID中该网元标识，获知SNMP Manager要访问哪个网元，进而确定要访问哪个Context。

下面通过一个实例进一步说明：

如图7A、B所示，分别为ME表和MODULE表的实施例结构图，其中MEID是ME表中的一个网元索引，MODULE是CSCF网元的一个对象类，所以在MIB中，MODULE表属于CSCF网元的分支，在MODULE表有两个索引：hwImsMeMEID(MEID)和hwImsCscfModuleMID(MID)，其中hwImsMeMEID网元表中进行定义。

MODULE表中存放着各个CSCF网元的MODULE实例，不同网元的MODULE实例放在不同的Context中，如果发送SNMP V1或者V2c消息的SNMP Manager输入的第一个VB的OID不携带MEID，则SNMP Agent就不知道SNMP Manager要访问哪个网元的MODULE实例，所以，SNMP Manager输入的第一个VB的OID中必须携带MEID，SNMP Agent就可以知道SNMP Manager具体要访问的网元，进而知道SNMP Manager具体要访问的Context，这样，SNMP Agent就可以只访问在一个Context中的MODULE实例信息。举例说明如下：

1、如果SNMP Manager要通过Get-bulk-request查询MEID为100的MODULE的前几个实例的非索引列，则输入的VB的OID可以为：hwImsCscfModleMT.100、hwImsCscfModleETGRP、hwImsCscfModleRN1、hwImsCscfModlePN1、hwImsCscfModleSN1、hwImsCsctModleRN2、hwImsCscfModlePN2、hwImsCscfModleSN2、hwImsCscfModleMNAME和hwImsCsctModleRowStatus，即第一个VB的OID必须包含MEID。

2、如果SNMP Manager要获取MEID为100、MID为8的MODULE实例的非索引列，则需要输入的VB的OID应该为：hwImsCscfModleMT.100.8、hwImsCscfModleETGRP.100.8、hwImsCscfModleRN 1.100.8、hwImsCscfModlePN1.100.8、hwImsCscfModleSNl.100.8、hwImsCscfModleRN2.100.8、hwImsCscfModlePN2.100.8、hwImsCscfModleSN2.100.8、hwImsCscfModleMNAME.100.8和hwImsCscfModleRowStatus.100.8。显然，第一个VB的OID中也必须携带MEID信息。

B、SNMP Manager发送SNMP V1或者V2c消息时，当要访问某个基础分支(除了所有网元分支之外的其他所有分支统称为基础分支)的对象属性信息，则在VB的OID中携带该分支的MIB节点信息；而SNMP Agent接收消息后，当消息中的第一个VB的OID不属于某类网元的分支，而属于某个基础分支，则通过消息中的第一个VB的OID判断所属MIB分支，进一步判断Context，从而获知SNMP Manager要访问哪个Context。

例如，如果SNMP Manager要访问框架MIB中的告警表节点，则输入的第一个VB的OID的前面部分与Context为omsFm的分支的根节点的OID相同，那么SNMP Agent接收该消息后，则可以直接确认Context为omsFm；如果SNMP Manager要访问框架MIB中的网元表节点，则输入的第一个VB的OID的前面部分与Context为omsCmCommon的分支的根节点的OID相同，那么SNMP Agent接收SNMP V1或者V2c消息后，则可以直接确认Context为omsCmCommon。例如1.2为omsFm分支的根节点，如果第一个VB的OID为1.2.35.6，则根据其前缀1.2可以断定context为omsFm。

当然，SNMP消息中携带场景信息并不局限于第一个VB的OID中，也可以在其他的VB的OID中，只要SNMP Manager和SNMP Agent事先约定即可，其具体实现方式参照前述内容，此处不再赘述。

需要说明一点，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序指令相关的硬件来完成，所述的程序可以存储于一计算机可读取的存储介质中，所述的存储介质，如：ROM/RAM、磁碟、光盘等。

如图8所示，为本发明实施例网络管理的系统框图，包括：SNMP Manager810和SNMP Agent 820，其中：

SNMP Manager 810包括：消息生成单元811和发送单元812。其中，消息生成单元811，用于生成SNMP消息，该SNMP消息携带场景信息的OID；发送单元812，用于将所述的SNMP消息发送给SNMP Agent 820。其中，所述的消息生成单元811进一步包括第一设置子单元8111，用于当所述SNMP消息是SNMP V1或者V2c消息时，并且要访问某个网元的信息，在所述SNMP消息中的第一个VB的OID中设置某个网元的标识信息；以及第二设置子单元8112，用于当所述SNMP消息是SNMP V3消息时，在所述SNMP消息中设置某个Context的ContextName参数。

SNMP Agent 820至少包括：接收单元821、第一识别单元822、第二识别单元823、以及执行单元824。其中，接收单元821，用于接收来自SNMPManager的SNMP消息；第二识别单元823，用于当该SNMP消息中包含ContextName参数时，根据该ContextName参数确定要访问的Context；第一识别单元822，用于当该SNMP消息中不包含ContextName参数时，根据该SNMP消息中携带场景信息的OID，即第一个VB的OID确定要访问的Context；执行单元824，用于根据所述SNMP消息在由所述第一识别单元822或第二识别单元823确定的Context内执行与该SNMP消息相应的操作。至于第一识别单元822根据该SNMP消息中携带场景信息的OID确定要访问的Context，及第二识别单元823根据ContextName参数确定要访问的Context的具体说明，请参照前述内容，此处不再赘述。

SNMP Agent 820还可以包括：场景划分单元825，用于按照同一类信息放在同一个Context中的方式将MIB划分为若干个Context，并且不同网元的信息放在不同的Context中。Context的划分具体参照前述说明，此处不再赘述。

需要说明的是，本发明实施例中的SNMP Manager包括但不限于NMS上的SNMP Manager，SNMP Agent包括但不限于EMS上的SNMP Agent；本发明实施例中的网元可以是各种网络设备。本发明实施例可以应用于任何使用各种SNMP版本的通信系统管理各种类型的多个网元。

如图9所示，为本发明网络管理的应用实施例OMS2600产品的架构示意图。OMS(Operation Management Server，运行管理服务器)2600是一种管理IMS(IP Multi-media Subsystem，IP多媒体子系统)各种网元的类EMS系统。之所以称为类EMS系统，是指该系统介于EMS和ME之间。这里所述的各种网元可以为CSCF(Call Session Control Function，呼叫会话控制功能)、HSS(HomeSubscriber Server，归属用户服务器)、以及各类AS(Application Server，应用服务器)等。

在图9中，OMS2600 920向上层EMS 910提供的SNMP北向接口由SNMPAgent实现。OMS2600 920可以管理多种类型多个版本的多个网元ME1-ME7930，包括：版本1的CSCF1、版本1的CSCF2、版本2的CSCF3、版本2的CSCF4、版本1的HSS1、版本1的HSS2以及版本2的HSS3。

OMS2600支持的MIB 940被划分为以下Context：

omsFm 9401是一个Context，存放跟故障管理相关的MIB信息，例如告警表等。这些信息在框架MIB中定义。

omsPm 9402是一个Context，存放跟性能管理相关的MIB信息。这些信息在框架MIB中定义。

omsCmCommon 9403是一个Context，存放配置管理框架信息，该Context中包含一个网元表，存放所有网元的基本信息。该网元表是所有对象表的父表，其索引为网元标识，例如，网元ID或者网元名等。这些信息在框架MIB中定义。

OMS2600 9404是一个Context，存放OMS2600本身的对象信息。这些信息在OMS2600本身MIB中定义。

ME1-ME7 930分别对应一个Context，即：Context1-Context7(对应图中的标号9405-9411)，存放某个网元的对象信息。这些信息在各个类型各个版本的网元MIB中定义。

其中，各个网元的对象信息放在不同的Context中，即网元CSCF1的所有对象信息放在Context1中；网元CSCF2的所有对象信息放在Context2中；网元CSCF3的所有对象信息放在Context3中；网元CSCF4的所有对象信息放在Context4中；网元HSS1的所有对象信息放在Context5中；网元HSS2的所有对象信息放在Context6中；以及网元HSS3的所有对象信息放在Context7中。

SNMP Agent支持SNMP V1、V2c和SNMP V3，EMS可以通过SNMP V1、V2c或者SNMP V3消息访问各个网元的信息。当然，EMS下发SNMP V1、V2c消息时，必须满足如下要求：当要访问某个网元的对象属性信息，则在第一个VB的OID中必须携带该网元在网元表中的索引，即第一个VB的OID中必须携带该网元的标识信息；当要访问某个基础分支的对象属性信息，则在VB的OID的前面部分与要访问的基础分支的根节点的OID相同，具体如前述说明，此处不再赘述。

本发明实施例能够应用于使用SNMP各种版本的通信系统，不论使用SNMP哪种版本，都采用同样的Context划分机制，将不同网元的对象信息划分到不同的Context中，从而规避不同类型不同版本的网元MIB结构不一致的问题。在SNMP Manager发送SNMP V1、V2c消息时，如果要访问某个网元的信息，需要在SNMP V1、V2c消息的第一个VB的OID中增加该网元的标识信息，使得SNMP Agent通过该标识信息确定SNMP Manager要访问的Context，如果要访问其他信息，则不用携带任何标识，而SNMP Agent可以通过第一个VB的OID确定要访问的场景，进而在该场景内执行与该SNMP消息相应的操作，从而可以实现对各种类型各个版本的多个网元进行有效管理。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1、一种网络代理设备，其特征在于，包括：

2、根据权利要求1所述的网络代理设备，其特征在于，所述简单网络管理协议消息中携带场景信息的对象识别符中包含某个网元的标识信息。

3、根据权利要求1或2所述的网络代理设备，其特征在于，还包括：场景划分单元，用于按照同一类信息放在同一个场景中的方式将管理信息库划分为若干个场景供所述的执行单元执行相应的操作，并且不同网元的信息放在不同场景中。

4、根据权利要求3所述的网络代理设备，其特征在于，还包括：第二识别单元，用于根据所述接收单元接收的简单网络管理协议消息中的场景名参数确定要访问的场景。

5、一种网络管理设备，其特征在于，包括：

6、根据权利要求5所述的网络管理设备，其特征在于，所述的消息生成单元进一步包括第一设置子单元，用于在所述简单网络管理协议消息中第一个变量的对象识别符中设置某个网元的标识信息。

7、根据权利要求6所述的网络管理设备，其特征在于，所述的消息生成单元进一步包括第二设置子单元，用于在所述简单网络管理协议消息中设置某个场景的场景名参数。

8、一种网络管理的方法，其特征在于，包括以下步骤：

接收简单网络管理协议消息；

9、根据权利要求8所述的网络管理的方法，其特征在于，所述简单网络管理协议消息中携带场景信息的对象识别符中包含某个网元的标识信息。

10、根据权利要求8或9所述的网络管理的方法，其特征在于，所述接收简单网络管理协议消息的步骤之前还包括：按照同一类信息放在同一个场景中的方式将管理信息库划分为若干个场景，并且将不同网元的信息放在不同场景中。

11、根据权利要求10所述的网络管理的方法，其特征在于，所述根据该简单网络管理协议消息中携带场景信息的对象识别符确定要访问的场景进一步包括：当所述对象识别符所在的变量属于基础分支时，根据该变量的对象识别符确定该变量所属的分支，进而确定要访问的场景。

12、根据权利要求10所述的网络管理的方法，其特征在于，所述根据该简单网络管理协议消息中携带场景信息的对象识别符确定要访问的场景进一步包括：当所述对象识别符所在的变量属于网元分支时，根据该变量的对象识别符所包含的网元标识信息确定要访问的场景。

13、根据权利要求11或12所述的网络管理的方法，其特征在于，所述变量为该简单网络管理协议消息中的第一个变量。

14、根据权利要求8所述的实现网络管理的方法，其特征在于，所述简单网络管理协议消息中包含某个场景的场景名参数。

15、根据权利要求14所述的网络管理的方法，其特征在于，还包括：根据该场景名参数确定要访问的场景，在该场景内执行与该简单网络管理协议消息相应的操作。

16、一种网络管理的方法，其特征在于，包括以下步骤：

将所述的简单网络管理协议消息发送出去。

17、根据权利要求16所述的网络管理的方法，其特征在于，所述简单网络管理协议消息中第一个变量的对象识别符中设置有某个网元的标识信息。

18、根据权利要求16所述的网络管理的方法，其特征在于，所述简单网络管理协议消息中设置有某个场景的场景名参数。

19、一种网络管理的系统，其特征在于，包括网络管理设备和网络代理设备，其中：

所述网络管理设备包括：

所述网络代理设备包括：

接收单元，用于接收来自所述网络管理设备的简单网络管理协议消息；

20、根据权利要求19所述的网络管理系统，其特征在于，所述简单网络管理协议消息中携带场景信息的对象识别符中包含某个网元的标识信息。

21、根据权利要求19或20所述的网络管理的系统，其特征在于，所述网络代理设备还包括：场景划分单元，用于按照同一类信息放在同一个场景中的方式将管理信息库划分为若干个场景供所述的执行单元执行相应的操作，并且不同网元的信息放在不同场景中。

22、根据权利要求21所述的网络管理的系统，其特征在于，所述网络代理设备还包括：第二识别单元，用于根据所述接收单元接收的简单网络管理协议消息中的场景名参数确定要访问的场景。

23、根据权利要求19所述的网络管理的系统，其特征在于，所述的消息生成单元进一步包括第一设置子单元，用于在所述简单网络管理协议消息中第一个变量的对象识别符中设置某个网元的标识信息。

24、根据权利要求23所述的网络管理的系统，其特征在于，所述的消息生成单元进一步包括第二设置子单元，用于在所述简单网络管理协议消息中设置某个场景的场景名参数。