New version page

Nettle: Functional Reactive Programming of OpenFlow Networks

Upgrade to remove ads

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View Full Document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Upgrade to remove ads
Unformatted text preview:

Nettle: Functional Reactive Programmingof OpenFlow NetworksAndreas Voellmy and Paul HudakYale [email protected], [email protected] We describe a language-centric approach to solving th e com-plex, low-level, and error-prone problem of network control. Specifically,we have designed a domain-specific language called Nettle, embeddedin Haskell, that allows programming OpenFlow networks in an elegant,declarative style. Nettle is based on the principles of functional reactiveprogramming (FRP), a n d as such has both continuous and discrete ab-stractions, each of which is leveraged in the design of Nettle: using thediscrete nature of FRP we are able to elegantly capture co ntrol messagesto and from OpenFlow switches as streams of Nettle events; using thecontinuous nature of FRP we are able to express dynamic load balancingalgorithms in a concise manner, reflecting directly the mathematics ofthe underlying control system. We have implemented Nettle and tested iton real OpenFlow switches. We demonstrate our methodology by writingseveral non-trivial OpenFlow controllers.1 IntroductionNetworks continue to increase in importance and complexity, yet the means toconfigure them remain primitive and error prone. There is no precise languagefor d es c r ib in g what a network should do, nor how it should behave. At best,network operators document their complex requirements informally, but thenare faced with the daunting and unreliable task of translating their specificationsby hand into t he low-level, device-specific, often arcane s cr ip ts used to controltoday’s commercial switches and routers. This low-level programming modeloften results in devices and protocols interacting in unexpected and unintendedways [5], and gives little hope in validating high-level protocols and policies suchas th ose related to traffic engineerin g, bus in es s relations h ip s, se cu r ity [11, 3].Part of the prob lem is that most conventional routers are n ot only low-level,they are also decidedly impoverished in expressive power, and inflexible in theirconfiguration capabilities – it is sometime s difficult to get even the most basicconfigurations to work correctly.We believe that these problems can be overcome through the use of advancedhigh-level programming languages and tools that allow on e to express the overallnetwork behavior as a single program expressed in a declarative style. Althoughthis idea has been sugges ted by several researchers [3, 9], the development of anactual solution has been elusive. There are two aspects of our approach that webelieve will result in a successful outcome: First, we abandon conventional com-mercial routers in favor of OpenFlow switches [1]. OpenFlow presents a unified,flexible, dynamic, remotely programmable interface that allows network switchesto be controlled from a logically centralized location.Second, we use advanced programming language ideas to ensure th at ourprogramming model is expressive, natural, concise, and designed precisely fornetworking applications. Specifically, we borrow ideas from functio nal reactiveprogramming (FRP) and adopt the design methodology of domain-specific lan-guage (DSL) research.Our overall approach, which we call Nettle, allows us to radically rethink theproblem of network c onfiguration. Indeed, we like the mantra, “Don’t configurethe network, progra m it!” In doing this at a high level, we enable the developmentof new, powerful, and natural network policies, protocols, and control algorithms.2 Overall ApproachWe are interested in the problem of configuring a local network of OpenFlowswitches, varying i n size from a s in gle router to several hundred, or even thou-sands. Such a network may belong to a commercial entity, an ISP, a university,etc. Typically, certain border routers of such a network interface to the Inter-net, but our focus is on the internal interactions and coordin ation between localswitches. Unlike most conventional networks, all of the OpenFlow switches com-municate to a centralized controller. It is here th at a Nettle program runs, thusforming a global control policy for the entire local network.Figure 1 illustrates our software architecture. At the bottom are OpenFlowswitches the mse lves. One level up is Haskell, our host language. Above that is alibrary, HOpenFlow, that abstractly captures the OpenFlow protocol.OpenFlowHaskellHOpenFlowFunctional Reactive Progra mmingSecurityRoutingContracts. . . . . . . . .. . . . . . . . .Fig. 1. Nettle layered system architecture.The next layer in our stack is an instantiation of the Functional ReactiveProgramming (FRP) paradigm. FRP is a family of languages that provide anexpressive and mathematically sound approach to programming interactive sys-tems in a declarative manner. FRP has been used successfully in computer ani-mation, robotics, control systems, GUIs , interactive multimedia, and other areasin which there is a combination of both continuous and d is cr e te entities [10, 4].This is t he layer that is the focus of this paper.Above the FRP layer, we p lan to implement an extensible family of DSLs,each member capturing a different network abstraction. For example, we mayhave one DSL for access control, another for t r affic engineering, and anotherfor interdomain contracts. As a concrete example, in [12] we describe a DSLfor expressing a class of dynamic security policies for campus networks and itsimplementation on Nettle’s FRP layer.Our contributions in the design of Nettle/FRP may be summarized as follows:1. We have designed a discrete, event-based abstraction that captures commu-nication patterns to and from OpenFlow switches. With this abstraction weare able to develop complete controllers in an elegant style that treat eachmessage stream as a whole, rather than as individual messages.2. We have designed a notion of continous, time-varying quantities that capturehigher-level abstractions such as traffic volume on individual network links.With this abstraction we are able to think of certain kinds of network control,such as traffic engineering, as a continous control problem, much like inconventional control theory.3. We have implemented all of Nettle/FRP in the context of the software archi-tecture of Figure 1. We have tested our system on refe r en ce implementationsof th e OpenFlow switches, as well as on real OpenFlow switches.4. We have us ed Nettle/FRP to design several non-trivial controllers that solverealistic


Download Nettle: Functional Reactive Programming of OpenFlow Networks
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Nettle: Functional Reactive Programming of OpenFlow Networks and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Nettle: Functional Reactive Programming of OpenFlow Networks 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?