SCOR: CP-based Northbound for SDN
•Download as PPTX, PDF•
1 like•373 views
1) The document presents a constraint programming (CP)-based approach for implementing a northbound interface for software-defined networking (SDN) controllers. 2) The proposed interface uses MiniZinc, a CP modeling language, to define predicates for quality-of-service (QoS) routing algorithms and traffic engineering applications. 3) Example predicates modeled in MiniZinc include the network path predicate, path cost predicate, and capacity guarantee predicate.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to SCOR: CP-based Northbound for SDN
Similar to SCOR: CP-based Northbound for SDN (20)
Recently uploaded
Recently uploaded (20)
SCOR: CP-based Northbound for SDN
- 1. SCOR: Constraint Programming-based Northbound Interface for SDN Siamak Layeghy, Farzaneh Pakzad and Marius Portmann School of ITEE, The University of Queensland Brisbane, Australia Presented by Siamak Layeghy 26th International Telecommunication Networks and Applications Conference (ITNAC) 7-9 December 2016, University of Otago, Dunedin, New Zealand 1
- 2. 2
- 3. Merchant Switching Chips Networking: Vertically integrated Closed, proprietary Slow innovation AppAppAppApp Control Plane B Control Plane C Control Plane A or or Specialized Control Plane Specialized Hardware Specialized Features Innovative Networking ? 3
- 4. App App App App App App App App App Specialized Packet Forwarding Hardware Specialized Packet Forwarding Hardware Specialized Packet Forwarding Hardware Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Feature Feature Feature Software Defined Networking (SDN): Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Southbound interface Northbound interface App App App Network Operating System Feature Feature Feature Feature Feature Feature Feature Feature Feature 4
- 5. How good are northbound interfaces? • There is no Standard northbound interface • Many controllers have their own northbound interfaces e.g. OpenDaylight, NOX, Onix and Floodlight (specific definitions) 5
- 6. 2 3 4 6 5 C = 30 D = 2 L = 1 C = 100 D = 1, L = 1 C = 30 D = 5 L = 1 C = 20 D = 1 L = 2 C= 20 D= 1 L = 2 C = 10, D = 9, L = 2 1 7 Routing & Quality of Service (QoS) Routing Shortest Path Routing Widest Path Routing (maximum bandwidth path) Minimum delay Path Routing C: Capacity (Mb/s) D: Delay (sec) L: Loss (Percentage) QoS Routing … 6
- 7. Link-optimization routing Link-constrained routing Path-optimization routing Path-constrained routing Link-constrained Path- optimization routing Link-constrained Link- optimization routing Multi-Path-constrained routing Path-constrained Path- optimization routing Path-constrained Link- optimization routing Link-constrained Path- constrained routing Multi-link-constrained routing Basic QoS Routing Algorithms Composite QoS Routing Algorithms QoS Routing Algorithms[6] Link Metric Path Metric 7
- 8. Routing Framework Network Operating System Applications Network Operating System Network Elements Network State Monitor Route Calculator - - - - - - - - - - - - - - - - - - - - - - - - Flow Installer Host Tracker Topology Discovery Network state Monitoring Flow Demand Estimation QoS Routing Interface - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MiniZinc (Language) QoS Routing Traffic Engineering Link Utilization Load Balancing . . . Network State Database Service Chaining OpenFlow <---NorthBoundAPI---> . . . <-------------------------RoutingFramework------------------------> 8 SCOR
- 9. Constraint Programming CP Pseudocode: Variables: Puzzle (2D-array of integers, range: 1..9) Constraints: Fill Puzzle with initial numbers Alldifferent Rows Alldifferent Columns Alldifferent Sub-Squares Solve: Satisfy constraints for x in range(0,9): for y in range(0,9): if grid[x][y] == 0: return x, y return -1, -1 def isValid(grid, i, j, e): rowOk = all([e != grid[i][x] for x in range(9)]) if rowOk: columnOk = all([e != grid[x][j] for x in range(9)]) if columnOk: # finding the top left x, y co-ordinates of the section containing the i,j cell secTopX, secTopY = 3 *(i/3), 3 *(j/3) for x in range(secTopX, secTopX+3): for y in range(secTopY, secTopY+3): if grid[x][y] == e: return False return True return False def solveSudoku(grid, i=0, j=0): i,j = findNextCellToFill(grid, i, j) if i == -1: return True for e in range(1,10): if isValid(grid,i,j,e): grid[i][j] = e if solveSudoku(grid, i, j): return True # Undo the current cell for backtracking grid[i][j] = 0 return False 9
- 10. The new Northbound Interface Network Operating System Applications QoS Routing Interface - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MiniZinc (Language) QoS Routing Traffic Engineering Link Utilization Load Balancing . . . Service chaining <---NorthBoundAPI---> . . . <-------------------------RoutingFramew Chosen Northbound Language: MiniZinc & Solvers (Gecode, Jacop, ECLiPSe, and many other solvers ) QoS Routing Interface: The Minimum set of needed primitives for implementation of QoS routing and Traffic Engineering applications. 10
- 12. Capacity Guarantee Predicate Residual Capacity Predicate Capacity Limit Predicate Path Cost Predicate Delay Predicate Congestion Predicate Link Utilisation Predicate Northbound Interface QoS Routing Interface: Network Path Predicate 12 Path Bottleneck Predicate …
- 13. Network Path Predicate Implemented using flow conservation: • Variables: 𝑃 𝑋𝑖 : represents a set of nodes that constitutes a flow path and in which 𝑋𝑖, 𝑖 ∈ 1 ≤ 𝑖 ≤ 𝑁 represents the network nodes • Constraints: • 𝐹𝑙𝑜𝑤 𝑖𝑛 𝑋𝑖 + 𝛼 = 𝐹𝑙𝑜𝑤 𝑖𝑛 𝑋𝑖 for 𝑖 ∈ 1 ≤ 𝑖 ≤ 𝑁 if 𝑖 = ‘source’, 𝛼 = 1; else if 𝑖 = ‘destination’ , 𝛼 = −1; else, 𝛼 = 0 • Objective: Find value of {𝑃} that satisfies constraints Network Path Predicate % Variables declaration array[int,int] of var 0..1: LPM, % Link Path Membership, % flow conservation constraint forall(i in 1.. number_of_nodes)( node_flow_in[i] = sum(k in 1.. number_of_links ) (if Links[k, 2] = i then LPM[k] else 0 endif) ∧ node_flow_out[i] = sum(k in 1.. number_of_links) (if Links[k, 1] = i then LPM[k] else 0 endif) ∧ node_flow_in[i] + (if i = s then 1 else 0 endif) = node_flow_out[i] + (if i = t then 1 else 0 endif) ∧ Node_flow_in[i] <= 1 ) 13 Network Path Predicate
- 14. Least Cost Path QoS Routing & TE applications Network Path Predicate Path Cost Predicate Least Cost Path in SCOR % Variable declaration: array[1..number_of_links,1..number_of_flows] of var 0..1: LPM; array[1..number_of_flows] of var int: Cost; % Constraints: constraint network_path( LPM, Link_Parameters, Nodes, Sources, Destinations); constraint path_cost( LPM, Link_Parameters, Cost); % Solve: Solve minimize Cost[1] Least Cost Path with Capacity Constraint Network Path Predicate Path Cost Predicate Capacity Limit Predicate Least Cost Path with Capacity Constraint in SCOR % Variable declaration: array[1..number_of_links,1..number_of_flows] of var 0..1: LPM; array[1..number_of_flows] of var int: Cost; array[1..number_of_flows] of var int: Limits; % Constraints: constraint network_path( LPM, Link_Parameters, Nodes, Sources, Destinations); constraint path_cost( LPM, Link_Parameters, Cost); constraint capacity_limit(LPM, Link_Parameters, Flow_demands, Limits ); % Solve: Solve minimize Cost[1] 14
- 15. 𝑎𝑖𝑗 𝜅 ∈ 0, 1 ∀ 𝑖 ∈ 𝑃; 𝑗 ∈ 𝐸; 𝜋𝑖 𝜅 ∈ Π𝑖, QoS Routing & TE applications 𝜋 𝑖 𝜅 ∈Π 𝑖 𝑥𝑖 𝜅 = 1 ∀ 𝑖 ∈ 𝑃, 𝑚𝑎𝑥 𝑧 , 𝑥𝑖 𝜅 ∈ 0, 1 ∀ 𝑖 ∈ 𝑃; 𝜋𝑖 𝜅 ∈ Π𝑖, 𝑓𝑗 = 𝑖∈𝑃 𝜋 𝑖 𝜅 ∈𝛱 𝑖 𝑎𝑖𝑗 𝜅 𝑥𝑖 𝜅 𝑑𝑖; ∀ ݆∈𝐸, 𝑓𝑗 ≤ 𝑐𝑗 ∀ 𝑗 ∈ 𝐸, 𝑧 ≤ 𝑐𝑗 − 𝑓𝑗 ∀ 𝑗 ∈ 𝐸, Maximum Residual Capacity Network Path Predicate Capacity Guarantee Predicate Maximum Residual Capacity 𝐺𝑖𝑣𝑒𝑛 𝐺𝑟𝑎𝑝ℎ 𝐺 𝑉, 𝐸 𝑎𝑛𝑑 𝑃 𝑝𝑖 𝑓𝑙𝑜𝑤𝑠 𝑡𝑜 𝑏𝑒 𝑟𝑜𝑢𝑡𝑒𝑑 𝑤𝑖𝑡ℎ 𝐷 𝑑𝑖 𝑑𝑒𝑚𝑛𝑎𝑑𝑠: Π𝑖 = 𝜋𝑖 𝜅 : 𝑘 = 0, … , 𝑙𝑖 ∀ 𝑖 ∈ 𝑃, Maximum Residual Capacity in SCOR % Variables array[1..number_of_links,1..number_of_flows] of var 0..1: LPM; array[1..number_of_links] of var int: Residual; % Constraints constraint network_path(LPM, Links, Nodes, sources, Destinations); constraint capacity_guarantee(LPM, Flow_demands, Link_Parameters, Residuals ); % Solve solve maximize min(Residual); 15
- 16. 16 QoS Routing Problem SCOR Predicates # Lines Shortest Path path cost 3 Widest Path Path bottleneck 3 Minimum-Loss Path path cost 3 Minimum-Fixed-Delay Path path cost 3 Fixed-Delay-Constrained Path path cost 3 Least-Cost Path path cost 3 Maximum-Residual-Capacity Path capacity guarantee 3 Delay-Constrained Least Cost Path path cost x 2 4 Delay-Delay jitter-Constrained Path path cost x 2 4 Bandwidth-Delay-Constrained Path path cost – capacity limit 4 Bandwidth-Constrained Least Delay Path path cost – capacity limit 4 Evaluation: completeness Bandwidth Constrained Path capacity limit 3 Bandwidth Guaranteed Path capacity guarantee 3 Minimum-Dynamic-Delay Path delay 3 QoS Routing Algorithms and Predicates to model them in SCOR
- 17. Evaluation: Various Network Topologies Pod 0 Pod 1 Pod 2 Pod 3 Edge Aggregation Core Simple fat-tree topology for k=4, nodes=36, link= 48 Grid topology for k=6, nodes=36, link= 60 17
- 18. Evaluation: Various Number of nodes 18 10 100 1000 10000 100000 0 50 100 150 200 250 300 350 400 SolveTime(ms) Network Size (number of nodes) SCOR, Grid topology LP, Grid topology SCOR, Fat-Tree topology LP, Fat-Tree topology 0 50 100 150 200 250 300 350 400 450 500 550 600 0 50 100 150 200 250 300 350 400 SolveTime(ms) Network Size (number of nodes) Least Cost Path with Capacity Constraints, Grid Topology Least Cost Path, Grid Topology Least Cost Path with Capacity Constraint, Fat-Tree Topology Least Cost Path, Fat-Tree Topology
- 19. Conclusion: 19
- 20. 20
Editor's Notes
- Today I will start with a short background and the related works, then I will explain my research tasks and the methodology I have used to accomplish these research tasks. Finally I will discuss the results I have achieved so far.
- Networking people thought a similar change can happen to networking devices as well. They suggested if we separate hardware and software, then developing applications will be possible, independent from hardware. And, this was the way Software Defined Networking appeared.
- The main idea behind SDN is to separate the forwarding brain from these expensive specialized hardware and concentrate it in a logically centralized node which is called controller. The controller uses an open interface to the hardware, which is now a brain-less forwarding device, to tell them how to forward packets. This interface is called southbound interface. Then applications can use the abstractions created by the controller to program the network. They use another interface which is called northbound interface.
- The Northbound interfaces are the other place where I expected to find some QoS routing related work. But I noticed that current northbound interfaces rarely provide features for this purpose. The only Northbound interface that could be used for QoS routing was SFNet that has a limited scope. Here my conclusion was: “there…TE applications.”
- Google’s project is not the only required technique in today’s networking. It is among a group of routing techniques which are called Quality of Service Routing. In QoS routing, some constraints are considered when looking for a path to satisfy the service requirements. Let me explain this using some examples Suppose this graph represents a network topology with bi-directional links. Each link is associated with three parameters which states its capacity or bandwidth, its delay and its loss ratio. Node number 1 is the source and node number 7 is the destination. A routing algorithm’s job is to find a series of links which connects a source to a destination. The most common routing algorithm in internet is shortest path routing In this shortest path routing the metric considered finding path is the hop count to destination. A path with the least number of hops will be selected. Now, suppose you have an application which requires a lot of bandwidth, let say streaming video. As long as there is enough resources in all paths, it does not matter which routing algorithm you may use. But most of the time it is not the case with the networks and the shortest path which does not care about path’s bandwidth might cause some problem. If you care about the service quality, you would prefer a routing algorithm which takes into account the bandwidth of the path. In fact you may prefer to find a path that provides the maximum bandwidth. The widest path routing finds a path that has the maximum bandwidth in its bottleneck. Then you might have another application, let say (voice over IP) or VOIP. Now you don’t need too much bandwidth, instead your application is sensitive to the end to end delay. In this case, if care about the quality of the service, you may prefer the end to end delay to be taken into account when the path is calculated. So you may prefer to find a path with minimum delay. In this way a lot of metrics can be applied in path calculation and a lot of QoS routing algorithms can be generated.
- In my survey on QoS routing algorithms I found a well cited reference which divides QoS routing schemes to two categories. The first group is called “Basic QoS routing”. In these algorithms only one QoS metric is considered. If this metric is related to a link parameter such as bandwidth, the resulting QoS routing will be called link-optimization or link-constrained routing. Examples include Maximum Bandwidth or the Widest path routing and Bandwidth constrained routing in which the path should have specific bandwidth on its bottleneck. The other case is when the metric is related to the whole path such as delay, then we have path optimization and path constrained routing. Examples include the minimum delay path and constrained delay path routing. The second group of QoS routing algorithms is called composite QoS routing. These QoS routing schemes are created by combining basic QoS routing algorithms. In these algorithms, usually one metric is optimized and one or more metrics are constrained. For instance an algorithm for finding a path with minimum delay and a specified value of bandwidth belongs to this group. Another possible combination is to combine multiple constrained metrics. For instance, a path with specified amount of bandwidth, delay and packet loss.
- The routing framework’s design and implementation is done and is operational, unless a user interface should be designed to allow users select the QoS method which should be applied on flows. At the moment one method manually is selected and path are calculated accordingly.
- The main idea behind using constraint programming for this northbound interface is to separate the complexity from the user. I believe this concept is represented in this image very well. While it might need a lot of effort to produce a chemical product, this lucky scientist can easily produce it. Most of the job is done by the system. There is a similar situation with CP. It allows to describe the required solution without the distraction of algorithmic details. The system that find the solution in the case of CP is called solver Solvers are software that are specially designed for this purpose. People have researched about this for years and generated many powerful solvers. So in CP a user only states the constraints and the solution is found by the solver program. For instance, if we want to solve a Sudoku using CP, We use a variable to define the puzzle. Variables are unknown parameters which can only be known at the end of program. Then we state the constraints as having different values between 1 and 9 in each raw, column and each sub-square Finally the solve item indicates whether it is a constraint satisfaction or optimization problem. This is how Sudoku can be solved in Python. As you can see, every step of the procedure should exactly be determined in this way.
- The CP language chosen for the Northbound interface, is MiniZinc. MiniZinc is a constraint modelling language created by NICTA people such as Peter J. Stuckey, in Melbourne and Monash Universities. MiniZinc is high-level enough to express most constraint problems easily, low-level enough that it can be mapped onto existing solvers. It comes with a few solvers such as Gecode but it is possible to use many more available solvers such as jacop and eclipse. This northbound interface has two layers, the first layer is the MiniZinc language, and the second layer, is the set of primitives or predicates in MiniZinc literature, which makes it possible to implement all QoS routing algorithms. People: Ralph Becket, Sebastian Brand, Mark Brown, Thibaut Feydy, Julien Fischer, Maria Garcia de la Banda, Kim Marriott, and Mark Wallace allows concise and powerful modelling of problems, and solving of the same model by many solvers: constraint programming, mixed integer programming, SAT, SMT and local search. Powerful solving technology lazy clause generation provides the state-of-the-art constraint programming solvers, and unbeatable results on many problems, particularly scheduling. Nested constraint programming: an extension to CP to allow the expression and solving of complex nested discrete optimization problems, such as minimax problems, stochastic optimization problems, bi-level and multi-level optimization, quantified constraint optimization problems, and more. MiniZinc comes with these solvers: FD , CPX , MIP , Lazy
- This layer consists of one main predicate which identifies a network path and seven other predicates which state various constraints about bandwidth, delay and other metrics. Each QoS routing algorithm is generated by combining one or more predicates with the Path predicate.
- The path predicate is implemented using flow conservation rule. This rule states the total sum of the flows entered a node is equal to sum of the flows leaving the node unless the node is either source or sink. The CP Pseudo-code here includes a single variable which represents the link to path membership. The only constraint used here is the one that states the flow conservation rule. and this is the actual code for the path predicate.
- Let see for instance how the minimum delay path is created. To create this application, it is enough to add the total cost predicate to the path predicate and define the cost as the transmission delay. and this is the real implementation of this application using the new northbound interface. Then we want to implement the algorithm which calculates minimum delay path that has specific bandwidth. This is called capacity constrained minimum delay path. To create this, only one predicate is added to previous program which applies capacity constraint. and this is the actual implementation of the application in the new northbound interface.
- To have a feeling how this new interface makes it easy to create QoS routing applications, I use another example: the maximum residual capacity. In Maximum residual capacity, each flow is placed where the remaining capacity after placing the flow is the maximum in the bottleneck. This helps to route more con-current flows in the same network by load balancing. This is the formal problem definition: It states that for a Graph of V nodes and E links and a set of P flows with D demands, find the maximum of Z in a way that Each flow can be directed through Py_i paths And the total number of paths that a flow can be routed is just 1 And the flow cannot be splitted into separate paths Where the total flow of a link j is the sum of all flows going through that link It should be less than the capacity of the link And Z is remaining capacity of the links I could not find the exact implementation of this algorithm in python but I found a similar example which is called “Maximum Con-current Flow” It is written in 400 lines of code. Now let see how this algorithm is implemented in the new northbound interface. It is created by adding the residual capacity predicate to the path predicate. And this is the real implementation of the algorithm in the new northbound interface. each commodity: i ∈ P set of routes (paths) Πi = {πik : k = 1,...,li} from node si to node ti (there are li paths) Let xik denote a 0/1 variable, which equals 1 if πik is the path for commodity i and is 0 otherwise. binary variable akij indicates whether or not path πik uses the arc j ∈ A
- And these are QoS routing and TE applications created using the 8 predicates. Because of interest of time I will not go through all these applications but I explain how they are created using a few examples.
- So far, it is shown that how useful is the new northbound interface. But one might ask if these applications are practical? To evaluate this, we ran a set of experiments with various setups. We used two major topologies in these experiments which included the fat tree topology which is mostly used in data centres and grid topology that can be used to model various networks.
- In the first series of experiments we changed the number network nodes and run the application to find the requested path. Here is some examples of the results. The X axis indicates the number of nodes and the Y axis indicates the time that the solver needed to solve the problem and find the path. As you can see, for complex QoS routing problems such as maximum residual capacity or maximum link utilization, where there are near to 400 nodes in the network, the required time is in the range of 150 Milliseconds which is quite practical.
- In the first series of experiments we changed the number network nodes and run the application to find the requested path. Here is some examples of the results. The X axis indicates the number of nodes and the Y axis indicates the time that the solver needed to solve the problem and find the path. As you can see, for complex QoS routing problems such as maximum residual capacity or maximum link utilization, where there are near to 400 nodes in the network, the required time is in the range of 150 Milliseconds which is quite practical.
- Then we increased the number of con-current flows and ran the experiments. For a network of about 400 nodes, the solution time for 4 con-current flows is around 1 second which is acceptable, however, by adding new flows, solution time will increase to 5 to 6 seconds that I still believe it is acceptable. In a network of near to 400 nodes, working with micro-flows is not common. So it is quite acceptable practice to aggregate flows and apply the above QoS routing algorithms on the aggregated flows, for instance 4 con-current flows. The other possible solution is to force solver to calculate the output in one second, for instance. Based on our experiments, the difference between this solution and the final solution is very tiny. My progress to date ends here, let’s see what do we have in the research plan.