Gabriela Mamani

Jonathan Becedas

Vicente Feliu Batlle
email: vicente.feliu@uclm.es

Robust Position Control of a DC Motor by Sliding Mode

Keywords: Robust control, sliding mode control, DC motor

The position of the DC motor is controlled by using a continuous sliding mode control (SMC), which is highly robust to the Coulomb friction torque and to high unknown payload variations, which involve changes in the rotational inertia of the motor shaft. The main contribution of the work is the experimentation of a SMC control which does not requires the knowledge of the payload variation range, i.e., the system is quite robust to any unknown change in the payload mass value.

Introduction

Many of the developed controllers depend strongly on the exact modelling of the mechanical system. Any change in the plant parameters reduces the controller performance, making the system lose the desired specifications. The discrepancies between the actual plant and the mathematical model may be due to un-modelled dynamic, variation in system parameters or the approximation of complex plant behaviour by a straightforward model. We must ensure that the resulting controller has the ability to produce the required performance levels in practice despite such plant/model mismatches. This has led to an intense interest in the development of socalled robust control methods which seek to solve this problem. One particular approach to robust controller design is sliding model control methodology.

Several SMC approaches have been applied to different types of motors. The authors in [START_REF] Veselic | High-Performance Position Control of Induction Motor Using Discrete-Time Sliding-Mode Control[END_REF] apply discrete time sliding-mode methodology in order to develop an induction motor position controller. In [START_REF] Traore | Sensorless Induction Motor: High-Order Sliding-Mode Controller and Adaptive Interconnected Observer[END_REF] an adaptive observer and a higher order sliding-mode framework are combined to control induction motors without mechanical sensors. In [START_REF] Ryvkin | Sliding-Mode-Based Control for a Three-Level Inverter Drive[END_REF] the sliding-mode approach is developed to control an induction motor fed by a three-level voltage source inverter. In the paper of [START_REF] Comanescu | Decoupled Current Control of Sensorless Induction-Motor Drives by Integral Sliding Mode[END_REF] discuss current decoupling and controller design for sensorless vector-controlled induction motor drives. They present a method, which does not require speed estimation, for decoupled current control based on integral sliding mode. Another contribution concerned with electric drive control is the paper by [START_REF] Pisano | Cascade Control of PM DC Drives Via Second-Order Sliding-Mode Technique[END_REF], which presents a cascade control scheme, based on multiple instances of a second-order SMC algorithm for the speed/position control of permanent-magnet motors.

A (SMC) design methodology based on the control law described in [START_REF] Young | A Control Engineers Guide to Sliding Mode Control[END_REF] and [START_REF] Edwards | Sliding Mode Control -Theory and Applications[END_REF] is applied here to a DC servo motor model. A rigorous interpretation of the relationship between the equivalent control law and the low frequency components of the discontinuous control action maintaining a sliding motion is described in [START_REF] Utkin | Sliding Modes in Control Optimization[END_REF].

Contributions to Technological Innovation

This work presents an easily implemented robust controller applied to DC motor model, since the motor is the basis of many applications in present-day industry, as is the case of manipulator robots. A simple demonstration of the control method's robustness to variations in the inertia is provided. The analysis presented shows that the system correctly performs for any type of payload and for any variation in it. Unlike other existing control methods in which to define the range in which the inertia may vary is necessary, in this paper this is not, which permits greater versatility and security upon its implementation in any type of electro-mechanical systems. Moreover the control method is robust to Coulomb friction, one of the non-linear types of friction which is still of current scientific interest since it affects the control accuracy

Modeling of the DC Motor Model and Problem Statement

A common electromechanical actuator in many control systems is constituted by the DC motor [START_REF] Begamudre | Electro-Mechanical Energy Conversion with Dynamics of Machines[END_REF]. We can write its dynamic equation by using Newton's Second law: The nominal system equation of the motor dynamics (1) can be written in statespace form as & acts in the input channel (i.e. in the second of the pair of the differential equations). The variable structure control system with a sliding mode have the ability to completely reject the effect of the bounded uncertainty acting in the input channels which is referred to as matched uncertainty, (see [START_REF] Utkin | Sliding Modes in Control Optimization[END_REF]).

) ( 1 0 ) ( 0 ) ( 0 1 0 ) ( m sign t u Jn k t x J v t x θ µ & &       -         +         - = (2)

Sliding Mode Control: State Feedback

Consider the following state representation of an uncertain Linear Time Invariant (LTI

) dynamic system 0 ≥ ∀t ) , , ( ) ( ) ( ) ( u x t f t Bu t Ax t x m + + = & (3) ) ( ) ( t Cx t y = (4)
Where the state In this paper, the following is assumed:

n x ℜ ∈ , n n A × ℜ ∈ , m n B × ℜ ∈
A.1: The pair A, B is controllable. A.2: The input distribution matrix B is full rank.
As is well known, SMC design consists of a two-step procedure. The first one is the description of the control objective in terms of a space state surface (called the sliding surface). The surface choice is developed such that the system trajectories satisfy the performance specifications, when the sliding variable lies on the sliding surface. The second step (controller design) is represented by the definition of a control action which steers the state trajectories onto the sliding surface, after a finite transient.

Sliding Surface Design

By assumption

m B rank = ) (
, then an orthogonal similarity transformation z x T x r = → exists such that the state and input matrices have the following structure: Hence, the reduced-order sliding mode dynamic is given by

      =       = 2 22 21 12 11 0 , B B T A A A A AT T r T r r (5) Where ) ( ) ( 11 m n m n A - × - ℜ ∈ , m m n A × - ℜ ∈ ) ( 12 , ) ( 21 m n m A - × ℜ ∈ , m m A × ℜ ∈
) ( 2 t z in term of ) ( 1 t z yields ) ( ) (
) ( ) ( ) ( 1 12 11 1 t z M A A t z - = & (8)
In the context of designing a regulator, the matrix governing the sliding motion . Therefore, to find a gain matrix M by using any available linear state feedback method will always be possible, e.g. pole placement, quadratic minimization or direct eigenstructure assignment (more details of this approach can be found in [START_REF] Utkin | Sliding Modes in Control Optimization[END_REF].

Control Law Design

A common control structure is divided into two parts:

) ( ) ( ) (
s s ssign = ) (
. In order to smooth the control action, a small positive scalar, γ is added to the denominator of the control law to yield γ ρ

+ = s s t u n ) ( (11)
The scalar function ρ , which depend only on the magnitude of the uncertainty and satisfies the η -reachability condition, [START_REF] Utkin | Sliding Modes in Control Optimization[END_REF].

Experiments

The experimental platform consists of a three legged metallic chassis that supports an Harmonic Drive mini servo DC motor RH-8D-6006-E036AL-SP(N) which has a reduction relation . The real time experiments are carried out under the Real Time Workshop®, which allows us to generate and execute C code from SIMULINK® models and embedded MATLAB® code. The controller is implemented in a PC with the real time software. A data acquisition card is used to establish the communication with the real platform: execution of the control law and reading of the sensorial system described above.

Experimental Results

The demonstration of the robustness with regard to payload changes is carried out by changing the ratio between the inertia value used to design the control algorithm, θ correspond to the different values of δ ,(see first and second column of Table 1; the third column represents the percentage of J whit regard to a J ). Note that the control the control is robust with regard to the inertia change: the controller never becomes unstable and the steady state error is null. Nevertheless, the trajectory tracking error increases when the inertia of the motor decreases with regard to that used to design the control. Observe that when 1 = δ , i.e. J J a = the delay of the trajectory m θ with regard to the reference * m θ is insignificant, and when that ratio increases from 2 to 20 , the delay is more notorious. Nevertheless, the system is always stable and the steady state error is null, which demonstrates the robustness of the control law. . This signifies that in the following experiments the real inertia of the motor is from 1 to 20 times greater than the controller design inertia, or that it is the same to increase the inertia of the motor shaft. The first and second column of Table 2 2).

These results permit us to affirm that the trajectory tracking error is almost the same for all cases in which a J J ≥ , and these errors correspond to that obtained when a J J = . This demonstrates the good performance of the presented method, which can be used in experimental platforms for trajectory tracking tasks in which the payload may change. Such a robustness is obtained in these experiments for very extreme cases

a a J J J ≥ ≥
, which means that there is no boundary in the δ value, with the exception of physical limitations such as the saturation of the servo-amplifier, i.e. the maximum and minimum δ values are given by the maximum voltage value supported by the servo-amplifier (in these experiments ) ( 10 V which is delimited for every application.

The authors want to highlight that due to the (SMC) nature is that of a switch changing from one state to the other, the control action signals has not been included, because the control action presents a high frequency chattering effect which makes quite difficult the visualization. Since the nature of this paper is wanted to be maintained essentially practical and experimental by the authors, theoretical analysis of the system under the effect of the different types of noise has not been included. Nevertheless, notice that the results are obtained from a real platform, means that the sensors measurement and the system dynamics are affected by unstructured noise. Even in presence of these types of noise the control system works properly with high accuracy as shown with these experimental results, which demonstrate a high robustness to unstructured measurement and system noises. A SMC based on the equivalent control approach has been presented and designed for the DC motor model. This approach allows matched uncertainties in DC motor model to be dealt with. These results advise the use of a control scheme insensitive to payload variations, to fulfil the requirements imposed to the system for the whole range of inertias due to the controller design does not require bounded uncertainties. Further computer simulations and experiments were carried out to test the robustness property of the SMC, considering different combination of uncertain parameters. The experimental results demonstrate the good performance of the method: the responses of the control system in trajectory tracking tasks are quite fast and the steady state errors are null. Therefore, in light of the experimental results obtained, we demonstrate that the SMC control method proposed in this paper solves the problem of high payload changes in DC motors and electromechanical actuators, since the control design is robust with regard to the friction in the motor dynamics and high varying payloads with no restriction in the variation, i.e. this method does not requires the a priori knowledge of the varying range of the load, being this, the main contribution of this work. Furthermore, the control law is very well suited for trajectory tracking tasks with. This characteristic makes the control here designed able to control robot manipulators, in which the trajectory tracking is an essential problem since the accelerations must be slow enough not to damage the electrical actuators nor the mechanical structure and joints.

On the other hand, a chattering reduction technique is part of the future research to be done and also the design and development of a sliding mode controller to solve the tracking problem of an uncertain very lightweight single-link flexible arm with high varying payload

  computing a finite number of time derivatives of output signal.

  to as the input and output respectively. The matrices A , B , C will be termed the system, input and output distribution matrices respectively. The uncertain vector function sum of matched nonlinearities and/or uncertainties.

  to be known constant matrices. The square matrix 2 B is non-singular because the input distribution matrix is assumed to be of full rank. The new coordinates are defined as

  have stable eigenvalues. The switching surface design problem can therefore be considered to be one of choosing a state feedback matrix M to stabilize the reduced order system )

.

  The frame makes the stable and free rotation of the motor around the vertical axis of the platform possible. The motor shaft is capable of turning either right or left around the Z axis. Furthermore, a servo-amplifier is used to supply the DC motor. This amplifier accepts control inputs from the computer in the range [ ] the sensor system is integrated by an encoder embedded in the motor, which allows us to know the motor position with a precision of )

