# Industrial IoT Monitoring: Technologies and Architecture Proposal
## 2 Technologies for Industrial IoT
### Management Protocols  
Network management emerged in traditional networks with the need to control and monitor networks as they grew up in size and complexity. ISO/IEC 7498-4 [36] was one of the first initiatives to establish a management framework, by defining a set of functional areas, namely: fault, configuration, accounting, performance, and security management. Furthermore, ISO/IEC 7498-4 proposed the use of managed objects as abstractions for network resources, which, in turn, contain several attributes. In current protocols, managed objects can be defined using several syntaxes, like SMIv2 [37], YANG [38], and XML [39]. Managed objects data are stored in management databases and accessed by management protocols. In this sub-section, we identify two types of management protocols: (1) protocols designed for traditional networks; and (2) protocols designed for networks of resource-constrained devices, that can also be used in some traditional networks. As one of most used protocols for the management of IP devices, SNMP [37] provides most of the basic functionality defined in ISO/IEC 7498-4. The standard specifies an architecture based on agents and managers. Devices being monitored, run SNMP agents that share the device state information with an SNMP manager, by using query/response interactions and trap notifications. Each SNMPagent has a collection of managed objects whose data are stored in a Management Information Base (MIB). Each object is identified using a specific object identifier (OID). Despite the success of SNMP for monitoring purposes, the protocol failed to provide an effective and reliable way to configure devices. Thus, IETF started a working group that wrote an informational RFC [40] with several requirements that coming network management standards should implemented. This work was the basis for the NETCONF [41] protocol. Differently from SNMP's manager-agent architecture, NETCONF uses a client-server architecture. The server runs on a management device (SNMP agent) and shares the monitoring information (also by query/response and notification messages) with the client (SNMP manager). Additionally, when devices need to be configured, the client may send several configuration commands in one or several transactions. The transactions supported in NETCONF give operators the capability of sending out-of-order commands, and of performing rollback and commit operations. The management protocols mentioned up to now were designed for traditional networks. In [42], the authors implemented traditional network management protocols in networks of constrained devices, and concluded that SNMP and NETCONF are not suitable for this type of networks. For instance, the use of TLS encryption in NETCONF adds significant overhead in terms of session time (i.e., in the order of seconds). In later years, with the growth of IoT, new solutions that address resource-constrained devices and 6 LowPAN networks were proposed. These solutions also take advantage of transport protocols specially designed for resource-constrained devices, like CoAP [43]. One of the first solutions developed with a focus on the management of 6 LowPAN networks was the LoWPAN Network Management (LNMP) protocol [44]. The LNMP protocol implements a solution based on SNMP that targets 6 LowPAN networks. In this solution, 6 LowPAN gateways convert the information from 6 LowPAN networks to SNMP MIBs and make it available over IP. On the other hand, other management architectures were evaluated, and new research directions that take advantage of new technologies like HTTP appeared. In [45], the authors evaluated the use of different architectures like SNMP, Resource-Oriented Architecture (ROA), and Service-Oriented Architecture (SOA), and concluded that ROA architectures are more suitable for resource-constrained devices in terms of response time and power consumption, and are less sensitive to changes in timeout. As a result, a RESTful version of NETCONF was created, named RESTCONF [46].