SDNManager: A Safeguard Architecture for SDN DoS Attacks...

Research ArticleSDNManager A Safeguard Architecture for SDN DoS AttacksBased on Bandwidth Prediction

Tao Wang Hongchang Chen Guozhen Cheng and Yulin Lu

National Digital Switching System Engineering and Technological Research Center Zhengzhou 450002 China

Correspondence should be addressed to Tao Wang wangtaogenuine163com

Received 28 September 2017 Revised 24 November 2017 Accepted 11 December 2017 Published 15 January 2018

Academic Editor Qiang Fu

Copyright copy 2018 TaoWang et alThis is an open access article distributed under theCreative CommonsAttribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Software-Defined Networking (SDN) has quickly emerged as a promising technology for future networks and gained muchattention However the centralized nature of SDN makes the system vulnerable to denial-of-services (DoS) attacks especiallyfor the currently widely deployed multicontroller system Due to DoS attacks SDN multicontroller model may additionally facethe risk of the cascading failures of controllers In this paper we propose SDNManager a lightweight and fast denial-of-servicedetection and mitigation system for SDN It has five components monitor forecast engine checker updater and storage service Ittypically follows a control loop of reading flow statistics forecasting flow bandwidth changes based on the statistics and accordinglyupdating the network It is worth noting that the forecast engine employs a novel dynamic time-series (DTS) model which greatlyimproves bandwidth prediction accuracyWhat ismore to further optimize the defense effect we also propose a controller dynamicscheduling strategy to ensure the global network state optimization and improve the defense efficiency We evaluate SDNManagerthrough a prototype implementation tested in a real SDN network environment The results show that SDNManager is effectivewith adding only a minor overhead into the entire SDNOpenFlow infrastructure

1 Introduction

Software-DefinedNetworking (SDN) [1] has quickly emergedas a new paradigm that decouples the control logic fromdata plane devices It offloads the complex network controlfunctions to the logically centralized controllers while thedata plane tends to be a set of dumb forwarding devicesControllers as the main component of SDN are responsiblefor maintaining network-wide state views and performingforwarding decisions to support fine-grained network man-agement policies Therefore the separation of control planeand data plane enables a flexible network management andrapid deployment of new functionalities However securityof controller is the precondition and the basis of SDN

OpenFlow as a reference implementation of SDN hasbeenwidely used in recent years InOpenFlow when a switchreceives a new flow and there are no matching flow rulesinstalled in its flow table the data plane will typically bufferthe packet in the first place and then request a new flowrule from the controller with an OFPT PACKET INmessageHowever it is obvious to see that the centralized controller

introduces considerable overhead and could easily becomea bottleneck As illustrated in Figure 1 two kinds of DoSattacks [2] are generally considered in SDN networks In thefirst attack attackers may simply mount saturation attackstowards an SDN controller by sending massive useless pack-ets Then the controller has to handle every useless new flowfor flow entry creation which greatly occupies computingresource and makes controllers show poor responsiveness toother legitimate flow requests In the second attack due to thelimited storage capacity the switch can only store a certainamount of flow entries So if the attacker aims to saturate thememory the switch cannot insert the new flow entry intoswitch flow table and will respond with an error message tothe controller simply dropping the packets at the end

Existed control plane is typically equipped with onecontroller which makes SDNmore vulnerable to DoS attackFor example if the only controller is overwhelmed orcompromised by attacks the entire network system willbe paralyzed subsequently Thus to improve scalability andalleviate single point failure the latest control plane is usuallyimplemented as a distributed network operating system with

HindawiSecurity and Communication NetworksVolume 2018 Article ID 7545079 16 pageshttpsdoiorg10115520187545079

2 Security and Communication Networks

PACKET INAttack1 Exhaust control

plane bandwidthAttack2 Overload

the buffer

Controller

Step 1 DestID Source

SecurityChannel

Flow table scheduler

Control path

PacketAbstract API

API

SDN switch

Step 2

Data pathFlow table

Flow table

Flow table

update

Hardware driverPacket processing table

Packet forwardingPort

Attacker

Normal userNormaltraffic

Attacktraffic

Step 5

Flow ModStep 4Step 3

Server

middot middot middot


Figure 1 SDN architecture and denial-of-service attacks

multiple controllers (ONOS) Wang et al [3] dynamicallyassign controllers to minimize the average response timeand balance load ElDefrawy and Kaczmarek [4] introducea prototype SDN controller that can tolerate Byzantine faultsNote that currentmultiple-controller architectures aremostlydesigned from the aspects of scalability and efficiency insteadof typical security so a more comprehensive architecturewhich emphasizes on the aspect of security urgently needsto be solved What is more in the multiple-controller modelif one controller fails after a successful DoS attack othercontrollers will take over it and the additional loadmaymakethem overloaded causing the cascading failure [5] ultimatelyAs illustrated in Figure 2 (Stage 1) when controller 119888 failsthe load of controller 119888 (switches 7 8 and 9) is redistributedto controller 119886 and 119889 whose loads are then exceeding theircapacities In Stage 2 when controllers 119886 and 119889 fail the loadof controller 119886 (switches 1 2 3 4 5 6 and 7) is redistributedto controller 119887 and the load of controller 119889 (Switches 8 915 16 17 and 18) is also redistributed to controller b too InStage 3 controller b takes all the load to manage the networkIn Stage 4 controller 119889 fails at last and all the switchesare out of control As a result the whole SDN networkbecomes paralyzed and triggered by the failure of onlyone controller which accelerates the paralysis of the wholemodel

To address the above problems we devised SDNManagera fast and lightweight denial-of-service detection and miti-gation system for SDN which can significantly increase theresistance of SDN networks to both single point of failureand cascading failure caused by DoS attack Specifically ourcontributions are as follows

(i) SDNManager employs a novel dynamic time-series(DTS) model which greatly improves bandwidth pre-diction accuracy so it can provide higher detectionaccuracy and ensure better protection to the wholenetworks

(ii) SDNManager is implemented on the control planewhich conforms to the SDN security trend and does

not require anymodification on the data planeThere-fore it is easier to deploy SDNManager compared tothe previous solutions

(iii) SDNManager is valid for all types of DoS attacks(iv) SDNManager adds minor overhead into the entire

SDNOpenFlow infrastructure(v) To further optimize the defense effect we also pro-

pose a controller dynamic scheduling strategy toensure the global network state optimization andimprove the defense efficiency

The rest of the paper is organized as follows Section 2introduces some related works The design of SDNManageris detailed in Section 3 Section 4 presents the dynamiccontroller scheduling strategyThe experiments and results ofthe SDNManager and dynamic controller scheduling strategyevaluation are presented in Sections 5 and 6 respectivelySection 8 introduces our future works Section 8 concludesthe paper

2 Related Work

Some recent research [6ndash8] also pointed out that the SDNcontroller is a vulnerable target of DDoS attacks Yan and Yu[9] argue that although SDN controller itself is a vulnerabletarget of DDoS attacks it also brings us an unexpectedopportunity to mitigate DDoS attacks in cloud computingenvironments Several solutions have been proposed to mit-igate the SDN DoS attacks For example Kotani and Okabe[10] proposed a packet-in message filtering mechanism forprotection of the SDN control plane The packet-in filteringmechanism can first record the values of packet header fieldsbefore sending packet-in messages and then filter out packetsthat have the same values as the recorded ones Of course ifthe DoS attacker deliberately sends new packets that have dif-ferent values from the recorded ones the packet-in filteringmechanism will be completely ineffective Mousavi and St-Hilaire [11] introduced an early detection method for DDoSattacks against the SDN controller based on the entropy

Security and Communication Networks 3

L = 08C L = 08C

L = 08C

L = 08C

L = 12C

L = 36C

L = 14C

L = 14C

Stage 1 Stage 2

Stage 3 Stage 4

Controller

Exceed controller capacitySwitch

a b

c d

a b

cd

a b

c d

a b

cd

1

2

34

5

6

7 8

9

10 11

12

1314

15

1617

18

1

2

34

5

6

78

9

10 11

12

1314

1516

17

18

1

2

3 4

5

6

7

8

9

1516 17

18

10 11

12

1314

1

2

3 45

6

7

8

9

1516 17

18

10 11

12

1314

C capacity

L load

Figure 2 The cascading failures of controllers