aJ

  , and the real value of the motor, J :

  represented in the fourth column of Table1. Note that the error % ε increases if δ increases. Such values vary from that the steady state error is null in both cases, although the maximum trajectory tracking error % ε increases with the δ value.

Fig. 1 .

 1 Fig. 1. Results when 1 20 δ ≤ ≤ .

Fig. 2 θ

 2 Fig. 2 shows the experimental results obtained when 1 20 / 1 ≤ ≤ δ

Fig. 2 .

 2 Fig. 2. Results when 1 / 20 1 δ ≤ ≤

Table 1 .

 1 Result 1.

	Signal	δ	J % =	J	a	ε	%
	θ	m		1	100	%	2	.	25
	θ	m	2	2	50	%	2	.	92
	θ	m	3	3	33	.	33	%	18	.	13
	θ	m	4	5	25	%	51	.	78
	θ	m	5	10	10	%	. 69	20
	θ	m	6	15	6	.	67	%	. 76	74
	θ	m	7	20	5	%	80	.	84

  depicts the correspondence between the signals m m θ . All the trajectories have null steady state error and the trajectory tracking errors % ε do not increase (see fourth column of Table

												θ to
	θ	13 m	with regard to the ratio δ . The third column of this table shows the
	percentage	a J J	⋅	100	. Note that the most unfavourable case	δ	=	1	/	20	corresponds to
	inertia of the motor which is 20 times greater than the controller design inertia.
	Observe that the trajectories m θ to 13 m θ are superimposed on the reference trajectory

*

& & & &

Acknowledgments. This research was supported by the Spanish Government Research Programme via Project Ref.: PBI-05-057, by the Consejería de Educación y Ciencia de la Junta de Comunidades de Castilla-La Mancha and European Social Fund.


Daniel Cachapa
email: daniel.cachapa@de.schneider-electric.com

Robert Harrison
email: r.harrison@lboro.ac.uk

Armando Colombo
email: armando.colombo@de.schneider-electric.com

Improving Energy Efficiency in the Production Floor Using SoA-based Monitoring Techniques

Keywords: SoA, Web Services, Production Monitoring, Simulation

Modern manufacturing systems are struggling to remain competitive under the pressures of and increasingly demanding society. The advent of SoAbased production systems is presented as the solution to facing those difficulties. In order to support this new production paradigm, new tools have to be developed for the benefit of the production engineers of who will be implementing and deploying the SoA-based factory floor. This entails the development of Smart Devices, which while being autonomous are able to communicate and cooperate in an open and standardized way with other participants in the production system. These capabilities can be exploited in order to implement a next-generation production monitoring system that is not only able to monitor production status, but also energy usage, eventually leading to much greener and more efficient factories.

Introduction

Modern industrial manufacturing is facing pressure from all directions: governments want greener and safer products, while costumers demand quality, customization and lower prices. In order to face these challenges in an age of technological boom, companies are turning more and more to machines to accomplish the tasks previously made by human.

The field of factory automation has been a pioneer in this area and has evolved much in the past few years as machines get ever more sophisticated and efficient. Nevertheless, these changes have also raised the complexities involved in maintaining and controlling them. Implementing a modern factory floor is an incredibly expensive and time-consuming labour as production specifications must be transformed into the machine code connecting all of the devices together. Likewise, a monitoring framework must also be implemented so that production engineers can have a realtime view of the machine's status, production flow, energy usage, stock management, as well as other essential production indexes.

It is expected that the event-based, high-level and decoupled nature of SoAenabled production devices will allow for easier integration, configuration and maintenance of factory monitoring systems, while at the same time improving the performance and capabilities over traditional systems. The study of monitoring and energy efficiency issues in SoA-based factory automation relies not only on following current state-of-the-art in the relevant areas, but also on the building of prototype engineering solutions that demonstrate the proposed methodologies. Those solutions should be engineered based on existing use-cases that represent current industrial needs.

Contribution to Technological Innovation

The flexible production line requires the development of modular devices which can be plugged into the production line and participate in a cooperative network configured to accomplish a given task. The devices themselves should be autonomous in the sense that they don't depend directly on any of the other participants in the network to achieve their full functionality, which means that the devices are individually programmed and tested before reaching the production line.

This entails: • Developing building blocks -Intelligent functions embedded into devices (profiles, HMI, tools, web, agents) • Making the blocks work together -Design of networked autonomous and fault adaptive systems (protocols, robust, security) • Assuring a common objective -Concepts, methods and tools for building robust, reconfigurable intelligent systems and guarantee expected overall system behaviour Also important is that the devices are able to communicate in a standards-based manner with the other participants in the network. Standardization guarantees better flexibility for the system builder in mixing and matching parts from different suppliers, creating a fairer market for device builders and thereby reducing costs through the power of healthy competition in the marketplace.

The requirements described above are embodied in the tenants of SoA as it describes a standards-based network of autonomous participants which work together in order to reach a common goal. Specifically, the use of SoA and Web Service technology from the enterprise level all the way down to the device level yields the following benefits:

• Easy adoption: it is possible to deploy the technology incrementally either by gradually replacing components, or using middleware solutions in older equipment (Priyantha, Kansal, Goraczko, & Zhao, 2008). • Easy integration: made possible by the standards-based nature of SoA and WS technology. • Easy to develop new applications: SoA and Web Services are at the heart of new programming paradigms heavily endorsed by influential software companies such as Microsoft® and Sun®.

• Reduced time for setup: made possible by the high-level nature of Web Services, and facilities such as discovery and eventing. Bringing SoA into the production line requires a careful design in order to keep a clean architecture with clear hierarchical separation between different levels and usage patterns. The implementation must account for the requirements of the current production runs, as well as being ready to quickly incorporate changes in the production process, while at the same time supporting use cases that can range from production control to production monitoring, to business process management [START_REF] Karnouskos | Integration of SOA-ready Networked Embedded Devices in Enterprise Systems via a Cross-Layered Web Service Infrastructure[END_REF].

With energy prices are on the rise, and environmental concerns coming from both consumers and governmental agencies, the industry is concerning itself greatly with energy savings on the shop floor, which not only have the potential of yielding savings directly on the energy bills and environmental taxes, but also having an impact on sales as the marketing department is allowed to stick a "green" label on the end-user packaging.

The research presented here aims to develop a SoA-based framework for decoupled factory devices, and use it to perform monitoring of production data, with a particular emphasis on energy usage, in order to research viable energy management strategies for the factories of the future.

State-of-the-Art / Related literature

Many SoA-based frameworks have been proposed, such as in [START_REF] Colombo | Integration of Web-Services and Agent Technology: A Service-Oriented Architecture-based Automation Framework[END_REF], where the author separates the production system into three hierarchies: the embedded components (TEC), composed into embedded machines (TEM), which themselves are arranged into embedded production systems (TES). In [START_REF] Lastra | Reference Mechatronic Architecture for Actor-Based Assembly Systems[END_REF], the author presents a similar approach dubbed Actor-based Assembly Systems in which simple SoA-based devices with limited functionality are composed together to build complex production systems. In {Document Not In Library} the authors present a similar framework of SoA-based devices using the OPC Unified Architecture. These frameworks have many things in common, which represent the central tenets of the SoA-based production system: a society of autonomous devices which cooperate in order to achieve the functionality required for the production objectives.

The research presented here builds upon the same basic procedures and techniques in order to build a fully functional production system. Much of the work follows the groundwork laid down in the SIRENA (Jammes & Smit, 2005)

Research Contribution and Innovation

The research plan for the work presented here is separated in two stages: the development of a SoA-based framework for factory devices, and the leveraging of that framework in order to perform event-based monitoring of production and energy data.

The first and most essential step in the creation of a test production line based on the SoA paradigm is the availability of "smart devices". The concept of a Smart Device is used to describe a device that is designed from the ground up to be autonomous and cooperative. Smart devices integrate the kinematics; the behaviour, which is exposed to the outside as services; and, in the case of a virtual device, the geometry, or physical dimensions of the device it represents. Smart Devices can thus be brought into the production line, connected to the network, and have their full functionality immediately available for the controller to exploit with minimal configuration. The procedure of developing a virtual smart device in the Delmia Automation environment with a DPWS-based service interface which is identical to the one available from the corresponding real device is described in [START_REF] Cachapa | An Approach for Integrating Real and Virtual Production Automation Devices Applying the Service-oriented Architecture Paradigm[END_REF].

The Smart Devices feature fixed input and output ports at its physical boundaries, so that different devices can be connected at their ports in order to build a continuous sequence of machines that can transport work pieces inside the production cell. The ports themselves are intimately connected to the device's internal functionality and exposed as individual services, meaning that the physical composition of devices is also reflected in the functional composition of the respective services associated to those ports. Two or more devices can be composed in this manner in order to form composed devices, which abstract the interactions between the individual devices and whose resulting characteristics may be different from the simple sum of the capabilities and limitations of each component. The composed devices can be themselves composed into new composed devices of an even higher hierarchy.

By linking and composing smart devices together, a full, SoA-based production system can be assembled. This technique was demonstrated in [START_REF] Leitão | Engineering Tools for the Integration of Service-oriented Production Systems[END_REF] where a virtual SoA-based production cell, shown in Fig. 1a) was built according to an existing physical cell, shown in Fig. 1b), and used to aid the development of the production controller. Since all participants in the production line share the same network and high-level functionality, and the components in both the virtual and the real environments appear in the network as autonomous devices, there is no difference in functionality between them from the controller's point of view, which allows replacing some of the virtual components for real ones for testing purposes. The outcome is an open architecture where all the participants can communicate freely according to their function, as seen in Fig. 2. Thanks to the high-level nature of the services provided by the smart devices, the device operations have a one-to-one mapping between both the real and virtual worlds, meaning that as long as all the devices are accessible in the network, the same controller is able to perform the same set of operations in the virtual and real worlds without the need for any specific platform dependencies. Fig. 3 shows an example of this mapping during a transfer operation from one smart device to another. This technique allows the production engineer to validate the production cell's layout and process control on the virtual production floor, and later replace the virtual devices for real ones as necessary for testing until the control software is running the full, physical, production cell. Similarly, the installation of a new device can be tested offline by first connecting it to the virtual model, and replacing it with the real device only after the new configuration has been validated.

