4 Conversion algorithm process design 4.1 Data model analysis
Compared with SNMP, NETCONF is a brand new XML configuration management protocol. The NETCONF protocol is conceptually divided into four layers, namely content layer, operation layer, RPC layer and transport protocol layer. Currently, the operation layer, RPC layer and transport protocol layer There are corresponding standards and specifications. The content layer does not give specific requirements. It allows the NETCONF data model to be defined separately, making it more flexible. However, on the other hand, it also hinders the widespread application of NETCONF. The data model definition is different from the traditional data model. The conversion is currently the focus and hot spot of major international standard research. In 2009, the NETMOD working group proposed YANG [14] as the standard NETCONF data modeling method. It is still under discussion and verification. The existing data model language, For example, XML Schema Definition (XSD) and Relax NG can be used for its data model. Because NETCONF is based on XML, XSD is an ideal choice. This article also uses XSD as a data modeling language to conduct experiments. IETF organization, Especially NETCONF work.
The ParseXML class is used to parse NETCONF messages, and its implementation depends on the other three key classes; the XmlDocument class is mainly used to extract key information of XML-based NETCONF messages, such as device P address, operation object OID, operation type, etc.; The Operations class provides three basic SNMP operations: GetRequest, GetBulkRequest and SetRequest, which makes it possible to implement the basic functions of SNMP; the UdpTarget class is mainly used to construct SNMP PDU and send corresponding SNMP request messages according to specific operations. 4.3 Conversion algorithm process design
The conversion process is shown in Figure 6 (see next page). 5 Experiment and Analysis
5.1 Experimental environment and parameters
Visual Studio 2010 is used as the development platform, and the programming language is C#. Four machines are selected for the experiment, one machine is used as the network management terminal based on NETCONF, one machine is used as the message converter, and one machine is used as the SNMP agent.
One server serves as a NETCONF agent. The SNMP agent and NETCONF agent are connected to the aggregation node through RS232 and the RFID card reader through USB. The aggregation node is connected to the static node through the ZigBee protocol. The experimental environment is shown in Figure 7 (see shown on the next page).
5.2 Running Example
This article selects SNMP agent and NETCONF agent for experiments. The goal is to obtain the sysUpTime of the device through the NETCONF management terminal.
Click “import object of management”, and the management object is displayed in the object browser window in a tree structure. Select the management device. Enter the P address of the agent and select the operation type, database status, and operation object respectively. Click “cre-ateMessage” to manage The end generates management messages based on NETCONF and displays them in the sending window. Click “sendMessage” to send the message, wait for the converter to respond, and the response message is displayed in the message receiving window.
If it corresponds to an SNMP agent, the receiving window will directly display the results, send the message and return the message as shown in Figure 8 (see next page).
If it corresponds to a NETCONF agent, the receiving window displays the rpc-reply message based on NET-CONF, and the sent message and return message are shown in Figure 9. If it corresponds to a NETCONF agent and the sent message lacks message-id, then Returns the rpc-error message based on NETCONF, encapsulates it in rpc-reply, and sends it to the IoT-шлюз
The messages sent and returned are shown in Figure 10.5.3 Experimental analysis results and improvements
Figure 11 and Figure 12 respectively show the response time comparison of 20 groups of system tests, each group of 100 random get-config operations. The response time types of the test are the total response time Ta, the management end to converter transmission time and the converter processing time. It can be seen that the four types of response times fluctuate in a relatively stable range, but the response time between TR and converter to agent is TTA. When this article was tested, the first time Tan and Tan were significantly higher than Tn and TT. After analysis , This is mainly because the two aspects of response time are not considered as special cases. This is because the converter is a Web service. First, the TCP-based message transmission time is significantly higher than the UDP-based message release. Through the TCP three-way handshake and management The end establishes a connection, and the converter and the transmission time of the text. In addition, in terms of the size of the packet, the management end based on NETCONF communicates through UDP, and UDP does not need to establish a connection. The XML messages sent by Figure 11 and Figure 12 are ,Compared to SNMP, only variable binding is more complicated.
Figure 12 shows an example of the message sent by the management end and the converted message leaf node. The converter automatically calls GetBulkOperation to compare with the change in the agent size. The experiment only considers the interaction of the data part of the TCP or UDP message segment. As can be seen from Figure 13, the size of the management packets of the NETCONF management end is almost the same. This article tests the first 8 basic object groups in mib-2, which are stable for the MIB tree. The SNMP management packets converted by the converter big or small
The changes fluctuate relatively large. Through analysis, this is mainly because considering that the number of scalar objects in the eight basic object groups is not the same, after weighing the processing time of the agent and the number of converted messages, the experiment will reduce the NonRe of the SNMPv2 GetBulk message. The -peaters field is set to 0, and the MaxRepetitions field is set to 20. For object groups with scalar objects greater than 20, multiple GetBulk requests need to be sent. This part can be optimized in the future, and these two parameters are automatically generated according to actual needs to reduce the number of converted messages. Size. Testing the change in packet size before and after conversion provides a reference for future converter location deployment.
Figure 13 (see previous page) shows the success rate of 20 randomly generated groups of 10,000 management messages each to obtain correct response messages. Failed operations will return error types. Through experiments, it was found that the success rates of the two operations are stable. At more than 99.4%, it is found through the error type returned that failure is mainly related to the current network and system conditions. The success rate of the get-congfig operation is generally higher than the success rate of edit-config. This is because the configuration operation is compared with the get-congfig operation. Value operations are more restricted. IoT-шлюз
The experiment selected response time, packet size change, and success rate to evaluate the performance of the system. The experiment mainly considered the compatibility of the NETCONF management end and the SNMP agent. The data model used the XML-based four-layer structure introduced in Section 4.1 , that is, the MIB-2 library is converted into the model required for the experiment through smidump. During the experiment, it was also found that the intermediate nodes of the MIB tree were lost during the conversion process, which shows that the conversion efficiency of MIB information expression is not accurate enough.
6 Conclusion
In order to deploy a unified network management system based on NETCONF in the Internet of Things environment, taking into account the current shortcomings of SNMP in configuration performance, security and scalability, as well as the complex SMI syntax and poor flexibility, the article proposes an Internet of Things-oriented Network management message conversion mechanism in the environment, which can adaptively manage various devices. In particular, this conversion mechanism is provided to the management end through web service, which has great advantages in security, scalability, and configuration efficiency. To the greatest extent. This article also proposes the design architecture of the management end, converter, and agent end. Through experiments, it is verified that the system’s compatibility with SNMP agents can effectively manage SNMP devices.
In future work, we will focus our research on three aspects: data model, scalability, and managed device monitoring performance optimization, and ultimately achieve unified and efficient management of network devices in the Internet of Things environment.
Ключевые слова: Шлюз для Интернета вещей