variation of destination IP address He thinks that the desti-nation IP addresses of normal flows should be almost evenlydistributed while the destination IP addresses of maliciousflows are always destined for several targets However it isalso not difficult for DoS attackers to generate a large amountof new traffic flows the destination IP addresses of which areevenly distributed to overload the SDN controller Avant-Guard [2] introduces connection migration and actuatingtriggers into the SDN architecture to defend against the SYNFlood attacks but it does not workwell when confrontedwithother DoS attacks in SDN FloodGuard [12] uses proactiveflow rule analyzer and packet migration to defend againstdata plane saturation attack but it is too costly Previouslyrelated works such as [13 14] employed Self OrganizingMaps (SOM) to classify whether the traffic is abnormal or notto defend against DoS attacks but the overhead of the classi-fication is also too high to be used in real time Yan et al [15]proposed a solution to detect DDoS attacks based on fuzzysynthetic evaluation decision-making model Although it isa lightweight detection method its detection accuracy is notvery well Wang et al [16] formulate the dynamic controllerassignment problem as an online optimization problem

aiming atminimizing the total costThey also propose a noveltwo-phase algorithm by casting the assignment problem asa stable matching problem with transfers Simulations showthat the online approach reduces total cost and achieves betterload balancing among controllers However the algorithm ismostly devised from the perspective of scalability efficiencyand availability instead of security

Wei et al [17] employ theARIMAmodel and theGARCHmodel to forecast the trend and volatility of the futuredemand Amin et al [18] propose a forecasting approachthat integrates ARIMA and GARCH models to capture theQoS attributesrsquo volatility Krithikaivasan et al [19] develop aforecasting methodology based on an ARCH model whichcaptures the time variation in the (conditional) varianceof a time-series However the above models have shownthat the statistical distribution of the innovations (errors)often has a departure from normality which is typical of thevolatility found in bursty traffic Furthermore the past linearcombinations of squared error terms have been found to leadto inaccurate forecasts Therefore we employ the adaptiveconditional score of the distribution to track volatility in DTSmodel


By analyzing the existing works it is not difficult to findthat a more systematic approach needs to be designed to dealwith the attacks mentioned above Next we will show ourdesign

3 Design of SDNManager

In the currentOpenFlow reactivemode network suffers fromDoS attacks due to a lack of flow-level bandwidth control Inother words attackers can send useless packets without lim-its and then controller must perform forwarding decisionsand generate flow rules unconditionally until the controller issaturated Furthermore current SDN designs widely utilizedmultiple controllers Besides exploiting heterogeneity anddynamism to improve the security level of NOS in some otheraspects it also increases vulnerability in the single point offailure and easily causes the cascading failures of controllerswhich makes the whole network be paralyzed more quicklyThus it is undoubted that the influence is significant oncecontrollers are flooded

In this paper we introduce SDNManager a fast andlightweight denial-of-service detection and mitigation sys-tem that allows multiple controllers to operate indepen-dently to mitigate denial-of-service attack on the controllerSDNManager typically follows a control loop of readingflow statistics forecasting flow bandwidth changes based onthe statistics and accordingly updating the network Flowswith bandwidth usage higher than the predicted bandwidthusage are penalized by the application The penalization isproportional to the difference between current usage andpredicted usage Therefore the service will not be disruptedand the cascading failures can be effectively avoided eventhough some controllers are under DoS attacks Figure 3shows the architecture of SDNManager The details of SDN-Manager are described in the rest of this subsection Nota-tions of SDNManager lists most of the notations used in thepaper

31 System Architecture As Figure 3 shows SDNManagermainly has five components monitor forecast enginechecker updater and storage service We outline the role ofeach component by discussing three kinds of operating statesof SDNManager

In observed state (OS) monitor periodically collects anup-to-date view of the actual network states including flowrules statistics and path conditions from switches andtransforms them into OS variables Then the forecast enginereads these variables and forecasts the expected bandwidthutilization for each flow based on its historical data traceUsing a bandwidth checker module SDNManager mergesthese proposed states (PS the expected bandwidth utilization)into a target state (TS) that is guaranteed to maintain thesafety and performance of the system Updater module thenupdates the network to the target state What is more storageservice as the center of the system persistently stores thevariables of OS PS and TS and offers a highly availableread-write interface for other components which greatlysimplifies the design of the other components and allows

OpenFlowcollector

Translateto OS

Proxy

OS | PS | TSR W

Monitor

Write OS

Forecast engine

Read OSWrite PS

CheckerDiff

OS-PSReadOS PS

GenerateTS

Write TS

Execute command

Device-specificcommand pool

Read TS

Updater

Storage service

SDNManager

Control plane

Data plane

middot middot middotmiddot middot middot

Figure 3 The architecture of SDNManager

them to be stateless Of course what counts above all is thatSDNManager is supposed to forecast bandwidth utilizationaccurately Thus we employ a dynamic time-series model todevelop a novel bandwidth utilization forecast engine Nextwe introduce the forecast engine in detail

32 Forecast Engine AnARCH (autoregressive conditionallyheteroscedastic) model is a model for the variance of atime-series ARCH models are used to describe a changingpossibly volatile variance Current research in forecastingvolatility adopted methods developed originally from theARCH model in Econometrics Although an ARCH modelcould be used to describe a gradually increasing varianceover time most often it is used in situations in which theremay be short periods of increased variation Also it has beenobserved that the statistical distribution of the innovations(errors) often has a departure from normality which is typicalof the volatility found in bursty traffic Furthermore the pastlinear combinations of squared error terms have been foundto lead to inaccurate forecastsTherefore ARCHmodel is notour best choice and we need to optimize it Inspired by theARCH model [22] we adopt a dynamic time-series model(DTS) to forecast bandwidth volatility More specifically weemploy the adaptive conditional score of the distribution totrack volatility in DTS model Of course before describingthe DTS model in detail we first briefly introduce the ARCHmodel The ARCH model illustrates the variance of a time-series as a function of the squares of its past observationsThe major contribution of the ARCH model is to find thatapparent changes in the volatility of bandwidth time-seriesmay be predictable An ARCH process indexed on time 119905 asa random variable 119884119905 of order (119898 gt 1) can be expressed as


(1) In each time slot 119905(2) For each controller 119862119894 isin 119862(3) Query flow statistics and Path conditions(4) OS119862119894 larr Transform(state variables)(5) for each flow flow119894119895 isin flow119862119894(6) PS119862119894 larr BWflow119894119895 fcst = ForecastingEngine(OS119862119894 )(7) If BWflowij

BWflowij fcst gt 1 + 120585(8) TS119862119894 larr997888 BWflow119894119895 target = BWflow119894119895 lowast pun( 1

119890BWflow119894119895minusBWflow119894119895 fcst)

(9) else(10) TS119862119894 larr BWflow119894119895 target = BWflow119894119895(11) end if(12) end for(13) End For(14) Enforce Load redistribution strategy(15) Return

Algorithm 1 The main procedure of SDNManager

a product of innovations (errors) of the past 119898 terms and itsstandard deviation by

119884119905 = 1205901199051205761199051205902119905 = 120596 + 119898sum

119894=1

1198861198941198842119905minus119894 +119898sum119895=1

1198871198951205902119905minus119895 (1)

Here 120596 119886119894 119887119895 gt 0 are constants obtained through theprocess of model fitting However considering the aboveequations we can observe that the statistical distributionof the ARCH model always has the departure from nor-mality which is typical of the volatility existed in highlydynamic SDN traffic Furthermore past linear combinationsof squared error terms can inevitably bring about inaccurateforecasts Thus we employ the conditional score of thedistribution to track volatility to solve these problems

We also define a random variable BW119905 as the throughputof the time-series elicited from analyzed traces whose 119905thobservation is the dependent variable of interest with a time-varying parameter119891119905 which will be determined by estimating120579119905 the parameter of the conditional distribution of BW119905

BW119905 sim 119901 (BW119905 | 119891119905 120579119905) (2)Here we employ Maximum Likelihood Estimation (MLE)where the parameter 120579119905 is determined by the population thatmost likely produced the data vector BW119905 The followingequation is a recursion expression for 119891119905

119891119905 = 120596 + 119899sum119894=1

120572119894119891119905minus1 +119898sum119895=1

120573119895119904119905minus1 (3)

Here 120596 is a constant and 120572119894 120573119895 are coefficient matricesobtained through the process of model fitting and dimen-sioned for 119894 119895 = 1 119899 1 119898 respectively When anobservation density is realized for BW119905 the time-varyingparameter 119891119905 is updated by the conditional score 119904119905

119904119905 = 119904119905nabla119905 (4)

where nabla119905 = 120597 log119901(BW119905 | 119891119905 120579119905)120597119891119905 is the first derivative ofthe log-likelihood function of the conditional distributionrsquosparameter Inserting back into (3) yields

119891119905+1 = 120596 + 120572119891119905 + 120573119904119905 [120597 log119901 (BW119905 | 119891119905 120579119905)120597119891119905 ] (5)

The variance will be the second derivative in keeping witha measure of volatility The second moment is given by thefollowing equation

