Configuring a network is complicated and error-prone. SDN and the OpenFlow protocol aim to simplify the task by replacing each vendor's proprietary configuration syntax with a single unified language.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In an OpenFlow SDN environment, engineers can move away from managing individual devices with protocols like Spanning Tree instead decoupling the network's control plane and placing it into a centralized SDN controller. The controller is then able to make packet forwarding decisions for all devices on the network.
But the OpenFlow interface has also proven to be complex, so researchers are developing network programming languages, such as Frenetic and Pyretic that will simplify OpenFlow SDN programming.
The complicated process behind OpenFlow SDN
While OpenFlow controllers eliminate the need for configuring and managing hundreds of individual devices, the routing decision-making process behind this system can be complicated.
In a controller-based SDN environment, when a packet with a previously unseen source and destination address arrives at a network device, the device sends the packet to the controller. The controller determines how the packet should be routed. It then configures forwarding rules on the device that govern how subsequent packets with the same source and destination should be routed.
Source and destination pairs are called flows. The controller creates a forwarding rule for each flow and configures the rule on each device along the path. The rule can be based on factors such as traffic loads, security or latency requirements.
A flow rule may specify an individual source and destination pair or it may contain wildcard addresses. Each device maintains a prioritized list of flow rules. When a packet arrives at a device it is compared against the list of flow rules and routed based on the highest priority rule.
Wildcard rules must be defined carefully so a packet that should be sent to the controller for individual handling isn't sent based on a wildcard rule defined earlier. When a flow is routed based on multiple criteria, a single rule must be created that incorporates all of the criteria. Otherwise, the flow will be routed based on the first rule in the list, and subsequent rules will be ignored. These are complexities that must be made simpler.
Network programming languages streamline OpenFlow
Frenetic and Pyretic are programming languages currently being researched by faculty and students primarily at Princeton and Cornell Universities. Both are high-level languages designed to hide the complexity of SDN programming and reduce the probability of errors. Work on both continues within the overall framework of the Frenetic Project.
Frenetic consists of a programming syntax and runtime based on the Ocaml programming language. It is designed to operate with the open source NOX controller. Pyretic is based on Python and operates with the POX controller.
Both languages speed network policy development by replacing a large number of individual OpenFlow commands with a few high-level commands. They also simplify policy creation.
Specifying multiple switch actions using low-level OpenFlow commands can be difficult and error prone. Statements supporting each action must be carefully ordered to ensure that commands are executed in the proper sequence. For example, configuring a switch to both forward packets and count them requires combining OpenFlow commands in a single sequence of commands. Writing a single policy module that configures a device to forward based on current link loading, packet priority and security, while also counting packets, is extremely difficult.
Using the language interfaces, programmers can specify each individual policy based on a single action or criterion. They can then write each policy component as a separate module using Frenetic or Pyretic. The language runtimes combine the policies to create OpenFlow commands that implement each of the criteria and sequence them properly. That eliminates the danger that commands implementing one policy will conflict with those implementing the other policy.
The languages and runtimes also eliminate common programming errors such as failing to address possible race conditions. A common situation occurs after the first packet of a new flow is detected. A second packet may arrive at the next device on the path before the controller is able to install the new rule in that device.
The second packet may be sent to the controller and result in unnecessary computation, or it may be forwarded incorrectly due to a wildcard rule already in place. The runtimes create rules that prevent this situation. The runtimes also eliminate inconsistency between devices during policy updates. They guarantee that all packets will be routed either by the old policy or the new one.
Frenetic and Pyretic: Slightly different approaches
Frenetic and Pyretic differ in how policy modules can be interpreted. Frenetic offers a parallel model. It appears to the programmer that each policy module acts on each packet directed to the controller, that is, modules are executed in parallel. Policies supporting multiple criteria such as forwarding based on link load while counting packets would appear to operate in parallel.
Pyretic also supports parallel execution but it adds sequential execution. For example, a Pyretic programmer can specify that an access control module is to be executed before a load balancing module. Programmers can also specify policies that change over time.
Monitoring the state of the network is an important function. The controller must be informed quickly about changes in load on individual links or failure of a link. The languages include commands that are interpreted by the runtime to create a set of OpenFlow commands to detect network events, poll counters and combine statistics to provide an overall view of network operations.
Frenetic and Pyretic going forward
Work continues on both languages. The Pyretic team is adding features such as support for quality of service and it is developing applications including RADIUS and DHCP servers. Other researchers have become interested. Faculty and students at Georgia Tech re-implemented its Resonance controller using Pyretic. Work was completed in a single day, and the number of lines of code was reduced by a factor of six. The Frenetic team is improving the efficiency of its compiler and verifying correct code generation.
As these languages emerge from research facilities and become available for commercial application, they will greatly accelerate the adoption of SDN.
About the author:
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.