Event-based Monitoring of Production and Energy Data

The initial steps towards a SoA-based production monitoring system for factory automation begin with a study of existing systems and a gathering of the requirements for such a system, as well as a wish list for improvements. The results of this study were as expected: monitoring systems are proprietary, in-house solutions, and are based on a patchwork of barely compatible and sometimes outdated technologies. This is the outcome of the systems having been built many years ago to face the growing pains of production automation, and then growing organically to face the ever increasing complexity of today's factories. The end result is a complex system layout featuring multiple closed networks interconnected by data exchangers, bridges and various middleware solutions.

The same SoA-based platform which is useful for aiding development of production systems could be used for performing real-time production monitoring. The event-based nature of the Smart Devices, coupled with other state-of-the-art technologies, such as RFID, allows for efficient tracking of materials, resources and operations over the production lifecycle. This would make it possible to use a single, open and standards compliant network throughout the entire factory floor, which would facilitate integration of new devices in already existing facilities.

Furthermore, the same system can be used to plug in to the various energy consumers participating in the production system, such as the facilities, lighting, heating, and others. Having detailed real-time and historical energy data will go a long way towards finding energy inefficiencies in the production process and researching ways of optimizing or eliminating them.

Discussion of Results and Critical View

The results achieved so far demonstrate that a SoA-based engineering tool can support the production engineer by greatly simplifying the process of production line layout and configuration. The simulation capabilities offered by the tool are indispensible for quick prototyping and testing of the capabilities, performance and throughput of the production process.

Furthermore, both the high-level nature the Web Service-based components and the generic support of the virtual 3D platform enable the quick development of new components and their adaptation into an existing production environment, where they can be thoroughly tested before deployment.

After deployment, the same technologies can serve as the base to a next-generation production monitoring system, replacing the current proprietary ones which face enormous limitations due to their complexity and forced support for legacy technologies.

The open and standard nature of the technologies and protocols used in the communication between the different devices enable a future where factories don't have to rely on a limited set of vendors for all of their production or control devices, but instead, benefit from an ecosystem where competing companies which all develop their products targeting the same standards, giving rise to a modular factory floor where the different machines are mixed-and-matched according to their quality, capabilities and price.

That's not to say that a new system would solve all the problems overnight. Initially, the SoA-based production monitoring system would either function parallel to the existing systems, or legacy technology would have to be adapted through the use of middleware software.

Conclusions and Further Work

It is unquestionable that the current tools for production engineering aren't capable of supporting the advent of SoA in the factory floor. For this reason, new tools and techniques will have to be developed.

The research presented here lays the groundwork for developing SoA-based virtual production lines based on proven industrial standards. These tools are an essential platform for conducting further research in the fields of production control and monitoring.

The first glimpses on the current state of production monitoring in use today show that there is much that can be improved. The event-based and open nature of the SoAbased production system makes it ideal for tackling the problem of monitoring the factory floor. It is hoped that the research into these issues culminates in a standard, extensible set of guidelines for production monitoring systems which follow closely current industrial requirements.

  and in the SOCRADES (de Souza et al., 2008) projects, as well as the RI-MACS project {Document Not In Library}. It is also closely related to the objectives put forward by the CONET {Document Not In Library} research project. The developments and tools developed in support of the research are mainly supported upon the Devices Profile for Web Services (DPWS) communication stack (Jammes, Mensch, & Smit, 2005) under the development umbrella of the SoA4D group {Document Not In Library}, and the Delmia Automation CAD suite {Document Not In Library} as a simulation/visualization tool. The results of the early experiments with these sets of tools are described in (Cachapa, Colombo, Feike, & Bepperling, 2007) and (Leitão et al., 2009).

Fig. 1 .

 1 Fig. 1. Virtual and real representations of a SoA-based production cell.

Fig. 2 .

 2 Fig. 2. Virtual SoA-based production system with hardware in the middle.

Fig. 3 .

 3 Fig. 3. Mapping operations in the real world to the virtual world using SoA-based real and virtual smart devices.

Acknowledgments. The authors would like to thank the European Commission and the partners of the EU IST FP6 project "Service-Oriented Cross-layer infrastructure for Distributed smart Embedded devices" (SOCRADES) and the EC ICT FP7 NoE project "Cooperating Objects" (CONET) for their support. Further recognition is due to the brilliant engineers at the Ford Motor Company in Dunton UK.


Alvaro L Barradas

Maria Do

Carmo R Medeiros
email: cmedeiro@ualg.pt

Simulation Model for OBS Contention Avoidance Routing Strategies