119868119905 = minus119864[1205972 log119901 (BW119905 | 119891119905 120579119905)1205972119891119905 ] = 119864 [nabla119905nabla1015840119905 ] (6)

Here 119868119905 is the Fisher information matrix for all terms to beused in computing the volatility and nabla119905 is the score vectorTherefore the model takes historical data trace as an inputand makes full use of the adaptive conditional score to yieldthe predicted flow-level bandwidth utilization BW119905 The DTSmodel makes full use of the observational density of thedependent variable in updating the conditional score ratherthan a linear combination of a finite number of past varianceterms In addition it also employs the derivative as a betterfilter with the conditional density and is therefore less pronewhen outliers are present in historical data

33 Dynamic Bandwidth Allocation Algorithm After com-pleting the design of the forecast engine we can then developan integrated dynamic bandwidth allocation algorithm forthis issueThe pseudocode of the dynamic bandwidth alloca-tion algorithm is shown inAlgorithm 1Thepractical solutionuses explicit bandwidth information of each flow to enforceaccurate rate control for traffic flows between controllers andswitches The solution takes full advantage of the ability ofglobal monitoring in SDNThe explicit steps of the algorithmare as follows

First the monitor periodically collects the current flowstatistics and path conditions and transforms them into OS


variables (lines (3)-(4)) Second the forecast engine readsthe latest OS variables from the storage service and proposesthe expected bandwidth utilization for each flow (line (6))Then bandwidth checker examines whether the observedbandwidth utilization for each flow is consistent with theexpected bandwidth utilization (line (7)) We set the slackvariable 120585 [23] mainly to reduce the impact of SDNManageron normal flow Flows with bandwidth consumption higherthan the predicted bandwidth consumption will be penalizedby the application (bandwidth checker) The penalization isproportional to the difference between current and predictedusage (lines (8)ndash(10)) Finally each controller repeats theabove steps and takes load redistribution strategy to preventcascading failures (line (14)) In addition there is a problemworthy of attention once the predicted bandwidth is notaccurate and the flow is penalized for that mistake then theuser of the flow can be hurt which is not fair Consideringthe predicted bandwidth is not absolutely accurate we set theslack variable 120585 isin [0 1] in Algorithm 1 mainly to reducethe impact of SDNManager on normal flow Of course itis necessary to ensure both the ldquofairnessrdquo and ldquosecurityrdquoof SDNMManager Here ldquofairnessrdquo means that even if thepredicted bandwidth is not absolutely accurate SDNManagershould guarantee the normal flowwill not be penalized for themistake ldquoSecurityrdquo of the process means that SDNManagershould prevent possible DoS attacks Therefore we canbalance the fairness and security by adjusting the value of theslack variable based on our actual requirements For exampleif we pay more attention to ldquofairnessrdquo the value of 120585 could beset to big enough On the contrary if we pay more attentionto ldquosecurityrdquo the value of 120585 could be set to small enoughCompared with the previous rate limiting algorithm [24]our method is more moderate The previous rate limitingalgorithm is not fair because it penalizes all routers equallyirrespective of whether they are greedy or well behaving

4 Dynamic ControllerScheduling Strategy (DCS)

With SDN technology widely used in the cloud data center[25] the industry uses SDN multicontroller model [26 27]to achieve high performance and high scalability Howeverthe SDN multicontroller model is more vulnerable to theDoS attacks on the controllerTherefore SDNmulticontrollermodel does need the associated SDN DoS defense mech-anism to enhance its availability The defense mechanismdesigned in this paper is adaptive for the SDNmulticontrollermodel It can effectively prevent the DoS attack against thecontroller and avoid the single failure point of the controller[28] Of course the defense mechanism also inevitablyincreases the controller load Also given the random natureofDoS attacks (random time randomaddress randomattackrate and random controller) it can result in unbalancedload across multiple controllers affect the average responsetime of the global network and reduce the overall qualityof service Therefore to further optimize the defense effectwe propose a controller dynamic scheduling strategy toensure the global network state optimization and improve thedefense efficiency

41 Dynamic Controller Scheduling Model Establishment Weassume that the SDN network consists of M controllersand N switches The controller set and the switch set arerepresented by 119862 = 1198881 1198882 119888119898 and 119878 = 1199041 1199042 119904119899respectively 119888119898 and 119904119899 represent the 119898th controller andthe 119899th switch respectively 119910(119905)119894119895 indicates whether the 119894thswitch is connected to the 119895th controller (1 indicates that theconnection is established 0 indicates that the connection isnot established) 119889119894119895 is the distance between the 119894th switch andthe 119895th controller (hops) The processing capability of eachcontroller in the controller set 119862 is 120583 = 1205831 1205832 120583119898 Inorder to increase the controller reliability and elasticity weset the decay factor of each controller as 120574 = 1205741 1205742 120574119898where 120574 isin (0 1)411 Average Global Controller Response Time Switch re-quests are aggregated at the processing queue of the con-nected controllers Therefore if the 119894th switch sends requeststo the controller at the rate 120592(119905)119894 in time slot 119905 the load ofcontroller 119895 can be expressed as

120579 (119905)119895 =119873sum119894=1

120592 (119905)119894 119910 (119905)119894119895 (7)

where 119910(119905)119894119895 indicates whether the 119894th switch is connected tothe 119895th controller (1 indicates that the connection is estab-lished 0 indicates that the connection is not established)According to the (7) and taking into account the effect of thenetwork topology size on the average response time of thecontroller we use (8) to compute the average request responsetime for controller 119895

120599 (119905)119895 = 1120583119895 minus 120579 (119905)119895119874(1198812) (8)

where 119881 is the scale of network topology (ie the number ofnetwork nodes)

The average controller response time in time slot t canbe represented as the weighted average of 120599(119905)119895 There-fore according to (7) and (8) the average global controllerresponse time is

120585 (119905) = sum119872119895=1 120579 (119905)119895 120599 (119905)119895sum119872119895=1 120579 (119905)119895 (9)

412 Dynamic Controller Scheduling Strategy Given theSDNmulticontroller model the dynamic controller schedul-ing strategy can dynamically assign controllers to switchesaccording to the change of the controller load By adjustingthe mappings between controllers and switches we canreduce the average response time of the global controllerand optimize the global quality of service The model can beabstracted as follows

Minimize 120585 (119905) (10)

st 120579 (119905)119895 le 120574119895120583119895 forall119895 (11)


Input forall119894 120592(119905)119894 forall119895 120583119895 120574119895Output 119910(119905)119894119895 forall119894 119895(1) function BSM (120592(119905)119894 120583119895 120574119895)(2) Each switch and controller builds Γ(119904119894) and Γ(119888119895)(3) while Any proposals from the switches do(4) if All the proposals will not vilolate constraint (11) then(5) The controllers accept all the proposals(6) else(7) The controllers only accept the most preferred proposals based on Γ(119904119894)(8) The controllers reject other proposals(9) end if(10) end while(11) Transform matching Θ to 119910(119905)119894119895 forall119894 119895(12) end function

Algorithm 2 Bidirectional selection mechanism

119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)

Formula (10) ensures the average response time of theglobal controller is optimal Constraint (11) ensures that nocontroller is overloaded Constraint (12) ensures that eachswitch must be connected to only one controller so as toensure validity and uniqueness

42 Solution for Dynamic Controller Scheduling ModelBecause the controller dynamic scheduling strategy is ori-ented to the SDN multicontroller model its solution needsto satisfy the high efficiency and the rapid convergence ofthe dynamic environment Through solving the model wecan get the global optimal controller-to-switch mappingTheoptimal mapping will balance the load across the multipleSDN controllers and optimize the defense effects of themechanism

In order to solve the optimal dynamic controller schedul-ing model we first make the controller and the switchperform ldquobidirectional selectionrdquo to construct the initialcontroller-to-switch mapping and then use the iterativealgorithm to adjust the mappings to achieve global networkperformance optimization Next we will describe the solu-tion for dynamic controller scheduling model in detail in thefollowing subsections

421 ldquoBidirectional Selectionrdquo Mechanism In this paper theldquobidirectional selectionrdquo mechanism is used to constructthe initial controller-to-switch mapping More specificallyall controllers and switches maintain their preferences listbased on some metrics In the case of satisfying the globalconstraints we construct the initial mapping according to thepreference lists [29]

From the perspective of the switch it may choose thecontroller with higher processing power and shorter responsetime (such as formula (8)) in the first place However thisindicator is related to many other factors so it is not easyto make a choice Therefore we use the maximum controllerresponse time as the indicator to construct a preference list of

each switchThemaximum response time of the 119895th controlleris represented as follows

120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)

