Technology trends such as Software-Defined Networking (SDN) are transforming networking services in terms of flexibility and faster deployment times. SDN separates the control plane from the data plane with its centralised architecture compared with the distributed approach used in other management systems. However, management systems are still required to adapt the new emerging SDN-like technologies to address various security and complex management issues. Simple Network Management Protocol (SNMP) is the most widespread management protocol implemented in a traditional Network Management System (NMS) but has some limitations with the development of SDN-like services. Hence, many studies have been undertaken to merge the SDN-like services with traditional network management systems. Results show that merging SDN with traditional NMS systems not only increases the average Management Information Base (MIB) polling time but also creates additional overheads on the network. Therefore, this paper proposes a dynamic scheme for MIB polling using an additional MIB controller agent within the SDN controller. Our results show that using the proposed scheme, the average polling time can be significantly reduced ( i.e., faster polling of the MIB information) and also requires very low overhead because of the small sized OpenFlow messages used during polling.
With the popularity of cloud computing features e.g., network virtualisation [
Provisioning of network systems is very important for network management including network operations [
Traditional management systems show inadequacies when deployed in DCs and enterprises with new SDN-like services [
Network virtualisation techniques allow service providers to slice infrastructure resources, enabling a flexible deployment of new network technologies. SDN breaks the old hardware barrier by introducing reconfigurable and extensible modules in network devices by separating the control plane from the data plane. SDN increases network flexibility and service agility with resource provisioning. Hence, continuous monitoring of SDN traffic is also required for utilisation of the network resources. SDN manages data flows and switching using the OpenFlow protocol [
SNMP largely deals with the management plane where focus is on collecting information about the traffic and status of the elements and is typically consumed by a NMS through polling the information periodically. Hence, the management plane monitors and configures the network element. Whereas, the control plane defines how packets flow through the network element. OpenFlow, by definition, focuses on the control plane but also supports the management plane of the network.
OpenFlow-like protocols are required to implement the SDN paradigm using the new network elements to incorporate Network Function Virtualisation [
The work described in this paper is conducted as part of a wider US-Ireland funded project concerned with enabling efficient and secure cloud computing for high capacity applications, including dynamic optical Terabit scale networking. Software Defined Monitoring with a MIB will necessitate real-time higher level executable policies across the management control plane between the main network elements. The MIB schema and syntax together with a policy engine will be capable of allowing the SDN controller to make real-time decisions about the cost and benefits of migration and/or replication. In particular, in this paper we initially used the SNMP protocol for MIB polling through the SDN controller i.e., merging the SDN controller with old NMS and found that using SNMP not only increases the average MIB polling time but also creates significant overheads on the network. Hence, this paper proposes a dynamic scheme of MIB polling using an additional controller inside the SDN controller. Our results show faster po- lling of the MIB information and very low overhead in the network compared to the NMS MIB polling.
The rest of the paper is organised as follows: Section II describes the related work in this area and how our work is unique; Section III provides details of the Software Defined Monitoring techniques and illustrates our proposed scheme. Section IV describes the experimental setup and configuration for this work. Section V presents the results with discussions comparing the old NMS with SDN and our proposed scheme. Finally, section VI provides some conclusions and a view for future work.
Many research studies related to network management have been undertaken. However, new network architectures with NMS required SNMP-like network ma- nagement protocols to manage the architecture effectively. An approach for managing SDN using traditional NMS is presented in [
A management architecture and Manager-agent communication model has been modelled in [
Much research also has been conducted without using the SNMP for Software Defined Monitoring. John et al. proposed a split selected monitoring control functionality onto node-local control planes in [
However, the main issue here is in considering the entire infrastructure as one unified service production environment and therefore, the challenge is to provide up-to-date, accurate, and detailed monitoring information to orchestration and control layers in a scalable way.
In optical networks, Non-SDN Reconfigurable Optical Add-Drop Multiplexer (ROADM)s are not always able to update hardware or software in the ROADMs to adapt legacy SDN architecture. In [
Although they claim their proposal does not require any software modification of the SDN controller or ROADM SNMP agent, the issue in such architectures is that it uses a proxy that translates the of messages sent by the controller into SNMP commands to apply the desired configurations on the ROADM and vice-versa. This can increase delay in a large data centre or inter-data centre net- works and reduce the monitoring performance.
In [
However, our work is motivated for such architectures and considered very small packets for SDN monitoring. Therefore, our scheme not only reduces the overall network overhead but also achieves high speed data polling. In summary, this paper is unique in the following aspects:
This work uses small packet sizes i.e., only 64-byte OpenFlow packets for SDN monitoring and hence can perform high speed polling.
Small sized packets will also reduce the overall network overhead for SDN mo- nitoring techniques and therefore can improve the QoS of the data centre.
The architecture achieves high availability by ensuring reduced latency between the SDN controller and the developed additional MIB controller with scalable efficient task queues.
The next Section describes old network management with MIB using SNMP protocol and proposes a dynamic approach of MIB polling in a software defined network for centralised network monitoring.
This paper aims to develop a dynamic approach for MIB polling in SDN for mo- nitoring. Our proposed approach includes an additional MIB controller agent in the controller plane of SDN. The MIB controller agent is designed considering a loosely coupled architecture for MIB polling to support high availability and sca- lability as defined in OpenFlow 1.2 or later.
SNMP agents (e.g., Net-SNMP) are allowed to collect the management information database from the device locally and make it available to the SNMP manager. Hence, the agent maintains an information database describing the managed device parameters.
NMS uses this database for specific information and this commonly shared database between the Agent and the Manager is called a MIB. A MIB is basically a collection of information for managing network elements. The MIB contains a standard set of statistical and control values defined for hardware nodes on a net- work. Private MIBs extends these standard values with values specific to a parti- cular agent.
The MIBs contains of managed objects identified by the name Object Identifier (Object ID or OID). Each Identifier is exclusive and represents specific features of a managed device. However, the return value of each identifier could be different e.g. Text, Number, Counter, etc. Like a folder structure on PCs, OIDs are very structured, and follow a hierarchical tree pattern as shown in
For example, three object levels are written as 1.3.0 not iso\org\standard. As shown in the figure, a typical object ID will be a dotted list of integers. Hence, the OID in RFC1213 for sysDescr is .1.3.6.1.2.1.1.1 and using the OID the system can get the hardware and software information used on the host.
In NMS, SNMP polls MIB information and gets a response from its MIB agents (e.g., switches, routers).
NMS using SNMP fetches MIB information directly from network devices for traffic monitoring. The collection of managed object values is performed periodically and then the information can be automatically transferred to a database. Under the NMS control via SNMP protocol, polling is still a popular mechanism to gather information from the managed networks. Most NMSs collect data from network elements directly via SNMP. However, in recent developments of data centre networks, OpenFlow based SDN requires monitoring of network devices and there has not yet been sufficient research done on SDN monitoring.
This work first aims to develop a MIB polling mechanism for SDN monitoring through the NMS using SNMP. As shown in
SNMP was envisioned for exposing data to external applications for remote mo- nitoring. A distinctive feature of SNMP includes the capability of sending trap messages so that the agent device can push information about their status or condition to the management plane. However, SNMP has many shortcomings, including being limited in the number of data types it can handle. The vendors can extend the SNMP OID in their own numbering scheme but the extension does not solve the whole problem with the advances of the emerging technologies like SDN.
Hence, in this paper we have introduced a MIB controller agent in the SDN controller using the RYU SDN Framework development [
The MIB controller agent in the SDN controller is implemented as a controller agent that sends MIB requests to a TCP port by using Netcat [
In Step 1: The GET_MIB_REQUEST is sent by the controller, which is a small TCP Packet using Netcat. We have used 64-byte frames to generate high packet rates and force high packet processing in the OpenFlow switch from the MIB controller.
In Step 2: With the help of Wireshark, we are able to trace corresponding Data-path IDs (DPID) of the OpenFlow switch and we have maintained a TCP Port to DPID table for this experiment to dynamically forward the MIB request to the memory cache.
In Step 3: The DPID finally requests the MIB information from the Memory cache.
In Step 4: The switch returns the MIB info as OpenFlow small 64-byte packets to the DPID.
In Step 5: The info is return as the GET_MIB_REPLY to the SDN controller directly.
For better performance, the MIB information is written in an in-memory cache maintaining a single list. The MIB data then can be dynamically configured via the northbound interface of the controller for monitoring. We have used the miss_ send_len field in the OpenFlow that defines the number of bytes of each packet sent to the controller to reduce the packet size to generate high packet rates and force high packet processing in the OpenFlow switch from the MIB controller [
In NMS, SNMP allows Protocol Data Units (PDUs) sized up to the Maximum Transmission Unit (MTU) of the network i.e., Ethernet allows up to 1500-byte frame payloads [
We have used Mininet version 2.2.1 and OpenFlow version 13 running on an Intel(R) Core (TM) i7 3.40 GHz CPU with 16 GB of memory for the experiments. All the experiments are done over 1000 runs with 0.95 or, 95% confidence interval [
We started some initial capacity variation experiments using SNMP and the SDN controller in a fat tree topology to check the Mininet topology. SDN com- menced with SNMP protocol shows that the average polling time is lower with respect to the higher link capacities between the Top of Rack and the Aggregate
Parameters | Value |
---|---|
Servers/Hosts | 16 |
Top of Rack switches | 8 |
Aggregate switches | 8 |
Core switches | 4 |
Bandwidth | |
Host to Top of Rack (EDGE Level) switches | 1 Gbps |
Aggregate to Top of Rack (EDGE Level) switches | 1 Gbps |
Aggregate to Core switches | 1 Gbps |
Polling Interval | 60 sec |
level switches. We found the gigabit links takes only a few milliseconds for MIB polling on average whereas, the average time for MIB polling can be up to 50 times higher using 100 Mbps links compared to the gigabit links as expected. We have performed a number of experiments described in various scenarios; the next sub-sections present the experimental results:
The first scenario considers a comparison between the developed MIB manager in the NMS application with the proposed additional MIB controller agent at the SDN without background traffic.
The second scenario continues the comparison considering various amounts of background traffic.
The first scenario is chosen to measure the polling speed considering a data centre with no background traffic. We have compared the Average Polling time for the developed MIB Manager in the NMS with the proposed MIB controller agent in the SDN by varying the MIB switch agents. Using NMS, the MIB Manager gets the bandwidth of the interface to the MIB switch agent. The If Speed variable is used in this case that replies with the speed of the interface as reported in the SNMP if Speed object. Our proposed approach requests similar MIB information that has been stored in the MIB switch memory cache, considering the fat tree topology using Mininet.
The figure also shows that with the number of increased active MIB switch agents, the average polling time difference between the two approaches increases.
For example, while 4 MIB switch agents are active, the average polling time initiated by NMS is 26 ms, whereas our approach shows only 7 ms. However, with 16 Active Switch Agents the polling time initiated by NMS is 460 ms, whereas the proposed approach can take up to 96 ms.
In the second scenario, we have considered various amount of background traffic while MIB polling to observe the overall network impact.
With 20% background traffic,
Parameters | Value |
---|---|
Servers/Hosts | 16 |
Top of Rack switches | 8 |
Aggregate switches | 8 |
Core switches | 4 |
Bandwidth | |
Host to Top of Rack (EDGE Level) switches | 1 Gbps |
Aggregate to Top of Rack (EDGE Level) switches | 1 Gbps |
Aggregate to Core switches | 1 Gbps |
Background Traffic | UDP |
Background Traffic with respect to Network bandwidth | 20%, 50% and 80% |
Polling Interval | 60 sec |
The impact of the retransmissions can be observed in
We have also obtained full sets of results considering 50% and 80% background traffic.
number of active switch agents is 3 using both approaches and it can increase up to 56 sec using NMS MIB polling. However, using the proposed approach it increases only up to 5 sec.
The packet drops graph considering 50% background traffic also shows that the average packet drops also increases compared to 20% background traffic as shown in
Considering 80% background traffic, the average polling time can be very high i.e., up to several minutes using NMS MIB polling, whereas our MIB controller
agent does not required any MIB manager from the application plane and it is anticipated that latency can be shorten and polling time is minimized as shown in
The effect of the increased retransmissions can be observed in
The proposed approach proposes an additional MIB controller in the SDN that provides centralized control and does not require querying devices individually. The MIB controller in the SDN controller is implemented as a controller agent which sends MIB requests by using OpenFlow messages with small packet size. Hence, by reducing the overhead our results show that using a K-ary Fat tree topology in various test scenarios the proposed approach outperforms a comparative traditional SNMP based polling.
An alternative to the K-ary Fat topology has been developed known as leaf- spine where a series of leaf switches form the access layer known as “pine switches”. The administrators claim that spine switches are one hop away and minimise the latency and the likelihood of bottlenecks between access-layer switches. The proposed approach sends small packets for MIB requests using OpenFlow messages and using leaf-spine architecture should not deteriorate the polling performance as the approach is not affected by latency and not affected by bottlenecks between access-layer switches.
Network monitoring is essential for network management where MIB polling from network devices is well recognised. Traffic monitoring using MIBs helps network operators understand network traffic volume and bandwidth utilisation, and is also important for network planning and design. In this paper, we have proposed a dynamic approach to effectively collect MIB information for SDN, and implemented the proposed architecture with an SDN controller to confirm its feasibility. Furthermore, we addressed issues in the MIB polling initiated by the NMS via SDN and proposed effective solutions.
However, sending small packets could result in lower throughput and therefore, a network administrator’s choice is a trade-off between the throughput and the polling response time in the case of high speed polling for network monitoring without interfering with the network data traffic. Future work will further investigate and develop high speed polling mechanisms considering high throughput in data centre environments by prioritizing the polling mechanisms within the management plane by developing new OpenFlow data compression techniques and scheduling algorithms. However, we expect the proposed scheme to be useful for many network management applications that require faster polling and continuous networking monitoring with very low overhead in a real data centre environment.
In SDN, a flow could be related to Inter-DC or Intra-DC. Accordingly, it is possible to attain more detailed MIB traffic in SDN, for example, network traffic consumed by an optical network or application. The low level optical attributes can be augmented with a formal illustration of the current network configuration and traffic load which will be closely coupled to the scheduling algorithms that will suggest reconfigurations to the SDN controller to be pushed down to the network elements. This formal representation of the network can monitor data from the network to be maintained on a per-link basis: average queuing delay, data loss, modulation scheme, encoding scheme, throughput, utilisation, jitter and other metrics that will become available from fast optical switching. Future work will propose an SDN architecture that will redesign including ROADMs. A proxy will be designed to translate the OpenFlow messages sent by the controller into SNMP commands to apply the desired configurations on the ROADM initially, without software modification of the controller or agent. This work will further provide such architecture by leveraging Packet Transport Routers and industry-leading optical systems into packet optical convergence architecture [
This research is supported by the “Agile Cloud Service Delivery Using Integrated Photonics Networking” project funded under the US-Ireland Programme NSF (US), SFI (Ireland) and DEL (N. Ireland).
Biswas, I., Abu- Tair, M., Morrow, P., McClean, S., Scotney, B. and Parr, G. (2017) A Dynamic Approach to MIB Polling for Software Defined Monitoring. Journal of Computer and Communications, 5, 24-41. https://doi.org/10.4236/jcc.2017.55003