Keywords: Optical networks, Network architecture and design, Optical burst switching, Contention avoidance, Routing strategies, Simulation

Optical burst switching (OBS) provides a feasible paradigm for the next IP over optical network backbones. However, due to its bufferless nature, OBS efficiency can be reduced by resource contention leading to burst loss. Several methods have been proposed to address this problem, most of them relying on reactive mechanisms which increase the complexity of core nodes, hampering scalability. In this work we consider a preventive traffic engineering approach for contention resolution which provides source routing with the objective of minimizing contention at the transmission links considering only topological information. This paper presents a simulation model aimed at the evaluation of different offline routing strategies in terms of burst contention. The simulation model is used to compare the performance of different novel path selection strategies with the traditional shortest path routing approach. Results confirm that the proposed strategies are effective in reducing the overall blocking and the model is feasible for the proposed QoS evaluation.

Introduction

Optical burst switching (OBS) [START_REF] Qiao | Optical Burst Switching (OBS): A New Paradigm for an Optical Internet[END_REF], [START_REF] Chen | Optical Burst Switching: A New Area in Optical Networking Research[END_REF] has emerged as an efficient switching paradigm for the core of IP over optical networks. OBS avoids the inefficient resource utilization of Optical Circuit Switching (OCS) and the requirements of buffers, optical logic processing and synchronization problems of Optical Packet Switching (OPS). In OBS the basic transport unit is the burst, an aggregate message that can be regarded as an optical ``super packet'' containing multiple IP packets going to the same egress node and (if used) grouped by some Quality of Service (QoS) criteria. Bursts are assembled at the ingress nodes and their transmission is preceded by dedicated setup messages, transmitted on a dedicated control channel with the purpose of reserving bandwidth along the path for the upcoming data bursts. Based on the information carried by the setup messages, the intermediate nodes reserve switching resources along a pre-configured path, providing an optical channel through which data bursts can be transmitted, after an adequate delay, from source to final destination without any optical-electrical-optical (OEO) conversion [START_REF] Chen | Optical Burst Switching: A New Area in Optical Networking Research[END_REF], [START_REF] Xiong | Control Architecture in Optical Burst-Switched WDM Networks[END_REF]. OBS, like other switching paradigms, does not perform well in overloaded scenarios and can present low reliability since it generally uses one-way reservation protocols, where data bursts are transmitted without confirmation that resources along the path will be successfully reserved to establish the required end-to-end transparent connection. Consequently, whenever the number of simultaneous reservation attempts exceed the number of available resources some will fail and, owing to the lack of sophisticated optical buffers, will result in burst loss. Burst loss degrades the global OBS performance since dropping leads to rescheduling of lost data with significant impact on any endto-end applications running in the network layers above, reducing its overall throughput. Therefore, minimizing burst loss is a key factor for the practical implementation of OBS networks.

Considerable effort has been devoted to the study of different methods to handle contention, including, burst scheduling, optical buffering, burst segmentation, wavelength conversion, and deflection routing [START_REF] Li | Recent Progress in the Scheduling Algorithms in Optical-Burst-Switched Networks[END_REF], [START_REF] Jue | Optical Burst Switched Networks[END_REF]. These are mainly reactive mechanisms driven by burst contention and requiring extra hardware and/or software components at each core node, significantly increasing their cost and complexity, leading to scalability impairments. A simple and cost efficient solution is to deploy contention mechanisms at the edge nodes. This approach has been followed by using burst assembly mechanisms [START_REF] Vokkarane | Prioritized Burst Segmentation and Composite Burst-Assembly Techniques for QoS Support in Optical Burst-Switched Networks[END_REF], [START_REF] Jin | Provision of Differentiated Performance in Optical Burst Switching Networks Based on Burst Assembly Processes[END_REF], by path selection and wavelength assignment [START_REF] Zhang | Absolute QoS Differentiation in Optical Burst-Switched Networks[END_REF], [START_REF] Teng | Wavelength Selection in OBS Networks Using Traffic Engineering and Priority-Based Concepts[END_REF] or by balancing the traffic load between alternate paths [START_REF] Teng | Traffic Engineering Approach to Path Selection in Optical Burst Switching Networks[END_REF], [START_REF] Li | Dynamic Load Balancing in IP-over-WDM Optical Burst Switching Networks[END_REF].

Path selection mechanisms at the ingress nodes can alleviate contention when compared with the shortest path (SP) routing. Although successfully used in both circuit switching and packet switching networks, SP routing does not take into consideration the traffic load offered to the network, and it often causes certain links to become congested while other links remain underutilized [START_REF] Teng | Traffic Engineering Approach to Path Selection in Optical Burst Switching Networks[END_REF]. This is highly undesirable in bufferless OBS networks, since a few highly congested links can lead to unacceptably high burst loss values for the entire network, corroborating contention avoidance strategies as an important feature in the OBS field.

The paper is organized as follows. After an introductory section where some OBS intrinsic problems are considered together with a brief state of the art, Section 2 presents the objective of the paper and its main contribution to technological innovation. Section 3 presents the simulation model and describes the OBS network simulator. Section 4 evaluates the performance of a path selection strategy and Section 5 concludes the paper with final remarks and further work for the near future.

Contribution to Technological Innovation

The aim of this paper is to present a simulation model for the evaluation of preventive routing strategies intended to minimize the global network contention and the overall burst loss through the adoption of optimized path selection strategies. Our approach uses only topological information to be integrated in an integer linear programming (ILP) formulation from which optimized routes are obtained. These routes can be used alone, as single-path static routes to provide load-balancing without the need for additional control messages with regard to link status or, alternatively, combined with dynamic contention resolution schemes (deflection or segmentation) and used occasionally as a default routing scheme to assume whenever the network needs to recover from instability, favoring the network resilience.

This offline source routing approach presents the following a priori advantages: no extra hardware or software components are required on the core nodes and no network flooding with signaling messages resulting from (over)active link state update protocols. Moreover, with this approach there is also no place for out-of-order arrivals, a frequent disadvantage of multipath routing schemes typically requiring large memories at the edge nodes for re-ordering operations. These are distinguishing qualities to make the architecture of the OBS nodes less complex, contributing to reduce both their cost and scalability impairments.

Simulation Methodology

The simulation model described in this paper is deployed in two stages. The first stage, which comprises the determination of routing paths, is the optimization stage and was developed with the CPLEX optimizer. In this stage a routing problem is formulated using ILP, which is a widely used approach to address both high level and system level synthesis. Taking into account the computation times involved (which have been found in a range between tens of seconds and some minutes), the relatively infrequent update requests expected from changes in the OBS backbones whose topologies typically last for long time scales, and the quasi-stationary aggregate traffic demands at optical backbones, which are expected to change relatively slowly [START_REF] Chen | Route Optimization in Optical Burst Switched Networks Considering the Streamline Effect[END_REF], this approach can be considered feasible for the real production of OBS networks by means of an operation process to be executed during its initial setup phase. The second stage, which comprises the application of the routing solution, is the simulation stage in stricto sensu, where the optimized paths produced on the first stage are incorporated into an OBS network simulation model.

First Stage -Routing Path Determination

Several optimization strategies for contention avoidance have been under evaluation for which different routing paths were calculated: minimizing the Max Congested Link (MCL), based on the idea that the more a certain link is included in the chosen paths for source-destination pairs, the highest the blocking probability can be [START_REF] Barradas | Edge-Node Deployed Routing Strategies for Load Balancing in Optical Burst Switched Networks[END_REF]; minimizing the Maximum End-to-end Congested (MEC) path, based on the idea that blocking may occur at any link traversed by a burst along the path [START_REF] Barradas | Edge-Node Deployed Routing Strategies for Load Balancing in Optical Burst Switched Networks[END_REF]; and two strategies considering the streamline effect [START_REF] Chen | Route Optimization in Optical Burst Switched Networks Considering the Streamline Effect[END_REF], a reported phenomenon unique to OBS networks wherein bursts traveling in a common link are streamlined and do not contend with each other until they diverge. One of these strategies, entitled Streamline-Based Preplanned Routing with no Pre-determined Paths (SBPR-nPP) was recently published in [START_REF] Barradas | Pre-planned Optical Burst Switched Routing Strategies Considering the Streamline Effect[END_REF] and, as an example, its ILP formalization will be succinctly presented next. The solution of this ILP problem will be used to drive source routing decisions on the second stage of this simulation methodology.