From the above formula we can see that controllers inthe 119894th switchrsquos preference list Γ(119904119894) are arranged in ascendingorder based on their own maximum response time Switch iprefers the controller whose index is smaller in the preferencelist The smaller the index of the controller in the preferencelist is the shorter the maximum response time of thecontroller is The preference list of the 119894th switch is shown in

Γ (119904119894) = 119888119895lowast forall119895 = 119895lowast120599 (119905)max119895lowast lt 120599 (119905)max

119895 (15)

From the perspective of the controller controller 119895 mayfirst choose the switch with smaller request rate and smallerdistance between the switch and the controller 119895 All switchesin the 119895th controllerrsquos preference list are arranged in ascendingorder based on the product of the request rate and thedistance between the switch and the controller Controller 119895prefers the switch whose index is smaller in the preference listΓ(119888119895)The smaller the index of the switch in the preference listis the higher the probability of this switch being selected bythe controller 119895 is The preference list of the 119895th controller isshown in (16)

Γ (119888119895) = 119904119894lowast forall119894 = 119894lowast120592 (119905)119894lowast lowast 119889119894lowast119895 lt 120592 (119905)119894 lowast 119889119894119895

(16)

Of course in the above case if the controller 119895 wants toplace the 119894lowast switch into the initial mapping the controller 119895needs to satisfy the constraint that the controller load can notexceed its maximum threshold after placing the 119894lowast switch intothe mapping

120579 (119905)119895 + 120592 (119905)119894lowast le 120574119895120583119895 forall119904119894lowast (17)

The pseudocode of ldquobidirectional selectionrdquo mechanismis shown in Algorithm 2 Specifically after each side builds


Input Initial matching Θ forall119895 120583119895 120574119895Output 119910(119905)119894119895 forall119894 119895(1) function Transfer(Θ 120583119895 120574119895)(2) for All controllers forall119895 119888119895 do(3) for Each switch s119894 isin Θ(119888119895) do(4) for controller c119898 isin 119862119888119895 do(5) Find the transfer pair (119904119894 119888119895 119888119898) with minimum TR(119904119894 119888119895 119888119898)(6) endfor(7) if TR(119904119894 119888119895 119888119898) lt 0 then(8) Update Θ larr transfer(119904119894 119888119895 119888119898)(9) end if(10) end for(11) end for(12) Transform Θ to 119910(119905)119894119895(13) end function

Algorithm 3 Optimal mapping algorithm

the preference list based on the above definitions switchesstart to propose to their most preferred controllersWhen thecontroller receives the proposals it begins to choose its mostpreferred switches under the capacity constraint and rejectthe rest Repeat this process until there are nomore proposals

422 Optimal Mapping Algorithm We can get the initialcontroller-to-switch mapping Θ by ldquobidirectional selectionrdquomechanism However the initial mapping is not the optimalsolution Therefore this subsection defines the transfer rulesand uses the iterative algorithm (Algorithm 3) to obtain theoptimal mapping between the controller and the switch

Transfer Rule Assume that switch 119904 corresponds to thecontroller 119886 in the initial mapping Θ After satisfying cer-tain transfer rules switch 119904 corresponds to controller bin the updated mapping The above process is denoted bytransfer(119904 119886 119887) Before the transfer process 119904 is includedin the set of switches mapped by controller 119886 After thetransfer process 119904 is deleted from the set of switches mappedby controller 119886 and added to the set of switches mappedby controller 119887 We define the transfer rule based on theaverage global controller response time After the transferprocess if themapping reduces the global controller responsetime we call that this process satisfies the transfer rules andthen update the controller-to-switch mapping The abovemathematical expression of the transfer process is as follows

Before transfer(119904 119886 119887)119878119886 = Θ (119886) 119878119887 = Θ (119887) (18)

After transfer(119904 119886 119887)119878119886lowast = Θ (119886lowast) = 119878119886 119904 119878119887lowast = Θ (119887lowast) = 119878119887 cup 119904 (19)

Transfer Rule

TR (119904 119886 119887) = 120599 (119905)119886lowast + 120599 (119905)119887lowast minus [120599 (119905)119886 + 120599 (119905)119887] lt 0 (20)

According to the above transfer rules we design the followingalgorithm to dynamically adjust the controller-to-switchmapping [30] and obtain the transfer pair with minimumtransfer rule value TR(119904119894 119888119895 119888119898) After finding the targettransfer pair we update the mapping to achieve the globalcontroller response time optimization

5 Evaluation of SDNManager

SDNManager and the dynamic controller scheduling strategyare described in detail in Sections 3 and 4 In this sectionwe will introduce our implementation of SDNManager andevaluate the performance and overhead of our system Belowwe will detail the experimental program and analyze theexperimental results

51 Implementation We implement SDNManager and testit under OpenFlow environment SDNManager is a fastand lightweight denial-of-service detection and mitigationsystem for SDNThedetailed design is stated in Sections 3 and4 Figure 4 describes the topology used for the experimentsWe use eight physical servers and four pica8 switches inthe experiments Each server is equipped with two Intel(R)Xeon(R) CPU x5690 347GHz and 48GB of RAM and runsCentOS 6 The 1thsim4th server uses virtual machines to run25 clients (including attackers) respectively Four Floodlightcontrollers are implemented on 5thsim8th server independently

Three sets of experiments are performed The first exper-iment shows a comparative performance of the forecastengine with DTS model and ARCH model for a sampletrace from the network traffic In the second experimentwe measure the bandwidth received by the legitimate clientand the attacker with and without SDNManager as a way ofvalidating the prototype In the meanwhile we also comparethe defense effects of SDNManager FloodGuard [12] andSGuard [13] In the last experiment we measure the CPU


Network topology

Ovs layer Ovs layer

Attacker Legitimate clientsA B C

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot

Figure 4 The topology used in the experiments

Table 1 Keenan test and MAPE for DtS and ARCH

Trace Keenan test MAPE119901 value DTS ARCH

1 [20] 687 times 10minus31 523 9272 [21] 293 times 10minus18 861 1192

utilization to compare the overhead of SDNManager SGuardand FloodGuard

52 Forecast Effect of Forecast Engine To validate the forecastengine discussed we conduct statistical analysis by applyingit to selected traces from the research [20] and online resource[21] What is more in order to enhance persuasivenesswe first conduct it on the traces and testify stationarityand nonlinearity and then compare the performance of theforecast engine with our DTS model and ARCH modelNonlinearity testing was done with the well-known Keenantest (a low 119901 value is indicative of nonlinearity) We alsocompute MAPE (Mean Absolute Percentage Error) [31] toachieve a comparison between the two models

Table 1 summarizes the Keenan test results and MAPEvalue for each model From the results we can see our modelsatisfies underlying statistical assumptions which lays thefoundation for the correctness of the following experimentalresults Figure 5 shows the comparative performance results(sample trace [21] September 5 2005 122815ndash122955)

Original trafficForecast (forecast engine)Forecast (ARCH model)

0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)

Figure 5 DTS and ARCH forecast of sample trace

When it comes to forecasting outlier the DTS modelis much more efficient than the ARCH model We use thefollowing equation to compute forecast error

ForecastError () = 100119899119899sum119905=1

10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)


Attacker AUser BUser C

Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(b) Without defense mechanism

Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard

Figure 6 The bandwidth changes before and after the attack

Here 119911119905 and 119905 are the real and estimated values of thetime-series Specifically the forecast error of DTS can beeffectually controlled between 8 and 13 However thatof ARCH is 20 to 40 From this perspective we canconclude that the accuracy of DTS model is higher than thatof ARCH model which is helpful to defend against possibleDoS attacks

53 SDNManager Defense Effects In the second experimentwe measure the bandwidth received by the legitimate clientand the attacker with andwithout SDNManager respectivelyas a way of validating the prototype For ease of explanationwe randomly choose three users A B and C (as Figure 4shows) from the networks and assume that A is the attackerwhose attack rate can be up to 1Gbs B and C are normalusers It is also worth noting that attacker A and userB are controlled by the same SDN controller but user C

is controlled by another different controller Therefore wecan compare the bandwidth received by different legitimateclients so as to increase the reliability of the results Inaddition the randomness introduced in the experiment alsoincreased the reliability of the experimental results Figures6(a) and 6(b) show the bandwidth changes of A B and Cbefore and after the saturation attack with SDNManager andwithout defense mechanism separately

In this experiment with and without SDNManager allusersrsquo bandwidth changes (no matter it is of the attacker orthe normal users) are within the normal range when there isno saturation attack (0sim40 s) This proves that SDNManagerdoes not harm the bandwidth of traffic forwarding If we startthe saturation attack (at about 40 s) without SDNManagerthe bandwidths of both user B and user C go down quicklywhereas the bandwidth received by attacker A continues toincrease without any limits The attacker can easily consume


