Frenetic: A Network Programming Language

With the development of software defined network (SDN) architectures, the network becomes programmable. For example, OpenFlow allows programmers to specify forwarding rules at the controllers, and the controller will install these rules to the switches. Unfortunately, these network programming languages such as OpenFlow and NOX can be difficult to use.

“… while OpenFlow and NOX now make it possible to implement exciting new network services, they do not make it easy.”

These languages have low-level of abstractions. While programming, programmers need to think about the switch-level rules, which are often composed of multiple tasks.

 

To Make Network Programming Easier

The goal of this paper is to simplify network programming by designing a higher level programming language. It starts from identifying three main problems in the existing programming language.

Problem 1: Anti-Modular

Here is an example for the anti-modular design in current network programming language.

Screen Shot 2017-03-09 at 10.41.47 AM

(picture from slides at http://frenetic-lang.org/publications/frenetic-icfp11-slides.pdf)

When we integrate the code of a repeater and a web monitor, we need to consider how these functions will influence each other at the switch level and carefully arrange the order and priority of each line of the code.

Problem 2: Two-Tiered Model

The current SDN architecture has a two-tiered model. When a packet arrives at the switch, the switch will check whether there are existing rules about how the packet should be forwarded. If so, the switch will forward the packet without notifying the controller. Otherwise, the switch will forward the packet to the controller. This design brings a problem: the controller will not see all the packets in the network. If we want to monitor all the packets in the network, we need to inspect and modify rules at the switch level.

Screen Shot 2017-03-09 at 10.55.44 AM

(picture from slides at http://frenetic-lang.org/publications/frenetic-icfp11-slides.pdf)

Problem 3: Network Race Conditions

When a switch S sees a packet p1 that it doesn’t know where to forward, it will ask the controller to help with the following steps:

  1. S forwards p1 to the Controller C
  2. finds out the forwarding rules for p1 and sends the rules r to S
  3. installs r received from C
  4. When S receives a new packet p2 that matches r, it uses to forward p2

However, since the switches and the controller form a distributed system, race conditions can occur. For example, step 4 can happen before step 3 because it takes time for r to be transferred from C to S. In this case, S would forward p2 to C because it has not received the rules for p2 yet.

Separation of Reading and Writing

All these three problems in current network programming can be contributed to the lack of efficient separation between reading (i.e., monitoring network conditions) and writing (i.e., specifying forwarding rules). Frenetic solves these problems by decomposing the language into two tasks: monitoring and forwarding.

Frenetic provides a declarative query language for classifying and aggregating net- work traffic as well as a functional reactive combinator library for describing high-level packet-forwarding policies.

Screen Shot 2017-03-09 at 11.28.51 AM

Presentation:

Reference:

http://frenetic-lang.org/publications/frenetic-icfp11.pdf

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s