SBPR-nPP strategy. Let

) , ( L N G be a network graph where N is the set of nodes and L is the set of links, and let us define a path over which a burst must travel, v , as a connected series of directed links, written as

) ( ) ( : v d v s v →
, from source node

) (v s to destination node ) (v d .
The set of paths that can be used by a burst from s to d is defined as

)} ( ), ( | ) ( ) ( : { , v d d v s s v d v s v V d s = = → =
and the set including all d s V , is defined as V . We also define

1 = v l p if link L l ∈ is included in v , 0 = v l p
otherwise. When taking a specific node as a reference point, a link coming out of that node can be denoted as out l and a link coming into that node can be denoted as in l . The total number of elements in N , L and V is denoted by N , L and V . In this strategy the algorithm must find a route for burst delivery between each d s → pair of nodes, which means that no pre-determined selection of routes exists. The main goal of the next objective function is to minimize MAX ζ , a global bound that stores the highest number of routes competing for an output link. The second component of the objective function is a secondary goal to find routes having a small number of hops and also to avoid loops.

∑ ∑

∈ ∈ - + N d s L l d s l MAX , , 1) LN(N 1 Minimize θ ζ (1) subject to , otherwise 0 if 1 if 1 ) ( : , ) ( : ,      = - = - = ∑ ∑ = ∈ = ∈ d i s i i l d L l d s l i l s L l d s l in in in out out out θ θ (2) N i N d s ∈ ∀ ∈ ∀ , , ∑ ∈ = ∈ ∀ ∈ ∀ ≥ N d s out out d s l i i l s L l N i out , , ) ( : , , θ ζ (3) N i i MAX ∈ ∀ ≥ , ζ ζ (4) MAX i d s l ζ ζ θ , } 1 , 0 { : integer negative - non ; , ∈ (5)

Second Stage -Routing Path Application

The application of the routing paths calculated in the first stage is done by simulation using an OBS model developed within the OMNeT++ simulation environment [START_REF] Varga | An Overview of the OMNeT++ Simulation Environment[END_REF] and some programming effort in C++.

The functional architecture of our OBS model has the same characteristics of the one presented in [START_REF] Xiong | Control Architecture in Optical Burst-Switched WDM Networks[END_REF] assuming that each node can support both new input traffic generated by the client networks as well as in transitu traffic passing all-optically from source to final destination. This study uses the following three networks: ARPAnet, NSFnet, and COST239 whose topologies are presented in Fig. 1. The nodes are connected by optical fibers with 16 wavelengths per link and a transmission capacity of 10 Gbits per second (per wavelength). The adopted traffic assumes a Poisson pattern with a threshold-based assembly method, generating bursts with size 100 Kbytes. Bursts are forwarded through the core backbone reproducing the relevant actions of the Just-Enough-Time (JET) [START_REF] Chen | Optical Burst Switching: A New Area in Optical Networking Research[END_REF] scheduling scheme. The control information processing time is assumed to be 10 µs per core node, although other values from 12.5 µs to 1 µs could be adopted depending on the technology in place.

The model employs source routing, in which a complete routing decision is taken at the ingress edge node. The path over which the burst must travel is carried on the setup message that precedes the transmission of each data burst and will not be modified by downstream nodes. The adopted path is fetched from the edge node's routing tables previously populated by the results of the path selection strategy discussed in the Section 3.1. Core nodes do not employ any buffering in the data path and they do not use deflection, but full wavelength conversion is assumed. Thus, a burst is blocked only if there are no free wavelengths available to accomplish the 'next hop' on a predetermined path to a certain destination. If scheduling fails the burst is simply dropped and no further contention resolution method is adopted. Together with the network topology description, the simulation model is essentially composed of OBS capable nodes interconnected by optical fibers. The model is based on two main modules, Edge Node and Core Node, with snapshots depicted in Fig. 1. These modules will be presented next using their functional perspective. Edge Nodes. Used to connect multiple subnetworks running on top of legacy link layer protocols to the OBS network. They can be considered either as ingress or egress nodes. When acting as ingress nodes, they are responsible for aggregating the incoming packets into bursts, for taking the initial (and here also permanent) routing decision, and for scheduling the bursts for transmission on outgoing channels. When acting as egress nodes, they perform the inverse operation, i.e., burst disassembly and packet forwarding to upper layers. In our model we assume the burst as the basic transport unit of interest. Hence, the issue of the packet aggregation policies is considered out of scope. Thus, whenever a Poisson process timer expires, a new burst is generated, a destination address is chosen at random between all other nodes in the network, a route to the destination node is taken from the source node's optimized routing table and an initial wavelength is randomly selected among the free ones. The burst is then retained on a system queue organized by destination address and the signaling process starts with the sending of a setup message on the appropriate dedicated channel. The setup message is always transmitted before the corresponding burst and apart from it by an adequate offset time. The model calculates this offset time in order to allow this message to be processed at each subsequent node before the burst arrival and in such a way that an optical path can be properly reserved for burst delivery.

Core Nodes. Responsible for processing setup messages, for switching the bursts from an input to an output port without OEO conversion and for handling contentions. Signaling in OBS is typically implemented using one out-of-band channel (λ 0 is used in this model). Several signaling schemes have been proposed for burst scheduling but Just-in-Time (JIT) and Just-Enough-Time (JET) are two of the most popular protocols in OBS networks. These are both one-way and source initiated signaling schemes, which means that bursts are sent to the core network without waiting for acknowledgments regarding the success or failure of the reservation attempts. Although closely related, they differ on the duration of the reservations. JIT uses immediate reservation with the data channel being reserved immediately since the moment the setup message reaches the node, while JET delays the channel reservation until the burst arrival. This technique, together with the implicit release, makes JET more efficient than JIT regarding bandwidth utilization, resulting in lower blocking rates and low end-to-end delay [START_REF] Jue | Optical Burst Switched Networks[END_REF]. The study presented here assumes a JET-kind behavior scheme. Together with burst forwarding without leaving the optical domain, core nodes are also responsible for taking contention resolution actions. Contention occurs when multiple bursts from different sources are destined for the same output port at the same time [START_REF] Jue | Optical Burst Switched Networks[END_REF]. Adding to the initially path selection strategies adopted on the edge nodes, the handling of burst contentions by the core nodes assume that they are equipped with devices having full wavelength conversion capability. This means that no end-to-end wavelength continuity constraint exists, and that any incoming wavelength can be shifted to any outgoing wavelength. As a result, only if there is no wavelength available on the output port the burst will be dropped without any further contention resolution action.

Performance Evaluation

For each network topology represented in Fig. 1 simulations were done using a specifically developed OBS simulator, assuming similar conditions with regard to the total amount of bursts generated per source node (10 6 ), arrival patterns and load variations. Results comparing the performance of the proposed path selection scheme with the SP routing are plotted in Fig. 2 with burst loss values normalized to the number of bursts that enter the network backbone against the average load. The plotted values of SBPR-nPP are always bellowing SP. This means that network performance can profit from balancing the potential path-load at the output links with these strategy. The graphics show also a progressively larger advantage for our algorithm following the increase of the physical connectivity parameter, with best results obtained for the COST239 European topology. This happens, because the higher connectivity of this network allows obtaining alternative paths to spread the potential traffic without extending them too much in terms of hop count. But even for the American ARPANET topology, which presents much lower connectivity values, a small benefit can be obtained with this approach.

Conclusion and Further Work

We consider the problem of routing path selection in OBS networks to minimize the overall burst loss due to resource contention of bursts aimed at the same output links. We take a preventive TE approach to provide source routing with minimized contention using only topological information and, in the case of the presented example, considering also the streamline effect. The proposed algorithm performs significantly better than the SP routing, with best performance obtained for networks characterized by having high physical connectivity.

Several research directions can be distinguished for future work. Among them, the adoption of combined routing strategies depending on traffic load variations can result in better performance. Another improvement can exploit the combined use of this static routing approach with the three basic deflection domains (time, space and wavelength) for contention resolution.

θ

  is a binary variable that indicates if the route for the s-d pair of nodes, used to carry bursts, uses link l . Constraint 2 guarantees flow conservation of every route. For a specific node i , constraint 3 stores in i ζ the highest number of selected routes competing for an output link, and constraint 4 stores in MAX ζ the maximum value of all i ζ . The main goal of the objective function is to minimize MAX ζ , the global bound.

Fig. 1 .

 1 Fig. 1. Network topologies, and snapshots of edge node and core node (left to right).

Fig. 2 .

 2 Fig. 2. Evaluation of SBPR-nPP vs. SP with normalized burst loss against average load.

Acknowledgments. The work reported in this paper was supported in part by FCT within CEOT (unit 631) at the University of Algarve, Portugal, under the project PTDC/EEA-TEL/7168/2006.


Paul Chaignon

Kahina Lazri

Jérôme Franc ¸ois † Olivier Festor

Understanding Disruptive Monitoring Capabilities of Programmable Networks

The design shift proposed by OpenFlow, with its simple stateless dataplane, initially contributed to the success of Software-Defined Networks. Its lack of state, however, prevents the implementation of many dataplane algorithms. Network applications must therefore offload stateful operations to the control plane, thereby increasing latency and limiting network scalability. Thus, recent research efforts centered on the addition of stateful properties to switches.

In this paper, we discuss the impact of emerging programmable dataplane abstractions on network monitoring. In particular, we investigate the need for dataplane states in the design of scalable monitoring applications. We argue that these abstractions are ill-suited for software switches as they retain hardware-specific limitations. Furthermore, we analyse the impact of stateful dataplane designs on the control plane visibility of the network. Finally, we identify opportunities for improvement in the design of stateful software switches.

I. INTRODUCTION

Traditional computer networks consist of interconnected fixed-function devices implemented on Application-Specific Integrated Circuits (ASICs) for line-rate processing. They comprise switches and routers for forwarding as well as middleboxes for specific functionalities, such as access control, intrusion detection, and load-balancing. Forwarding devices implement distributed network protocols for the control plane. Thus, the control and forwarding planes (also called dataplane) are tightly coupled inside closed-source network devices, which complicates the deployment of new protocols. Furthermore, these devices expose limited vendor-specific control interfaces that hinder network configuration processes.

The Software-Defined Network (SDN) paradigm aims at decoupling the control plane from the dataplane. Forwarding devices are controlled by a separate, centralized entity, the controller, through open interfaces. While logically centralized, the controller may still be distributed for scalability and fault-tolerance. Applications interfaced with the controller implement the intelligence of the network, whether it be traffic engineering, access control, or anomaly detection.

The SDN decoupling logic arises from a simple observation. Whereas the dataplane benefits from a hardware implementation for line-rate processing, the control plane benefits from a more flexible multi-purpose implementation. Thus, with SDN, switches and routers become simple forwarding devices while commodity servers host the control plane.

The interface between the controller and switches was initially standardized by the OpenFlow protocol [START_REF] Mckeown | Openflow: Enabling innovation in campus networks[END_REF]. It ad-vocates simple stateless switches exposed through a matchaction abstraction. This abstraction is particularly well-suited for traffic engineering applications as they leverage the global view of the centralized controller and require few functionalities from SDN switches [START_REF] Jain | B4: Experience with a Globally-Deployed Software Defined WAN[END_REF]. Applications that do not fit the stateless match-action abstraction must rely on the control plane. Control plane implementations, however, incur higher latencies and stress the control to dataplane path.

This limitation is particularly challenging for monitoring applications. They all require their own peculiar view of the network: flow statistics for heavy-hitter detection [START_REF] Jose | Online measurement of large traffic aggregates on commodity switches[END_REF] and round trip times for TCP performance analysis [START_REF] Ghasemi | Dapper: Data Plane Performance Diagnosis of TCP[END_REF], for example. Monitoring applications could summarize measurements at the dataplane, but the limited capabilities exposed by OpenFlow force switches to send large quantities of raw measurements to the controller.

The inadequacy of OpenFlow for network monitoring was recognized and discussed early on in [START_REF] Curtis | Devoflow: Scaling flow management for high-performance networks[END_REF], [START_REF] Yu | Software defined traffic measurement with opensketch[END_REF]. Enabling preprocessing of measurements in the dataplane requires persistent switch memories -referred to as the dataplane state -to store intermediate results. Recent proposals for new SDN paradigms explored how this dataplane state can be exposed to applications at the control plane.

In this paper, we investigate how these expositions of the dataplane state impact the design of monitoring applications. In particular, an unconstrained access to this state enables the implementation of any dataplane algorithm [START_REF] Sonchack | Enabling practical software-defined networking security applications with OFX[END_REF], [START_REF] Mekky | Application-aware data plane processing in sdn[END_REF], but introduces two main challenges. First, it limits the control plane's visibility, as any action taken based on the dataplane state becomes invisible to the controller. Second, an unconstrained access to the dataplane state is only possible on commodity hardware and thus, achieves two orders of magnitude lower performance than fixed-function ASIC switches. This second challenge was the subject of recent advances in hardware design, with the emergence of the first programmable ASIC switches with stateful processing capabilities [START_REF] Networks | Barefoot Tofino[END_REF]- [START_REF] Bosshart | Forwarding metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN[END_REF].

The remainder of this paper is organized as follows. In section II, we detail the challenges for the implementation of monitoring algorithms. We then classify research proposals in section III according to the flexibility they offer for stateful dataplane implementations. In section IV, we analyze the implications for the control plane's global view. Finally, in section V, we discuss shortcomings in recent emerging stateful designs and identify new research opportunities.

II. NETWORK MONITORING CHALLENGES

Several scalability challenges for network monitoring applications in SDNs stem from dataplane resource limitations and affect both software and hardware switches [START_REF] Moshref | Resource/accuracy tradeoffs in software-defined measurement[END_REF].

A. Hardware Resource Limitations

Resource limitations in hardware switches are two-fold. First, flow tables in hardware switches have a limited size due to the use of Ternary Content-Addressable Memories (TCAMs). Switches use TCAMs to store and match against wild-card flow rules. These hardware components are expensive and consume considerable power and ASIC space. Thus, switch vendors often rely on less expensive and powerhungry Binary Content-Addressable Memories (BCAMs) and Static Random Access Memories (SRAMs) [START_REF] Moshref | Resource/accuracy tradeoffs in software-defined measurement[END_REF]. Second, hardware switches have limited CPU capacity, essentially used by auxiliary components, such as the OpenFlow switch agent.

Conversely, because software switches rely on commodity hardware, they dispose of large amounts of slower memories, DRAMs, with transparent memory caches on SRAMs. Servers can allocate enough DRAM space for the switch software to store hundred of thousands of rules. The CPU, however, is a limiting factor [START_REF] Pfaff | The Design and Implementation of Open vSwitch[END_REF]. The number of CPU cycles needed to process one packet determines the switch's throughput and latency. To avoid context switches, operators often dedicate a core to the switch. Nevertheless, auxiliary functions of the switch, such as rule management, run on that same core and, as such, may impact performance.

B. Scalability Challenges

Hardware resource limitations introduce a trade-off between the granularity of measurements and the consumed resources. Because of this trade-off, monitoring large-scale networks is challenging, and network operators often resort to inaccurate sampling-based measurements.

The first scalability challenge stems from the strict binding between flow rules and counters and the resulting trade-off between the granularity of flow rules and the accuracy of statistics. For example, if an application defines flows based on their destination IP addresses, switches will report a single set of counters per destination IP address. Thus, an application that relies on fine-grained visibility of flows needs to install additional rules in switches.

The number of flow rules, however, is limited in both hardware and software switches. In hardware switches, wildcard rules are typically stored in TCAMs. As a consequence, while they support large numbers of exact-match rules, they can only match against a limited number of wildcard rules [START_REF] Curtis | Devoflow: Scaling flow management for high-performance networks[END_REF]. In software switches, there is no hard constraint on the number of flow rules. Nevertheless, with a high number of flow rules, the switch's CPU will spend more time managing rules, revalidating caches, and retrieving statistics for cached rules [START_REF] Pfaff | The Design and Implementation of Open vSwitch[END_REF].

The second scalability challenge involves the frequency of statistic reports to the controller. A short delay between two statistic reports enables timely reaction to network events, but strains the path to the controller: the switch component that retrieves and sends statistics consumes CPU cycles, while the statistic reports themselves increase the network load. Preprocessing of statistics at the switch (e.g., aggregated reports) reduces the network overhead, but results in high CPU consumption.

III. TOWARDS PROGRAMMABLE NETWORK MONITORING

To address the scalability challenges for monitoring applications and the broader limitations of OpenFlow, several approaches have been proposed in the recent literature. This paper classifies these approaches according to the flexibility they offer for the implementation of dataplane algorithms.

We first focus on proposals for new control plane behaviors, as they preserve the stateless OpenFlow paradigm. We then discuss proposals to add a persistent state in the dataplane.

A. Control Plane-Based Monitoring

With the emergence of OpenFlow came proposals for software-defined network monitoring. The authors leverage the dynamicity and the global view over the network of OpenFlow to optimize resource utilization. They either consider a single switch and attempt to reduce its consumption of resources, or a coordinated set of switches to avoid local resource shortages.

1) Local Resource Optimization: Many applications are not interested in a fixed set of flows but rather in any flow with a specific characteristic. For example, to improve its efficiency, a traffic engineering application may monitor only elephant flows. Hence, to keep focus on relevant flows, dynamic adaptations of monitoring rules are required.

Jose et al. [START_REF] Jose | Online measurement of large traffic aggregates on commodity switches[END_REF] propose to dynamically adapt the granularity of flow rules. They implemented a use case to identify the IP addresses of heavy hitters in several iterations. At each iteration, their prototype divides rules for flows containing heavy hitters into more precise sub-rules, thus increasing the granularity of flow rules. However, their incremental detection of heavy hitters takes a minimum of 200 seconds to converge, rendering this strategy inefficient for short-lived flows.

In PayLess [START_REF] Chowdhury | Payless: A low cost network monitoring framework for software defined networks[END_REF], Chowdhury et al. propose a similar algorithm to adapt the reporting frequency, using a simple threshold-based algorithm. The algorithm increases the frequency if, over the last reporting period, the collected statistics changed more than a threshold ∆ 1 . Conversely, if the collected statistics changed less than a threshold ∆ 2 , the reporting frequency is decreased. Thus, PayLess monitors more closely highly variable flows. Chowdhury et al. demonstrate that the algorithm can halve the median reporting frequency while maintaining a high accuracy.

Y. Zhang proposes OpenWatch [START_REF] Zhang | An adaptive flow counting method for anomaly detection in sdn[END_REF], an adaptive algorithm for anomaly detection. OpenWatch can update both the granularity of flow rules and the reporting frequency using a prediction-based algorithm. The linear prediction model estimates future statistics based on previous values. If the next collected values lie within the predicted interval, OpenWatch decreases the granularity (respectively the reporting frequency); otherwise, it increases the granularity.

Consequently, the algorithm allocates more resources on flows with an irregular behavior.

Propositions for an adaptive definition of flow rules only alleviate the scalability challenges. Thus, depending on the desired accuracy and the number of flows to monitor, a large number of flow rules and a high reporting frequency might still be needed. Furthermore, since these approaches add a convergence delay, they require temporal stability of monitored flows and may miss transient network events.

2) Network-Wide Resource Optimization: While resources might be scarce locally, large-scale networks are likely to contain many switches and thus, enough resources globally. This rationale motivates several approaches to distribute monitoring resources across the dataplane.