the computation resource of the controller and overload theinfrastructure of SDN networks and cause the cascading fail-ures of controllers However while using SDNManager thesaturation attack also starts at about 40 s and the bandwidthof user B firstly decreases a little and then returns to normalthe bandwidth of user C almost remains unchanged This isbecause flows with bandwidth consumption higher than thepredicted bandwidth consumption will be penalized by theapplicationThe penalization is proportional to the differencebetween current and predicted usage In addition the forecastengine of SDNManager employs a novel dynamic time-series(DTS) model which greatly improves bandwidth predictionaccuracy In this case SDNManager can protect the SDNsignificantly and avoid the cascading failures of controllerseffectively

In order to compare the defense effect of SDNManagerwith the other defense mechanism we implement SGuardand FloodGuard on the same physical environment In themeanwhile we also measure the bandwidth received by thelegitimate client and the attacker Figures 6(c) and 6(d) showthe bandwidth changes of A B and C before and after thesaturation attack with SGuard and FloodGuard separately

With SGuard and FloodGuard all usersrsquo bandwidthslightly decreases (nomatter it is of the attacker or the normalusers) when there is no saturation attack (0sim40 s) In thisprocess SGuard receives collected flows extracts features thatare important to the DoS flooding attack detection and gath-ers them in 6-tuples which would be passed to the classifiermoduleThen the classifier module analyzes whether a given6-tuple corresponds to a DoS flooding attack or legitimatetraffic FloodGuard also needs to analyze data planemessagesand update its packet-processing policies in this processTherefore SGuard and FloodGuard need to make a compre-hensive judgment according to multifactors and then takethe appropriate protective measures This process involvesa lot of complex calculations so the evaluation resultsare not surprising This also proves that both SGuard andFloodGuard have a slightly negative impact on the bandwidthof traffic forwarding If we start the saturation attack (at about40 s) the bandwidths of both user B and user C go downslowly whereas the bandwidth received by attacker A slightlyincreases The attacker can hardly consume the computationresource of the controller and overload the infrastructureof SDN networks as well as cause the cascading failures ofcontrollers This proves that both SGuard and FloodGuardhave certain defense effects More specifically when thesaturation attack is detected FloodGuardrsquos proactive flow ruleanalyzer module dynamically tracks the runtime value ofthe state sensitive variables from the running applicationsconverts generated path conditions to the proactive flow rulesdynamically and installs these flow rules into the OpenFlowswitches SGuard can also classify traffic as either normal oran attack by using the features extracted from the data setand then take some measures to block attackers Howeverthe defense effects of SGuard and FloodGuard are worsethan the defense effect of SDNManager For example whenwe use SGuard and FloodGuard the bandwidth receivedby the legitimate client is lower than that in SDNManagerwhile the bandwidth received by the attacker is higher

With SDNManagerWithout defense mechanism With SGuard

With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion

Figure 7 CPU utilization

than that in SDNManger In addition the attack detectiontime of SDNManager is also less than that of SGuard orFloodGuard (SDNManager about 15 s SGuard about 28 sand FloodGuard about 37 s) SDNManager uses a lightweightDTS model to predict the bandwidth consumption Thepenalization is also based on the difference between currentand predicted usage Thus SDNManager can quickly detectthe DoS attacks Prevention and early detection of DoSattack are very important SDNManager can minimize thedelay of detecting DoS attack after its occurrence From thisperspective we can conclude that SDNManager has betterdefense effects than SGuard and FloodGuard

54 Overhead Analysis In this section we show our evalua-tion about the overhead of SDNManagerWith SDNManagerand without SDNManager we keep monitoring the resourceconsumption of controller 1 (we choose the CPU utilizationof each controller as the indicator of how many resourcesit consumes) Figure 7 shows the evaluation results We canobserve thatwhen there is no attack (before the 40 s) theCPUutilization of controller with SDNManager is a little higherthan that of the controller without any defense mechanismNot surprisingly this is owing to the design of SDNManagerSDNManager is responsible for performing a bandwidthprediction algorithm so that it will have a little impact on con-troller efficiency but this impact is still within our expectedtolerance When we start the saturation attack at about 40 sthe CPU utilization of controller with SDNManager almostremains unchanged while that of the controller withoutdefense mechanism increases quickly and reaches a peak atabout 50 s Thus the overhead of SDNManager is acceptablefor our system We also compare and analyze the overheadof SDNManager SGuard and FloodGuard We continue touse CPU utilization to represent the overhead of the systemIt is obvious to see that the overall utilization of SDNManageris relatively low which shows that SDNManager is highlyscalable and able to provide security services for morenetwork devices In contrast the overhead of SGuard and


Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4

Figure 8 4-pod fat-tree (example topology)

FloodGuard is higher SGuard and FloodGuard need tomakea comprehensive judgment according to multifactors andthen take the appropriate protective measures This processinvolves a lot of complex calculations so the evaluationresults are not surprising

6 Evaluation of DCS Model

Through the previous analysis we can see that the SDN-Manager proposed in this paper has obvious advantagescompared with other defense mechanisms such as SGuardand FloodGuard However the experimental environment inSection 5 is relatively static which cannot show the advantageof the controller dynamic scheduling strategy applied inthe cloud data center to the global network performance[32] Therefore in order to test the deployment effect of thecontroller dynamic scheduling strategy in the actual SDNenvironment this section further deploys the strategy in theexperimental cloud data center to test its defense effect

The data center topology chosen in this section is a 24-pod fat-tree structure (Figure 8) with a total of 720 switchesand 3456 host users There are 30 Floodlight controllersdeployed in this data center The decay factor of eachcontroller 120574119894 is set to (092sim096) randomly All Floodlightcontrollers are implemented on different physical serversindependently Each Server is equipped with two Intel(R)Xeon(R) CPU x5690 347GHz and 48GB of RAM and runsCentOS 6 Out-of-Band control uses a separate network toconnect all the switches with the controller We implementSDNManager SGuard and FloodGuard on each controllerThe attackers in the cloud data center are randomly selectedwhich are five percent of the total number of users The otherexperimental parameters are set as shown in Section 5Whenattack rate is 100Mbs 200Mbs 400Mbs and 800Mbsrespectively we test and analyze the average controllerresponse time of SDNManager SGuard and FloodGuardwithout applying controller dynamic scheduling strategyIn order to facilitate the comparative analysis we repeatthe experiment with applying controller scheduling strategyThe experimental results are shown in Figures 9 and 10Figures 9(a)ndash9(d) show the global controller response time atdifferent attack rates when the controller dynamic schedulingstrategy is not applied and Figures 10(a)ndash10(d) show theglobal controller response time at different attack rates whenthe controller dynamic scheduling strategy is applied

As can be seen from Figures 9(a)ndash9(d) in the absenceof controller dynamic scheduling strategy the average con-troller response time of SDNManager is significantly lowerthan that of SGuard and FloodGuard before launching attacks(119905 lt 10 s) On the one hand the reason is that the overheadof SDNManager is less than that of SGuard and FloodGuardOn the other hand SGuard and FloodGuard are relatively lessscalable (Scalability is the measure of how a system respondswhen additional hardware is added) It is worth noting thatthe size of the second experimental topology is significantlylarger than that of the first experimental topology Whenwe expand the topology the large topology brings a heavyload to SGuardrsquos abnormal traffic detection module andFloodGuardrsquos proactive flow rule analyzer module Morespecifically SGuard has to receive much more collectedflows extract features that are important to DoS floodingattack detection and gather them in 6 tuples which arepassed to the classifier module to analyze whether a given6-tuple corresponds to a DoS flooding attack or legitimatetraffic FloodGuardrsquos proactive flow rule analyzer modulemust combine symbolic execution and dynamic applicationtracking to derive proactive flow rules at runtime Thisprocess involves a lot of complex calculations and greatlyincrease the response time In contrast SDNManager onlyneeds to predict the bandwidth consumption and enforcethe penalization strategy based on the difference betweencurrent and predicted usage which greatly reduce the con-sumption of resources After 119905 = 10 s when attackers beginto launch attacks the average response time of SGuardand FloodGuard gradually increases With the increaseof attack rate the average response time also increases(Δ119905[lower Mbsdotsminus1] lt Δ119905[higher Mbsdotsminus1]) When attack rateis 100Mbs 200Mbs 400Mbs and 800Mbs respectivelythe corresponding peak response time of SGuard and Flood-Guard is (07 085) (09 12) (116 162) (2 26) From theabove results although the response time is affected it isstill within a reasonable range Compared to the above twodefense mechanisms SDNManager has some advantagesregarding overhead For example the average response timeof SDNManager is basically within (02 06) even at differentattack rates and it also fluctuates smoothly in some ranges Itproves that SDNManager is a lightweight and fast denial-of-service detection and mitigation system for SDN again

