Composing Software-Defined Networks - Freneticfrenetic-lang.org/publications/composing-  · Composing…

Download Composing Software-Defined Networks - Freneticfrenetic-lang.org/publications/composing-  · Composing…

Post on 18-Aug-2018

212 views

Category:

Documents

0 download

TRANSCRIPT

<ul><li><p>Composing Software-Defined Networks</p><p>Christopher Monsanto, Joshua Reich, Nate Foster, Jennifer Rexford, David WalkerPrinceton Cornell</p><p>AbstractManaging a network requires support for multiple con-current tasks, from routing and traffic monitoring, to ac-cess control and server load balancing. Software-DefinedNetworking (SDN) allows applications to realize thesetasks directly, by installing packet-processing rules onswitches. However, todays SDN platforms provide lim-ited support for creating modular applications. This pa-per introduces new abstractions for building applicationsout of multiple, independent modules that jointly man-age network traffic. First, we define composition opera-tors and a library of policies for forwarding and queryingtraffic. Our parallel composition operator allows multi-ple policies to operate on the same set of packets, while anovel sequential composition operator allows one policyto process packets after another. Second, we enable eachpolicy to operate on an abstract topology that implic-itly constrains what the module can see and do. Finally,we define a new abstract packet model that allows pro-grammers to extend packets with virtual fields that maybe used to associate packets with high-level meta-data.We realize these abstractions in Pyretic, an imperative,domain-specific language embedded in Python.</p><p>1 IntroductionSoftware-Defined Networking (SDN) can greatly sim-plify network management by offering programmersnetwork-wide visibility and direct control over the un-derlying switches from a logically-centralized controller.However, existing controller platforms [7, 12, 19, 2,3, 24, 21] offer a northbound API that forces pro-grammers to reason manually, in unstructured and adhoc ways, about low-level dependencies between dif-ferent parts of their code. An application that per-forms multiple tasks (e.g., routing, monitoring, accesscontrol, and server load balancing) must ensure thatpacket-processing rules installed to perform one task donot override the functionality of another. This resultsin monolithic applications where the logic for different</p><p>tasks is inexorably intertwined, making the software dif-ficult to write, test, debug, and reuse.</p><p>Modularity is the key to managing complexity in anysoftware system, and SDNs are no exception. Previousresearch has tackled an important special case, whereeach application controls its own slicea disjoint por-tion of traffic, over which the tenant or application mod-ule has (the illusion of) complete visibility and con-trol [21, 8]. In addition to traffic isolation, such a plat-form may also support subdivision of network resources(e.g., link bandwidth, rule-table space, and controllerCPU and memory) to prevent one module from affect-ing the performance of another. However, previous workdoes not address how to build a single application outof multiple, independent, reusable network policies thataffect the processing of the same traffic.</p><p>Composition operators. Many applications requirethe same traffic to be processed in multiple ways. Forinstance, an application may route traffic based on thedestination IP address, while monitoring the traffic bysource address. Or, the application may apply an access-control policy to drop unwanted traffic, before routingthe remaining traffic by destination address. Ideally, theprogrammer would construct a sophisticated applicationout of multiple modules that each partially specify thehandling of the traffic. Conceptually, modules that needto process the same traffic could run in parallel or in se-ries. In our previous work on Frenetic [6, 14], we in-troduced parallel composition, which gives each module(e.g., routing and monitoring) the illusion of operating onits own copy of each packet. This paper introduces a newkind of compositionsequential compositionthat al-lows one module to act on the packets already processedby another module (e.g., routing after access control).</p><p>Topology abstraction. Programmers also need waysto limit each modules sphere of influence. Rather thanhave a programming platform with one (implicit) globalnetwork, we introduce network objects, which allow</p></li><li><p>Monitorsrcip=5.6.7.8 count</p><p>Routedstip=10.0.0.1 fwd(1)dstip=10.0.0.2 fwd(2)</p><p>Load-balancesrcip=0*,dstip=1.2.3.4 dstip=10.0.0.1srcip=1*,dstip=1.2.3.4 dstip=10.0.0.2</p><p>Compiled Prioritized Rule Set for Monitor | Routesrcip=5.6.7.8,dstip=10.0.0.1 count,fwd(1)srcip=5.6.7.8,dstip=10.0.0.2 count,fwd(2)srcip=5.6.7.8 countdstip=10.0.0.1 fwd(1)dstip=10.0.0.2 fwd(2)</p><p>Compiled Prioritized Rule Set for Load-balance &gt;&gt; Routesrcip=0*,dstip=1.2.3.4 dstip=10.0.0.1,fwd(1)srcip=1*,dstip=1.2.3.4 dstip=10.0.0.2,fwd(2)</p><p>Figure 1: Parallel and Sequential Composition.</p><p>each module to operate on its own abstract view of thenetwork. Programmers can define network objects thatnaturally constrain what a module can see (informationhiding) and do (protection), extending previous work ontopology abstraction techniques [4, 17, 10, 25].</p><p>The Pyretic Language and System. Pyretic is a newlanguage and system that enables programmers to spec-ify network policies at a high level of abstraction, com-pose them together in a variety of ways, and executethem on abstract network topologies. Running Pyreticprograms efficiently relies on having a run-time systemthat performs composition and topology mapping to gen-erate rules to install in the switches. Our initial proto-type, built on top of POX [19], is a simple interpreterthat handles each packet at the controller. While suffi-cient to execute and test Pyretic programs, it does notprovide realistic performance. In our ongoing work, weare extending our run-time system to proactively gener-ate and install OpenFlow rules, building on our previousresearch [14].</p><p>The next section presents a top-down overview ofPyretics composition operators and topology abstractionmechanisms. The following two sections then explaineach in detail, building a complete picture of Pyreticfrom the bottom up. Section 3 presents the Pyretic lan-guage, including an abstract packet model that conveysinformation between modules, and a library for definingand composing policies. Section 4 introduces networkobjects, which allow each module to apply a policy overits own abstract topology, and describes how our run-time system executes Pyretic programs. To evaluate thelanguage, Section 5 presents example applications run-ning on our Pyretic prototype. After reviewing relatedwork in Section 6, we conclude in Section 7.</p><p>2 Abstractions for Modular ProgrammingBuilding modular SDN applications requires support forcomposition of multiple independent modules that eachpartially specify how traffic should be handled. The par-allel and sequential composition operators (Section 2.1)offer simple, yet powerful, ways to combine policiesgenerated by different modules. Network objects (Sec-</p><p>tion 2.2) allow policies to operate on abstract locationsthat mapthrough one or more levels of indirectiontoones in the physical network.</p><p>2.1 Parallel and Sequential Composition Operators</p><p>Parallel and sequential composition are two centralmechanisms for specifying the relationship betweenpacket-processing policies. Figure 1 illustrates these ab-stractions through two examples in which policies arespecified via prioritized lists of OpenFlow-like rules.Each rule includes a pattern (field=value) that matcheson bits in the packet header (e.g., source and destina-tion MAC addresses, IP addresses, and TCP/UDP portnumbers), and simple actions the switch should perform(e.g., drop, flood, forward out a port, rewrite a headerfield, or count1 matching packets). When a packet ar-rives, the switch (call it s) identifies the first matchingrule and performs the associated actions. Note that onemay easily think of such a list of rules as a function: Thefunction input is a packet at a particular inport on s andthe function output is a multiset of zero or more pack-ets on various outports of s (zero output packets if thematching rule drops the input packet; one output if it for-wards the input; and one or more if it floods). We call apacket together with its location a located packet.</p><p>Parallel Composition (|): Parallel composition givesthe illusion of multiple policies operating concurrentlyon separate copies of the same packets [6, 14]. Given twopolicy functions f and g operating on a located packetp, parallel composition computes the multiset union off (p) and g(p)that is, every located packet produced byeither policy. For example, suppose a programmer writesone module to monitor traffic by source IP address, andanother to route traffic by destination IP address. Themonitoring module (Figure 1, top-left) comprises a sim-ple policy that consists of a single rule applying the countaction to packets matching source IP address 5.6.7.8.The routing module (Figure 1, top-middle) consists oftwo rules, each matching on a destination IP address andforwarding packets out the specified port. Each module</p><p>1The OpenFlow API does not have an explicit count action; in-stead, every rule includes byte and packet counters. We considercount as an explicit action for ease of exposition.</p><p>2</p></li><li><p>generates its policy independently, with the programmerusing the | operator to specify that both the route andmonitor functions should be performed simultaneously.These can be mechanically compiled into a single jointruleset (Figure 1, bottom-left) [14].</p><p>Sequential Composition (&gt;&gt;): Sequential composi-tion gives the illusion of one module operating on thepackets produced by another. Given two policy func-tions f and g operating on a located packet p, sequen-tial composition applies g to each of the located pack-ets produced by f (p), to produce a new set of locatedpackets. For example, suppose a programmer writesone module to load balance traffic destined to a pub-lic IP address 1.2.3.4, over multiple server replicas atprivate addresses 10.0.0.1 and 10.0.0.2, respectively,and another to route traffic based on the chosen destina-tion server. The load-balancing module splits traffic des-tined to the public IP between the replicas based on theclient IP address. Traffic sent by clients with an IP ad-dress whose highest-order bit is 0 go to the first server,while remaining traffic goes to the second server. Asshown in Figure 1 (top-right), the load balancer performsa rewriting action to modify the destination address tocorrespond to the chosen server replica, without actuallychanging the packets location. This load balancer canbe composed sequentially with the routing policy intro-duced earlier. Here the programmer uses the &gt;&gt; opera-tor to specify that load balancing should be performedfirst, followed by routing. Again, these may be me-chanically compiled into a single joint ruleset (Figure 1,bottom-right).</p><p>2.2 Topology Abstraction With Network Objects</p><p>Modular programming requires a way to constrain whateach module can see (information hiding) and do (pro-tection). Network objects offer both information hidingand protection, while offering the familiar abstraction ofa network topology to each module. A network objectconsists of an abstract topology, as well as a policy func-tion applied to the abstract topology. For example, theabstract topology could be a subgraph of the real topol-ogy, one big virtual switch spanning the entire physicalnetwork, or anything in between. The abstract topologymay consist of a mix of physical and virtual switches,and may have multiple levels of nesting on top of the onereal network. To illustrate how topology abstraction mayhelp in creating modular SDN applications we look attwo examples: a many-to-one mapping in which sev-eral physical switches are made to appear as one virtualswitch and a one-to-many mapping in which one phys-ical switch is presented as several virtual switches.</p><p>Many-to-one. While MAC-learning is an effectiveway to learn the locations of hosts in a network, the</p><p>Figure 2: Many physical switches to one virtual.</p><p>need to compute spanning trees makes Ethernet proto-cols unattractive in large networks. Instead, a program-mer could combine MAC-learning at the edge of the net-work with shortest-path routing (for unicast traffic) andmulticast trees (for broadcast and flooding traffic) in thenetwork interior [18, 23]. Topology abstraction providesa simple way to realize this functionality, as shown inFigure 2. The MAC-learning module sees the networkas one big switch V, with one port for each edge linkin the underlying physical network (dotted lines). Themodule can run the conventional MAC-learning programto learn where hosts are located. When a previously-unknown host sends a packet, the module associates thesource address with the input port, allowing the moduleto direct future traffic destined to this address out thatport. When switch V receives a packet destined to an un-known address, the module floods the packet; otherwise,the switch forwards the traffic to the known output port.</p><p>The switching fabric of switch V is implemented bythe switching-fabric module, which sees the entire physi-cal network. the switching-fabric module performs rout-ing from one edge link to another (e.g., from the ingressport at switch A to the egress port at switch B), This re-quires some coordination between the two modules, sothe MAC-learner can specify the chosen output port(s),and the switching-fabric module can direct traffic on apath to the egress port(s).</p><p>As a general way to support coordination, we intro-duce an abstract packet model, incorporating the con-cept of virtual packet headers that a module can push,pop, and inspect, just like the actions OpenFlow sup-ports on real packet-header fields like VLAN tags andMPLS labels. When the MAC-learning module directstraffic from an input port to an output port, the switching-fabric module sees traffic with a virtual packet headerindicating the corresponding ingress and egress ports inits view of the network. A run-time system can performthe necessary mappings between the two abstract topolo-gies, and generate the appropriate rules to forward trafficfrom the ingress port to the appropriate egress port(s). Inpractice, a run-time system may represent virtual packet-header fields using VLAN tags or MPLS labels, and in-</p><p>3</p></li><li><p>Figure 3: One physical switch to many virtual.</p><p>stall rules that push, pop, and inspect these fields.</p><p>One-to-many. Enterprise networks often consist ofseveral Ethernet islands interconnected by gatewayrouters to an IP core, as shown in Figure 3. To imple-ment this behavior, an SDN programmer would have towrite a single, monolithic program that handles networkevents differently depending on the role the switch isplaying in the network. This program would implementMAC-learning and flooding to unknown destinations forswitches within Ethernet islands, shortest-path routingon IP prefixes for switches in the IP core, and gatewaylogic for devices connecting an island to the core. Thegateway logic would be complicated, as the switch wouldneed to act simultaneously as MAC-learner, IP route...</p></li></ul>

Recommended

View more >