With Palette [START_REF] Kanizo | Palette: Distributing tables in software-defined networks[END_REF], Kanizo et al. design a flexible approach to the distribution of resources in the dataplane. Palette aims at balancing flow table sizes while minimizing the total number of flow rules. Because it acts directly on flow tables, it does not depend on the application logic.

The distribution of flow rules raises two underlying problems: the decomposition of flow tables into elementary flow tables and the placement of these elementary flow tables along network paths. Each flow table is decomposed such that a flow going through the succession of elementary flow tables will result in the same measurements as if it had gone through the original flow table.

In DCM [START_REF] Yu | Distributed and collaborative traffic monitoring in software defined networks[END_REF], Yu et al. propose a greedy algorithm to distribute the monitoring load across switches. Contrary to Palette, DCM relies on a static exposition of state in switches, presented in section III-B. For this reason, DCM balances the memory usage across the dataplane, instead of the flow rules.

Similarly to local resource optimization approaches, proposals for network-wide optimization only alleviate the scalability challenges.

B. Monitoring Primitives in the Dataplane

The narrow measurement features of OpenFlow force switches to report large quantities of raw information to the controller. Hence, several proposed extensions for Open-Flow switches aim at processing measurements locally, before reporting the essential information to the controller. These approaches allocate a persistent state on switches to store intermediate measurements. These switch designs expose the persistent state through probabilistic data structures.