As can be seen from Figures 10(a)ndash10(d) when weuse the controller dynamic scheduling strategy the aver-age controller response time of SDNManager SGuard andFloodGuard significantly decreases before launching attacks(119905 lt 10 s) This is because the proposed controller dynamicscheduling strategy can effectively balance the data centercontroller load and optimize the global response time After119905 = 10 s when attackers begin to launch attacks the averageresponse time of SDNManager SGuard and FloodGuardgradually increases With the increase of attack rate theaverage response time also increases (Δ119905[lower Mbsdotsminus1] ltΔ119905[higher Mbsdotsminus1]) When attack rate is 100Mbs 200Mbs400Mbs and 800Mbs respectively the correspondingpeak response time of SDNManager SGuard and Flood-Guard is (015 046 065) (038 052 085) (041 079 117)(048 113 172) It can be seen from the above results that in


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)

(a) Attack rate 100Mbs

Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)

(b) Attack rate 200Mbs

Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)

(c) Attack rate 400Mbs

Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)

(d) Attack rate 800Mbs

Figure 9 Response time comparison using dynamic controller scheduling strategy

the latter case the peak response time is significantly reducedLess statistical fluctuation in response time also produces amore consistent end-user experience Overhead refers to theprocessing time required by system software which includesthe operating system and any utility that supports applicationprograms Response time is the total amount of time it takesto respond to a request for service Thus response time canindicate the overhead of the system For a given request theservice time varies little as the workload increases As can beseen from Figures 9 and 10 the response time with dynamiccontroller scheduling strategy is lower than that without thedynamic controller scheduling strategy On the one hand itproves that the dynamic controller scheduling strategy can

significantly optimize the average controller response timeOn the other hand it proves that the overhead of strategy isin a reasonable range

In summary in this experimental cloud data center sce-nario the controller dynamic scheduling strategy proposedin this paper significantly optimizes the average controllerresponse time which achieves the expected target

7 Future Work

In the future we plan to do the following two worksFirst in order to expand the scale and scope of SDN-

Manager we plan to implement it on Ryu or OpenDaylight


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)



in the future There is no doubt that the current popularSDN controllers are Ryu and OpenDaylight Ryu is com-monly referred to as component-based open source softwaredefined by a networking framework which is implementedentirely in Python It can provide software components withwell-defined APIs that are exposed to allow developers tocreate new network management and control applicationsIt also supports multiple southbound protocols for manag-ing devices What is more OpenDaylight is also a highlyavailable modular extensible scalable and multiprotocolcontroller infrastructure built for SDN deployments onmod-ern heterogeneous multivendor networks which provides amodel-driven service abstraction platform that allows usersto write apps that easily work across a wide variety ofhardware and southbound protocols Therefore Ryu and

OpenDaylight are two of those SDN controllers that weas developers should seriously consider Above all if weconduct the science experiment on Ryu orOpenDaylight theexperimental results will be better

Second we plan to combine SDNManager and the exist-ing Intrusion Detection System (IDS) to further improvedefense efficiency In this paper we view SDNDoS attack as aresource management problem It is a cyber-attack where theperpetrator seeks to make the controller resource unavailableto its intended users by temporarily or indefinitely disruptingservices of a host connected to the controller It is typi-cally accomplished by flooding the targeted controller withsuperfluous requests in an attempt to overload systems andprevent some or all legitimate requests from being fulfilledSimilarly burst traffic may also cause network congestion


and cause the packet drop to take place thus reducing theoverall throughput Therefore it is difficult to distinguishnormal burst traffic and DoS attack traffic A more detailedclassification requires an Intrusion Detection System (IDS)which would be considered in the future

8 Conclusions

In this paper we propose SDNManager to prevent SDNDoS attacks and the cascading failures of controllers SDN-Manager follows a control loop of reading flow statisticsforecasting flow bandwidth changes based on the statisticsand updating the network accordingly Flowswith bandwidthconsumption higher than a predicted usage are penalizedby the application The penalization is proportional tothe difference between current and predicted usage Thusattackers are served with a lower priority than the normalusers The evaluation results demonstrate the effectivenessof SDNManager and show that our system only adds minoroverhead

Notations of SDNManager

119862119894 119894th controllerflow119894119895 119894th flow is corresponding to 119894th controllerBWflow119894119895 Current bandwidth utilization of flow119894119895BWflow119894119895 fcst Predicted bandwidth utilization of flow119894119895BWflow119894119895 target Target allocation bandwidth of flow119894119895OS119888119894 The observed state variablesPS119888119894 The proposed state variablesTS119888119894 The target state variables119891119905 A time-varying parameter120579119905 Parameter of the conditional distribution

of bandwidth120583 Decay factor of control-to-data path119904119905 The conditional score120585 Slack variable

Conflicts of Interest

Theauthors declare there are no conflicts of interest regardingthe publication of this paper

Acknowledgments

This work was supported by the National Natural ScienceFoundation of China (no 060802 61521003) the Nationalkey Research and Development Program of China (nos2016YFB0800100 2016YFB0800101) the National NaturalScience Foundation for Young Scientists (no 61602509)the Science and Technology Project of Henan Province(172102210615) and the Emerging Direction Fostering Fundof Information Engineering University (2016610708)

References

[1] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo ACM SIGCOMMComputer Communication Revie vol 38 no 2 pp 69ndash74 2008

[2] S Shin V Yegneswaran P Porras et al ldquoAVANT-GUARD scal-able and vigilant switch flow management in software-definednetworksrdquo in Proceedings of the 2013 ACM SIGSAC conferenceon Computer amp communications security pp 413ndash424 BerlinGermany 2013

[3] T Wang F Liu J Guo et al ldquoDynamic SDN controllerassignment in data center networks Stablematchingwith trans-fersrdquo in IEEE INFOCOM 2016 - The 35th Annual IEEE Inter-national Conference on Computer Communications San Fran-cisco Calif USA 2016

[4] K ElDefrawy and T Kaczmarek ldquoByzantine fault tolerantsoftware-defined networking (SDN) controllersrdquo in 2016 IEEE40th Annual Computer Software and Applications Conference(COMPSAC) pp 208ndash213 Atlanta Ga USA 2016

[5] G Yao J Bi and L Guo ldquoOn the cascading failures of multi-controllers in software defined networksrdquo in 2013 21st IEEEInternational Conference on Network Protocols (ICNP) Goettin-gen Germany 2013

[6] S Scott-Hayward S Natarajan and S Sezer ldquoA survey ofsecurity in software defined networksrdquo IEEE CommunicationsSurveys amp Tutorials vol 18 no 1 pp 623ndash654 2016

[7] I Ahmad S Namal M Ylianttila et al ldquoSecurity in softwaredefined networks a surveyrdquo IEEE Communications SurveysampTutorials vol 17 no 4 pp 2317ndash2346 2015

[8] K Benton L J Camp and C Small ldquoOpenFlow vulnerabilityassessmentrdquo in Proceedings of the 2nd ACM SIGCOMM Work-shop on Hot Topics in Software Defined Networking (HotSDNrsquo13) pp 151-152 Hong Kong China 2013

[9] Q Yan and F R Yu ldquoDistributed denial of service attacksin software-defined networking with cloud computingrdquo IEEECommunications Magazine vol 53 no 4 pp 52ndash59 2015

[10] D Kotani and Y Okabe ldquoA packet-in message filtering mecha-nism for protection of control plane in OpenFlow networksrdquo inProceedings of the 10th ACMIEEE Symposium on Architecturesfor Networking and Communications Systems ANCS 2014 pp29ndash40 Los Angeles Calif USA October 2014

[11] S M Mousavi and M St-Hilaire ldquoEarly detection of DDoSattacks against SDN controllersrdquo in Proceedings of the 2015International Conference on Computing Networking and Com-munications ICNC 2015 pp 77ndash81 Garden Grove Calif USAFebruary 2015

[12] H Wang L Xu and G Gu ldquoFloodGuard a DoS attackprevention extension in software-defined networksrdquo in 201545th Annual IEEEIFIP International Conference on DependableSystems and Networks pp 239ndash250 Rio de Janeiro Brazil 2015

[13] T Wang and H Chen ldquoSGuard a lightweight SDN safe-guardarchitecture for DoS attacksrdquo China Communications vol 14no 6 pp 113ndash125 2017

[14] R Braga E Mota and A Passito ldquoLightweight DDoS floodingattack detection using NOXOpenFlowrdquo in IEEE Local Com-puter Network Conference pp 408ndash415 Denver Colo USA2010

