Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Software Defined Networking, OPEN FLOW : CONFLICT RESOLUTION AND MERGE

IP.com Disclosure Number: IPCOM000235067D
Publication Date: 2014-Feb-26

Publishing Venue

The IP.com Prior Art Database

Abstract

In the realm of Open flow controller flows generated by various services either proactively or reactively needs to be merged with the flows already installed on the network, So that the incoming packet can hit a single flow on the switch flow table and satisfy actions specified by various services. This whole process of performing arbitration across various functions in the controller is explained in Flow conflict and merge.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 22% of the total text.

Page 01 of 10

Software Defined Networking, OPEN FLOW : CONFLICT RESOLUTION AND MERGE

Abstract:
-------------
In an application ( or a management system , centralized controller etc ) hosting multiple services collaborating with each other, focused on managing multiple remote devices( and systems ), which have minimal logic processing capacity . There is a need to merge rules from different services as well as against rules on the devices( previously installed ), these optimized final set of rules reflect intention of individual services. Services continuously evolve rules based on events such as network events that impact the devices. These devices could support simple management protocols like "Open Flow" and minimal infrastructure such a one or more tables on them to install Rules on them. So any traffic or data are processed resulting in the one or more actions intended by the over all application based on these rules.

Rules from different services are conflict resolved before installing optimized rule set. This optimized rule set reflect the intended behavior of one or more individual services. This operation allows multiple services to collaborate within the application.

This approach also gives the ability to undo/modify/alter final ruleset on the device as the application state undergoes change based on the state of devices/data/traffic etc.

Know Solutions: ----------------------
Some of the solutions include:


1) If the target device or system is capable of processing complex logic through the use of protocols, then the device itself can take the intended actions based on filters.


2) device or system can process data or network traffic by enumerating all the rules/filters, thus achieving the intended actions.


3) Rules can be spread across on multiple tables and the device is made to search through a matching ruleset on all the tables until a match is found.

Drawback of existing solutions:
--------------------------------------------
Existing solutions heavily rely on the devices and systems that have intelligent processing capability at wire speed to achieve the target final action, By implementing specialized protocols between these devices to converge on the final action.

Also a specialized rule engine can utilized to achieve the final action. Generic rule engines based solutions are heavy weight components which are external that may not serve the purpose if the final rules convergence needs to happen at wire speed. Also leveraging generic rule engines for custom applications are a challenge.

References:
-----------------
1) Merging filter rules to reduce forwarding path lookup cycles :
Publication No: US 8065721 B1 / US8332927
URL : https://www.google.com/patents/US8065721?dq=merging+rules&hl=en&sa=X&ei=wpRVUuu1NuXtiAfYvI C4Bw&ved=0CDcQ6AEwAA


2) Conflict-handling assimilator service for exchange of rules with merging

1


Page 02 of 10

Publication No: US6910028 B2 / US20030023573

URL : https://www.google.com/patents/US6910028?pg=PA7&dq=merge+r...