Probabilistic data structures, or sketches, are used by streaming algorithms to store summary information on the input data [START_REF] Estan | New directions in traffic measurement and accounting[END_REF]. Sketches rely on hash algorithms to classify and count packets in a limited number of operations. As they store only the information required for the measurement task, they need few memory resources. Furthermore, these probabilistic data structures present a provable trade-off between the consumed resources and the achieved accuracy.

Probabilistic data structures have been extensively used to overcome resource limitations in the context of softwaredefined networking [START_REF] Yu | Software defined traffic measurement with opensketch[END_REF], [START_REF] Yu | Distributed and collaborative traffic monitoring in software defined networks[END_REF], [START_REF] Liu | One Sketch to Rule Them All: Rethinking Network Flow Monitoring with UnivMon[END_REF]. Indeed, they offer a better trade-off between resources and accuracy than counters, yet require little processing power.

In addition to the control plane algorithm for the distribution of rules presented in section III-A2, DCM [START_REF] Yu | Distributed and collaborative traffic monitoring in software defined networks[END_REF] integrates a two-stage Bloom filter-based process for the definition of monitoring flow rules. The first Bloom filter, called the admission Bloom filter, selects flows to measure. Packets matching the admission Bloom filter are further processed in the second stage, which is composed of a Bloom filter, called action Bloom filter, per monitoring action. Packets are matched against each action Bloom filter to select the actions to apply. For example, one Bloom filter may lead to a Count-Min sketch, while another may forward packets to the controller, to implement sampling. This two-stage pipeline greatly decreases the overall number of false positives. Nevertheless, DCM is inadequate for some applications (e.g., stateful firewalls) for which even a small number of false positives is unacceptable.

Yu et al. design OpenSketch [START_REF] Yu | Software defined traffic measurement with opensketch[END_REF], a library and an API for traffic measurement, concurrent to OpenFlow. OpenSketch contains several probabilistic data structures, which measurement tasks can use as primitives. For example, a DDoS detection task would leverage Count-Min sketches, bitmaps and reversible sketches.

Complex measurement tasks, however, involve elaborate combinations of sketch primitives. Furthermore, each new measurement task requires custom algorithms and sketches. The absence of a sufficiently general solution hinders the development of sketches in production switches.

To solve this issue, in UnivMon [START_REF] Liu | One Sketch to Rule Them All: Rethinking Network Flow Monitoring with UnivMon[END_REF], Liu et al. investigate the application of recent theoretical advances in universal streaming algorithms to network monitoring. Universal streaming algorithms can serve as the single primitive for a large number of monitoring tasks. Liu et al. develop a prototype and implement several measurement tasks from OpenSketch with this single data structure.

The authors of sketch-based proposals focused their evaluations on the accuracy and space constraints (memory, TCAMs, and number of hash functions). Only the authors of OpenSketch implemented it on a NetFPGA and measured the throughput, limited by the 1GbE link. Therefore, there is little information on whether sketch-based monitoring would scale to large networks, if implemented in hardware.

C. Stateful Software Dataplane

Counting and sampling methods are not always sufficient for monitoring applications, in particular for security applications. Applications need to monitor or take actions based on information from all network layers. For example, a denial-ofservice detection system may track packets with a particular signature in their payloads to confirm an anomaly detected by flow counters.

These unique needs motivate Mekky et al. [START_REF] Mekky | Application-aware data plane processing in sdn[END_REF] and Sonchack et al. [START_REF] Sonchack | Enabling practical software-defined networking security applications with OFX[END_REF] Furthermore, the high flexibility of the local application approach comes with two barriers to deployment.

First, the processing of packets by local applications impede the controller's view of the dataplane. Even though the local applications are installed on switches by the controller, it remains unaware of any packet processing they perform. This is problematic for network verification applications as they rely on the omniscient control plane.

Second, neither Mekky et al. nor Sonchack et al. present solutions isolate resources for local applications from resources for the OpenFlow forwarding pipeline. Hence, the controller cannot guarantee that a local application will not have a negative impact on packet forwarding. In particular, since the OpenFlow management agent and the local application compete for CPU resources, it may impact the switch ability to report statistics or forward packets to the remote controller.

D. Stateful Hardware Dataplane

Several recent efforts have focused on designing programmable dataplane hardware devices on ASIC for high performance networks. Most of these programmable dataplane designs expose persistent memory on switches, but differ in how it can be accessed and updated.

OpenState [START_REF] Bianchi | Openstate: Programming platform-independent stateful openflow applications inside the switch[END_REF] models switches as finite state machines, where each packet corresponds to a transition. Therefore, it exposes the persistent switch memory through a finite number of states only. Because this abstraction appeared insufficient to implement many networking algorithms, FAST [START_REF] Moshref | Flowlevel state transition as a new switch primitive for SDN[END_REF] and OPP [START_REF] Bianchi | Open Packet Processor: a programmable architecture for wire speed platform-independent stateful in-network processing[END_REF] propose to associate a set of registers to the finite state machines. While FAST received a software evaluation only, the authors of OPP implemented their prototype on FPGAs. Even though they propose a departure from the match-action abstraction, they discuss how OPP can be mapped into matchaction tables to leverage TCAMs and current ASIC hardware. Yet, they do not evaluate the potential increase in size of match-action tables to store all state machine transitions.