[15] Q Yan Q Gong and F-A Deng ldquoDetection of DDoS attacksagainst wireless SDN controllers based on the fuzzy syntheticevaluation decision-making modelrdquo Ad Hoc amp Sensor WirelessNetworks vol 33 no 1 pp 275ndash299 2016

[16] T Wang F Liu and H Xu ldquoAn efficient online algorithm fordynamic SDN controller assignment in data center networksrdquoIEEEACMTransactions on Networking vol 25 no 5 pp 2788ndash2801 2017

[17] W Wei X Wei T Chen et al ldquoDynamic correlative VMplacement for quality-assured cloud servicerdquo in 2013 IEEE


International Conference on Communications (ICC) pp 2573ndash2577 IEEE Budapest Hungary 2013

[18] A Amin A Colman and L Grunske ldquoAn approach toforecasting QoS attributes of web services based on ARIMAand GARCH modelsrdquo in Proceedings of the 2012 IEEE 19thInternational Conference on Web Services ICWS 2012 pp 74ndash81 Honolulu Hawaii USA 2012

[19] B Krithikaivasan Y Zeng K Deka et al ldquoARCH-based trafficforecasting and dynamic bandwidth provisioning for periodi-cally measured nonstationary trafficrdquo IEEEACM Transactionson Networking vol 15 no 3 pp 683ndash696 2007

[20] T Benson A Akella and D A Maltz ldquoNetwork traffic charac-teristics of data centers in the wildrdquo in Proceedings of the 10thACM SIGCOMM Conference on Internet Measurement (IMCrsquo10) pp 267ndash280 Melbourne Australia 2010

[21] ldquoUniversity of Napoli Network Monitoring and Measure-mentsrdquo httptrafficcomicsuninaitTracesttracesphp

[22] F X Diebold and M Nerlove ldquoThe dynamics of exchange ratevolatility A multivariate latent factor ARCHmodelrdquo Journal ofApplied Econometrics vol 4 no 1 pp 1ndash21 1989

[23] J A Cornell ldquoFitting a slack-variable model to mixture datasome questions raiserdquo Journal of Quality Technology vol 32 no2 pp 133ndash147 2000

[24] M Kuerban Y Tian Q Yang et al ldquoDOS attack mitigationstrategy on SDN controllerrdquo in 2016 IEEE International Con-ference on Networking Architecture and Storage (NAS) LongBeach Calif USA 2016

[25] A Roy H Zengy J Baggay et al ldquoInside the social networkrsquos(datacenter) networkrdquo in The 2015 ACM Conference on SpecialInterest Group on Data Communication pp 123ndash137 LondonUnited Kingdom 2015

[26] M Yu J Rexford M J Freedman et al ldquoScalable flow-based networking with DIFANErdquo in Proceedings of the 7thInternational Conference on Autonomic Computing SIGCOMM2010 pp 351ndash362 New Delhi India 2010

[27] T Koponen M Casado N Gude et al ldquoOnix a distributedcontrol platform for large-scale production networksrdquo inUsenixConference on Operating Systems Design and ImplementationUSENIX Association pp 351ndash364 2010

[28] A Tootoonchian S Gorbunov Y Ganjali et al ldquoOn controllerperformance in software-defined networksrdquo in Usenix Con-ference on Hot Topics in Management of Internet Cloud andEnterprise Networks and Services pp 10-10 2012

[29] F Liu J Guo X Huang et al ldquoEBA efficient bandwidthguarantee under traffic variability in datacentersrdquo IEEEACMTransactions on Networking vol 25 no 1 pp 506ndash519 2017

[30] J Guo F Liu D Zeng et al ldquoA cooperative game basedallocation for sharing data center networksrdquo in 2013 ProceedingsIEEE INFOCOM pp 2139ndash2147 Turin Italy 2013

[31] D M Keenan ldquoA tukey nonadditivity-type test for time seriesnonlinearityrdquo Biometrika vol 72 no 1 pp 39ndash44 1985

[32] Z Cai Z Wang K Zheng et al ldquoA Distributed TCAMcoprocessor architecture for integrated longest prefixmatchingpolicy filtering and content filteringrdquo IEEE Transactions onComputers vol 62 no 3 pp 417ndash427 2013

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


PACKET INAttack1 Exhaust control

plane bandwidthAttack2 Overload

the buffer

Controller

Step 1 DestID Source

SecurityChannel

Flow table scheduler

Control path

PacketAbstract API

API

SDN switch

Step 2

Data pathFlow table

Flow table

Flow table

update

Hardware driverPacket processing table

Packet forwardingPort

Attacker

Normal userNormaltraffic

Attacktraffic

Step 5

Flow ModStep 4Step 3

Server



Figure 1 SDN architecture and denial-of-service attacks

multiple controllers (ONOS) Wang et al [3] dynamicallyassign controllers to minimize the average response timeand balance load ElDefrawy and Kaczmarek [4] introducea prototype SDN controller that can tolerate Byzantine faultsNote that currentmultiple-controller architectures aremostlydesigned from the aspects of scalability and efficiency insteadof typical security so a more comprehensive architecturewhich emphasizes on the aspect of security urgently needsto be solved What is more in the multiple-controller modelif one controller fails after a successful DoS attack othercontrollers will take over it and the additional loadmaymakethem overloaded causing the cascading failure [5] ultimatelyAs illustrated in Figure 2 (Stage 1) when controller 119888 failsthe load of controller 119888 (switches 7 8 and 9) is redistributedto controller 119886 and 119889 whose loads are then exceeding theircapacities In Stage 2 when controllers 119886 and 119889 fail the loadof controller 119886 (switches 1 2 3 4 5 6 and 7) is redistributedto controller 119887 and the load of controller 119889 (Switches 8 915 16 17 and 18) is also redistributed to controller b too InStage 3 controller b takes all the load to manage the networkIn Stage 4 controller 119889 fails at last and all the switchesare out of control As a result the whole SDN networkbecomes paralyzed and triggered by the failure of onlyone controller which accelerates the paralysis of the wholemodel

To address the above problems we devised SDNManagera fast and lightweight denial-of-service detection and miti-gation system for SDN which can significantly increase theresistance of SDN networks to both single point of failureand cascading failure caused by DoS attack Specifically ourcontributions are as follows

(i) SDNManager employs a novel dynamic time-series(DTS) model which greatly improves bandwidth pre-diction accuracy so it can provide higher detectionaccuracy and ensure better protection to the wholenetworks

(ii) SDNManager is implemented on the control planewhich conforms to the SDN security trend and does

not require anymodification on the data planeThere-fore it is easier to deploy SDNManager compared tothe previous solutions

(iii) SDNManager is valid for all types of DoS attacks(iv) SDNManager adds minor overhead into the entire

SDNOpenFlow infrastructure(v) To further optimize the defense effect we also pro-

pose a controller dynamic scheduling strategy toensure the global network state optimization andimprove the defense efficiency

The rest of the paper is organized as follows Section 2introduces some related works The design of SDNManageris detailed in Section 3 Section 4 presents the dynamiccontroller scheduling strategyThe experiments and results ofthe SDNManager and dynamic controller scheduling strategyevaluation are presented in Sections 5 and 6 respectivelySection 8 introduces our future works Section 8 concludesthe paper

2 Related Work

Some recent research [6ndash8] also pointed out that the SDNcontroller is a vulnerable target of DDoS attacks Yan and Yu[9] argue that although SDN controller itself is a vulnerabletarget of DDoS attacks it also brings us an unexpectedopportunity to mitigate DDoS attacks in cloud computingenvironments Several solutions have been proposed to mit-igate the SDN DoS attacks For example Kotani and Okabe[10] proposed a packet-in message filtering mechanism forprotection of the SDN control plane The packet-in filteringmechanism can first record the values of packet header fieldsbefore sending packet-in messages and then filter out packetsthat have the same values as the recorded ones Of course ifthe DoS attacker deliberately sends new packets that have dif-ferent values from the recorded ones the packet-in filteringmechanism will be completely ineffective Mousavi and St-Hilaire [11] introduced an early detection method for DDoSattacks against the SDN controller based on the entropy


L = 08C L = 08C

L = 08C

L = 08C

L = 12C

L = 36C

L = 14C

L = 14C

Stage 1 Stage 2

Stage 3 Stage 4

Controller


a b

c d

a b

cd

a b

c d

a b

cd

1

2

34

5

6

7 8

9

10 11

12

1314

15

1617

18

1

2

34

5

6

78

9

10 11

12

1314

1516

17

18

1

2

3 4

5

6

7

8

9

1516 17

18

10 11

12

1314

1

2

3 45

6

7

8

9

1516 17

18

10 11

12

1314

C capacity

