3Based on NETCONF network management architecture
3.1 Based on NETCONF management terminal
The management end contains a total of 3 modules, as shown in Figure 1, which are the interactive interface, the management message processing layer, and the session communication layer. The interactive interface is responsible for information interaction with the administrator. The message processing layer is the core module of the management end and is responsible for managing The message is encapsulated into a NETCONF-based management message and transmitted to the session communication layer. It is also responsible for verifying the received message.
format, and parses out the operation results. Content layer encapsulation encapsulates the message according to the adopted data model. Operation layer encapsulation and RPC encapsulation encapsulates the message into the corresponding RPC message according to the operation type selected by the user. Session communication The layer corresponds to the transport layer in the NETCONF logical model, which is responsible for transmitting management messages to the message converter, waiting for the response of the message converter, and returning the response results to the message processing layer.
3.2 Message converter architecture
The message converter in this article communicates based on Web Service. Based on the widespread acceptance of XML, web services have become applications that use standard transmissions, encodings, and protocols to exchange information. Choosing Web Service as the message transmission between the management terminal and the message converter meets the characteristic requirements of network management message transmission under the Internet of Things, and makes it easier to realize cross-platform, cross-device, and cross-network supervision of network equipment.
The message converter converts the management messages sent so that the network management end can communicate with different types of agents. The message converter is published in the form of Web Service to interact with the management end and directly interact with the Internet of Things environment. Different types of agents interact with each other.
The overall architecture of the message converter is shown in Figure 2 on the following page. It is mainly divided into three functional modules, namely the message classifier SNMP, the message conversion module, and other agent message conversion modules.
3.2.1 NETCONF-SNMP management message conversion
The converter responsible for converting NETCONF management messages into SNMP management messages is mainly composed of 6 modules, namely request analyzer, MIB-XML translator, XML DOM, XML interrogator, and trap processing module (composed of trap receiver. It consists of trap analyzer and trap filter) and message generator.
The request analyzer combines XMLSchema to determine the legality of the management message, and combines the operation type mapping table to extract the operation type. The MIB-XMIL translator is responsible for converting the SMI MIB into XML. The converted XML can be used to find the OID corresponding to the operation object. and mapping of operation objects. XML DOM is the core of the converter. It analyzes the XML file and passes the obtained device address, operation type, operation object OID, etc. to the SNMP poller. It is also responsible for receiving traps and implementing the parameters in the traps. After mapping, it is passed to the XML message generator. The SNMP poller packages the obtained parameters into SNMP PDU and passes it to the SNMP agent, and accepts the response from the SNMP agent. In order to reduce the communication traffic between the management end and the converter, the SNMP trap processing uses a filtering mechanism. The trap processor consists of three modules. It classifies the received traps and establishes a classification system to determine the degree of urgency. Finally, it filters out some duplicate or invalid trap messages and passes them to XML. The DOM message generator generates the corresponding response message or notification message and sends it to the NETCONF management terminal and IoT-gateway.
The NETCONF-SNMP converter can also achieve compatibility with ANMP agents. This is because ANMP uses the same PDU format as SNMP, and also uses UDP as the transport protocol to send ANMP messages. In terms of data collection and control, ANMP extends the SNMP MIB In order to record the unique information of the Ad Hoc network. To manage the ANMP agent, first the management end loads the corresponding MIB file, and the message classifier determines the address in the management message.
If the corresponding ANMP agent is an ANMP agent, passing the management message to the converter can achieve effective management of the device corresponding to the ANMP agent.
3.2.2 Support for other network management protocols
Considering that there are a small number of other network management protocols in the Internet of Things environment, this article adds a theoretical architecture that supports other network management protocols. This architecture is explained below.
As shown in Figure 2, the architecture mainly consists of four parts, namely data tables, adapters, message generators, and trap receivers. Three data tables and three adapters are the key to the architecture. The device information table records the relevant information of the agent. , used to distinguish which agent the management end communicates with; the private data table maps the properties of NETCONF to the private properties of the agent; the operation table maps the operation type of NETCONF to the private operation type of the agent. The message adapter implements message format correspondence; The transport adapter is responsible for the converter communicating with various agents; the trap adapter is responsible for how the agent actively communicates with the management process and notifies the management process that something has happened. Internet of Things Gateway
When the management end communicates with the agent, the converter first loads the XML configuration file of the agent and generates three data tables, namely the device information table, the operation type table, and the private data table. The specific details of the above three adapters are generated through the data tables. Implementation, the adaptation manager is responsible for initializing the adapter and calling the adapter at the appropriate time. Under the coordination of the adaptation manager, the message generator can convert the NETCONF configuration message passed by the management end through the adapter into a PDU that can be recognized by the agent. ,The returned PDU can also be converted into a NETCONF-based response message through the management message generator.
3.3 Agent-side architecture design
Currently, network equipment manufacturers such as Cisco and Juniper have implemented RFC4741-based agents and embedded them into their latest routers.
NETCONF uses XML for data transmission and module expression, and has strong scalability. Network equipment providers can use this protocol to obtain and set all configuration data, which is suitable for rapid addition and efficient management of different types of equipment under the Internet of Things. These functions A large part depends on the implementation of the agent. How to effectively apply the agent based on NETCONF to different types of network devices and perform network management on them is an urgent problem that needs to be solved. This is related to the vitality of NETCONF in the Internet of Things network management. .This article divides agents into three
There are three types, namely SNMP agent, NETCONF agent and other agents.
This section analyzes the NETCONF agent architecture design based on the characteristics of the Internet of Things. According to the provisions of RFC4741, a basic NETCONF agent is designed in a four-layer structure. In addition, the agent must complete support for capability characteristics, three database statuses and event notifications. Based on The proxy architecture of NETCONF is shown in Figure 3.
The session communication layer is responsible for interacting with the management terminal. After the agent is started, it will monitor the management messages from the management terminal. After the message processor receives the management messages from the session communication layer, it can parse out the operation type and operation object and pass them to the operation processor. The result of the operation processor operation can be encapsulated into a response message based on NETCONF. The operation processor performs the specific operations parsed by the message processor. The configuration information status in the management object information base is divided into 3 stages, corresponding to 3 database statuses : Running state (running), start up state (start up) and candidate state (candidate). Capabilities (capabilities) are a new feature of NETCONF. This feature allows the client to discover the set of protocol extensions supported by the server. The introduction of “capabilities” The basic operation set is enriched and new operations are added to improve the scalability of the agent. The managed device passes the capability set to the management database for storage. After the management end sends a “HELLO” message, it is passed to the management end to inform the management end that it is being used. The set of protocol extensions supported by the managed device. The notification module is responsible for delivering messages actively sent by the managed device to the message processor, which is then encapsulated by the message processor and delivered to the management end through the session communication layer.
This article does not focus on discussing the two characteristics of “capability” and “notification”, but these two characteristics are crucial for applying NETCONF to the Internet of Things environment, because the Internet of Things environment requires “capability” to support Scalability, “notification” to support real-time monitoring of managed devices, is also the focus of our future work discussion.
Keywords: Internet of Things gateway