Recently, Bosshart et al. and Sivaraman et al. proposed to extend the match-action abstraction with stateful actions in P4 [START_REF]The P4 Language Consortium[END_REF] and Domino [START_REF] Sivaraman | Packet Transactions: High-Level Programming for Line-Rate Switches[END_REF] respectively. They expose the switch persistent memory as arrays, with a few restrictions on accesses to sustain line-rate hardware implementations. For example, they prohibit variable-sized loops, thus preventing the implementation of dynamic data structures, such as hash tables, linked lists, or priority queues. Furthermore, to allow for efficient pipelining, P4 and Domino also restrict the number of memory accesses to one per array and per table, forcing developers to use several arrays to implement a Bloom filter for example.

Recent proposals leverage the new stateful dataplane designs for network monitoring. Using P4, Ghasemi et al. implement Dapper [START_REF] Ghasemi | Dapper: Data Plane Performance Diagnosis of TCP[END_REF], a TCP performance analysis system. Dapper inspects TCP sessions in real time near end-hosts and determines the origin of performance drops between the sender, the receiver, and the network itself. Dapper stores TCP sessions in a hash table, but, due to P4's lack of variable-sized loops, collisions are not resolved. The authors evaluate how larger hash tables can help reduce the probability of collisions.

Sivaraman et al. design HashPipe [START_REF] Sivaraman | Smoking Out the Heavy-Hitter Flows with HashPipe[END_REF], a heavy hitter detection algorithm for programmable switches. They adapt a deterministic heavy hitter detection algorithm, which uses a hash table to store flow counts, for an implementation on P4. To avoid variable-sized lookups, they examine only a small, constant number of random items in the hash table. For this reason, HashPipe admits false positives, whose rate depends on the number of items examined and the size of the hash table.

The restrictions of current programmable hardware devices, in particular the lack of variable-sized loops, force developers to implement their own sketches. Although these language constraints stem from their line-rate hardware targets, they induce complex implementations, with higher memory consumption, reduced accuracy, and limited processing rates due to the use of additional tables.

IV. IMPACT ON THE CONTROL PLANE VISIBILITY

One of the strength of the initial OpenFlow proposal is the controller's global visibility over the network. In particular, given the headers of a packet, the controller knows the path the packet will take through the dataplane and the actions it will be submitted to. This knowledge is leveraged by network verification applications [START_REF] Khurshid | Veriflow: Verifying Network-Wide Invariants in Real Time[END_REF], for example, to check invariants in the configuration of the dataplane (absence of loops, enforcement of ACL rules, etc.). With new stateful switches, however, any action dependent on dataplane state would be invisible to the controller. In this section, we discuss the impact of stateful dataplane designs on the controller's visibility over the network.

Table I presents the proposals previously discussed with the state properties induced for the dataplane and the impact on the controller's visibility. Column Controller's visibility refers to the minimum information the controller has on a packet, regardless of the dataplane algorithm. Within the Dataplane state column, Stateful processing refers to the capacity of the dataplane state to influence the actions taken on a packet, whereas, with stateful monitoring proposals, the dataplane state is used for preprocessing of measurements only. Therefore, contrary to stateful monitoring, stateful processing enables switches to act on a packet differently depending on past packets. Because they preserve the OpenFlow abstractions, all proposals for new control plane behaviors retain the controller's omniscience. Conversely, proposals that enable stateful processing in the dataplane limit the controller's visibility over the network.

In particular, with P4, Domino, and local applications, dataplane algorithms may be defined such that the controller has no knowledge on the actions applied on a packet at runtime. For example, a P4 action may read the egress port from an array in the persistent memory. Since the controller has no visibility over the switch memory, it cannot know on which port the packet is sent out either.

Interestingly, not all proposals for stateful processing in the dataplane result in the same reduction of the controller's visibility. Whatever the state machines installed in the dataplane, with OPP, OpenState, and FAST, the controller can always determine the finite set of possible actions applied on a packet. The difference with other stateful processing designs resides in the inability to define stateful actions. With state machine-based approaches, actions depend on state machine transitions, but are chosen from a static set of predefined actions. Conversely, with P4 and Domino, actions can be defined at runtime, from the dataplane state.

Finally, sketch-based proposals for dataplane design retain the full controller's visibility. Indeed, because they advocate the use of a second stateful pipeline dedicated to monitoring, they preserve the initial stateless packet processing pipeline of OpenFlow. The absence of negative impact on the controller's visibility is thus a direct consequence of the use of the dataplane state for preprocessing of measurements only.

V. DISCUSSION & OPPORTUNITIES

P4 has recently gained momentum with the emergence of the first programmable P4 switch on the market [START_REF] Networks | Barefoot Tofino[END_REF]. Support for P4 is also expected in NICs and software switches. As Dapper [START_REF] Ghasemi | Dapper: Data Plane Performance Diagnosis of TCP[END_REF] and HashPipe [START_REF] Sivaraman | Smoking Out the Heavy-Hitter Flows with HashPipe[END_REF] demonstrate, the presence of stateful programmable devices in networks would enable the development of new monitoring applications for use in largescale networks.

The widespread deployment of P4 network devices, however, will largely depend on the availability of middle-end devices. Furthermore, we do not know yet to what extent such devices will follow the P4 specifications. For example, the lack of persistent general-purpose memories would make P4 less attractive to monitoring applications.

Moving forward, we identify three open research issues and opportunities for improvement in the design of dataplane devices.

First, the impact of stateful dataplane designs on network visibility has been overlooked by the research community thus far. New programmable switches could benefit from discussion on what an acceptable loss of visibility would be. Furthermore, network verification applications will require new methods and tools to overcome the loss of visibility and analyze the impact of dataplane states.

Second, we argue that their is still room for improvement in the design of stateful software switches. The first languages for programmable devices were designed for hardware switches [START_REF]The P4 Language Consortium[END_REF], [START_REF] Sivaraman | Packet Transactions: High-Level Programming for Line-Rate Switches[END_REF]. For this reason, they retain hardware specific limitations (discussed in section III-D). However, because software switches run on CPUs, restrictions on the access to persistent memories are unnecessary.

Furthermore, because software switches typically aim for lower performance than ASIC switches, accessing dynamic data structures at line-rate is feasible. Thus, software switches could expose their persistent memory through hash table structures, for example, instead of static data structures, such as arrays in P4. This new abstraction for the dataplane state would enable new use cases. For example, the implementation of a stateful firewall without relying on a controller requires a dynamic data structure. Indeed, because a stateful firewall needs to keep information on a variable number of established connections in memory, it cannot rely on a fixed size array. Moreover, as is the case for many security applications, probabilistic data structures are ill-suited because even a small number of false positives is unacceptable (allows illegitimate connections through).

Third, current specifications for programmable devices detail how processing pipelines can be defined, but not how they can be updated. The P4 specification [START_REF]The P4 Language Consortium[END_REF], for example, gives no indication on how to update the configuration of the device once it is running. This information is particularly important for network monitoring. The ability to load stateful algorithms in the switch at runtime, without interruption of packet processing, would enable the execution of monitoring algorithms for short periods of time. Network operators could use it for debugging or to gather additional information on network events of interest. This feature is easier to implement in software switches, as the switch must maintain two concurrent processing pipelines for a short time to avoid an interruption of packet processing.

VI. CONCLUSION

In this paper, we present recent work on network monitoring in software-defined networking. Network monitoring long called for the exposition of a dataplane state. The recent emergence of stateful programmable network devices may represent a fundamental shift for the design of monitoring applications. If these new devices live up to expectations, they will enable the development of new, unpredictable applications and their deployment in large-scale networks.

We discussed the impact of stateful dataplane designs on the control plane visibility over the network. Leveraging our analysis of requirements for monitoring applications, we identified three opportunities for improvement in the design of stateful network devices. In particular, for software switches, there is an opportunity to design a stateful programmable abstraction better suited to their commodity hardware environment.

  to design OpenFlow extensions to run applications locally, in switches. Both approaches allow control plane applications to execute any custom program in switches. To this end, Mekky et al. add a rule in flow tables to redirect unmatched packets to a separate table. The local application processes these packets and may forward them or alter flow tables as a result. Sonchack et al. adopt an alternate approach with OFX [7]: local applications control the first table in the OpenFlow pipeline and thus, they may intercept any packet independently of subsequent flow rules. As such, OFX keeps a strict separation between the flow table controlled locally and flow tables controlled by remote applications. In essence, Mekky et al. and Sonchack et al. propose a local controller that can host applications in switches. Because such applications can only run on commodity hardware, this approach is limited to software and white-box switches and is inadequate for high throughput execution on ASIC.

TABLE I :

 I Comparison of impact on dataplane state and controller's visibility of each proposal

ACKNOWLEDGMENTS

We would like to thank Sylvie Laniepce for her helpful comments on drafts of this paper.