L load












OpenFlowcollector

Translateto OS

Proxy

OS | PS | TSR W

Monitor

Write OS

Forecast engine

Read OSWrite PS

CheckerDiff

OS-PSReadOS PS

GenerateTS

Write TS

Execute command


Read TS

Updater

Storage service

SDNManager

Control plane

Data plane












119884119905 = 1205901199051205761199051205902119905 = 120596 + 119898sum

119894=1

1198861198941198842119905minus119894 +119898sum119895=1

1198871198951205902119905minus119895 (1)




119891119905 = 120596 + 119899sum119894=1

120572119894119891119905minus1 +119898sum119895=1

120573119895119904119905minus1 (3)


119904119905 = 119904119905nabla119905 (4)


119891119905+1 = 120596 + 120572119891119905 + 120573119904119905 [120597 log119901 (BW119905 | 119891119905 120579119905)120597119891119905 ] (5)











120579 (119905)119895 =119873sum119894=1

120592 (119905)119894 119910 (119905)119894119895 (7)


120599 (119905)119895 = 1120583119895 minus 120579 (119905)119895119874(1198812) (8)



120585 (119905) = sum119872119895=1 120579 (119905)119895 120599 (119905)119895sum119872119895=1 120579 (119905)119895 (9)


Minimize 120585 (119905) (10)

st 120579 (119905)119895 le 120574119895120583119895 forall119895 (11)




119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)







120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)



119895 (15)



(16)












Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



L = 08C L = 08C

L = 08C

L = 08C

L = 12C

L = 36C

L = 14C

L = 14C

Stage 1 Stage 2

Stage 3 Stage 4

Controller


a b

c d

a b

cd

a b

c d

a b

cd

1

2

34

5

6

7 8

9

10 11

12

1314

15

1617

18

1

2

34

5

6

78

9

10 11

12

1314

1516

17

18

1

2

3 4

5

6

7

8

9

1516 17

18

10 11

12

1314

1

2

3 45

6

7

8

9

1516 17

18

10 11

12

1314

C capacity

L load












OpenFlowcollector

Translateto OS

Proxy

OS | PS | TSR W

Monitor

Write OS

Forecast engine

Read OSWrite PS

CheckerDiff

OS-PSReadOS PS

GenerateTS

Write TS

Execute command


Read TS

Updater

Storage service

SDNManager

Control plane

Data plane












119884119905 = 1205901199051205761199051205902119905 = 120596 + 119898sum

119894=1

1198861198941198842119905minus119894 +119898sum119895=1

1198871198951205902119905minus119895 (1)




119891119905 = 120596 + 119899sum119894=1

120572119894119891119905minus1 +119898sum119895=1

120573119895119904119905minus1 (3)


119904119905 = 119904119905nabla119905 (4)


119891119905+1 = 120596 + 120572119891119905 + 120573119904119905 [120597 log119901 (BW119905 | 119891119905 120579119905)120597119891119905 ] (5)











120579 (119905)119895 =119873sum119894=1

120592 (119905)119894 119910 (119905)119894119895 (7)


120599 (119905)119895 = 1120583119895 minus 120579 (119905)119895119874(1198812) (8)



120585 (119905) = sum119872119895=1 120579 (119905)119895 120599 (119905)119895sum119872119895=1 120579 (119905)119895 (9)


Minimize 120585 (119905) (10)

st 120579 (119905)119895 le 120574119895120583119895 forall119895 (11)




119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)







120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)



119895 (15)



(16)












Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia









OpenFlowcollector

Translateto OS

Proxy

OS | PS | TSR W

Monitor

Write OS

Forecast engine

Read OSWrite PS

CheckerDiff

OS-PSReadOS PS

GenerateTS

Write TS

Execute command


Read TS

Updater

Storage service

SDNManager

Control plane

Data plane












119884119905 = 1205901199051205761199051205902119905 = 120596 + 119898sum

119894=1

1198861198941198842119905minus119894 +119898sum119895=1

1198871198951205902119905minus119895 (1)




119891119905 = 120596 + 119899sum119894=1

120572119894119891119905minus1 +119898sum119895=1

120573119895119904119905minus1 (3)


119904119905 = 119904119905nabla119905 (4)


119891119905+1 = 120596 + 120572119891119905 + 120573119904119905 [120597 log119901 (BW119905 | 119891119905 120579119905)120597119891119905 ] (5)











120579 (119905)119895 =119873sum119894=1

120592 (119905)119894 119910 (119905)119894119895 (7)


120599 (119905)119895 = 1120583119895 minus 120579 (119905)119895119874(1198812) (8)



120585 (119905) = sum119872119895=1 120579 (119905)119895 120599 (119905)119895sum119872119895=1 120579 (119905)119895 (9)


Minimize 120585 (119905) (10)

st 120579 (119905)119895 le 120574119895120583119895 forall119895 (11)




119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)







120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)



119895 (15)



(16)












Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia









119884119905 = 1205901199051205761199051205902119905 = 120596 + 119898sum

119894=1

1198861198941198842119905minus119894 +119898sum119895=1

1198871198951205902119905minus119895 (1)




119891119905 = 120596 + 119899sum119894=1

120572119894119891119905minus1 +119898sum119895=1

120573119895119904119905minus1 (3)


119904119905 = 119904119905nabla119905 (4)


119891119905+1 = 120596 + 120572119891119905 + 120573119904119905 [120597 log119901 (BW119905 | 119891119905 120579119905)120597119891119905 ] (5)











120579 (119905)119895 =119873sum119894=1

120592 (119905)119894 119910 (119905)119894119895 (7)


120599 (119905)119895 = 1120583119895 minus 120579 (119905)119895119874(1198812) (8)



120585 (119905) = sum119872119895=1 120579 (119905)119895 120599 (119905)119895sum119872119895=1 120579 (119905)119895 (9)


Minimize 120585 (119905) (10)

st 120579 (119905)119895 le 120574119895120583119895 forall119895 (11)




119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)







120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)



119895 (15)



(16)












Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia







120579 (119905)119895 =119873sum119894=1

120592 (119905)119894 119910 (119905)119894119895 (7)


120599 (119905)119895 = 1120583119895 minus 120579 (119905)119895119874(1198812) (8)



120585 (119905) = sum119872119895=1 120579 (119905)119895 120599 (119905)119895sum119872119895=1 120579 (119905)119895 (9)


Minimize 120585 (119905) (10)

st 120579 (119905)119895 le 120574119895120583119895 forall119895 (11)




119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)







120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)



119895 (15)



(16)












Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





119872sum119895=1

119910 (119905)119894119895 = 1 forall119894 (12)

119910 (119905)119894119895 isin 0 1 forall119894 119895 (13)







120599 (119905)max119895 = 1

120583119895 minus 120574119895120583119895 (14)



119895 (15)



(16)












Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia










Transfer Rule








Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Network topology

Ovs layer Ovs layer


Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Controlleramp

SDNManager

Network topology

C4 C3

C2

C1

S1

S4 S3

S2

Ovs layerOvs layer


middotmiddotmiddot

middotmiddotmiddot









0

50

100

150

200

250

300

350

400

450

500

Band

wid

th (M

bs)

10 20 30 40 50 60 70 80 90 1000Time (s)




10038161003816100381610038161003816100381610038161003816119911119905 minus 119905119911119905

10038161003816100381610038161003816100381610038161003816 (21)



Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(a) With SDNManager


Attack

0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)


Attack


0

200

400

600

800

1000

Band

wid

th (M

bs)

10020 30 40 50 60 70 80 90100Time (s)

(c) With SGuard


Attack

10020 30 40 50 60 70 80 90100Time (s)

0

200

400

600

800

1000Ba

ndw

idth

(Mb

s)

(d) With FloodGuard











With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia







With FloodGuard

10020 30 40 50 60 70 80 90100Time (s)

0

02

04

06

08

10

CPU

util

izat

ion





Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Pod 1 Pod 2 Pod 3

Core

Agg

Edge

Host

Pod 4









Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

100Mbs

0

02

04

06

08

10Re

spon

se ti

me (

s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)






7 Future Work




Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

0

02

04

06

08

10Re

spon

se ti

me (

s)100Mbs


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

200Mbs

0

04

08

12

16

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

400Mbs

0

04

08

12

16

20

Resp

onse

tim

e (s)


Attack

SGuardSDNManager

FloodGuard

10 20 5040300Time units

800Mbs

0

05

10

15

20

25

30Re

spon

se ti

me (

s)








8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




8 Conclusions







Acknowledgments


References





































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





















RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


SDNManager: A Safeguard Architecture for SDN DoS Attacks...

Documents

Transcript of SDNManager: A Safeguard Architecture for SDN DoS Attacks...