论文 sdn p271-koldehofe

1、Tutorial:Event-based Systems Meet Software-dened NetworkingBoris Koldehofe, Frank Drr, Muhammad Adnan Tariqtitute of Parallel and Distributed Systems University of Stuttgartfirstname.lastname ipvs.uni-stuttgart.deABSTRACTSoftware-dened networking (SDN) is a recent development in the area of communic

2、ation networks with tremendous support by key players building the next generation of com- puter hardware and software. This development will have signicant impact on how communication middlewarein particular, future distributed event-based systemscan be designed. While currently the communication m

3、iddleware has no possibility to directly inuence the properties of its underlying communication channels on the network layer, SDN enables communication middleware to control and ex- ibly adapt the forwarding of communication ows in the un- derlying network. In addition to the immediate implication

4、to local area networks such as data center networks, campus networks, or company networks, novel trends like network virtualization may even support Internet-wide distributed applications to benet from SDN in the future. This paper gives an introduction on how to utilize SDN-concepts for improving t

5、he performance of event-based middleware and to test their behavior.there is still a gap between the communication functionality required by distributed applications and the simple func-tionality oered by the Internet protocols. Fortance,distributed systems often require asynchronous communi- cation

6、 between multiple at design time unknown senders and receivers together with expressive addressing concepts like message channels, or content-based addressing, whereas TCP/IP and UDP/IP are restricted to simple addressing concepts (IP addresses and port numbers) and basic con-nection-oriented and co

7、nnection-less services (byte streams and datagrams). This gap is typically lled by communica- tion middleware systems implementing powerful communi- cation paradigms on top of the basic Internet protocols.Currently, we can observe a clear separation between com- munication middleware and network pro

8、tocols. Basically, the communication middleware is interfacing with the net- work through sockets that give the application little pos- sibilities to inuence the behavior of the underlying pro- tocols. In particular, the communication middleware has no inuence on how packets are routed in the physic

9、al net- work. Therefore, higher-level routing functionality is often implemented on the application layer in overlay networks on top of the IP network. This strict separation has made it very hard for the communication middleware to support application requirements like guarantees on end-to-end la-

10、tency since the application overlay is unaware about the real topology of the underlying network. Although this problem can be alleviated by using topology inference mechanisms, these mechanisms are not perfect and induce an overhead. And even if the communication middleware was aware of the physica

11、l network topology and all alternative routes on the network layer, it could not inuence the routing algorithms of the distributing routing protocols to utilize these routes. Moreover, the implementation of forwarding functionalityCategories and Subject DescriptorsC.2.1 Network Architecture and Desi

12、gn: Distributed networks; C.2.4 Distributed Systems: Distributed ap- plications; D.2.11 Software Architectures:Data ab- stractionKeywordsSoftware-dened Networking, Event-based Systems, Content- based Routing, Publish/Subscribe, Network Virtualization1.INTRODUCTIONThe success of the Internet and its

13、underlying network pro- tocol (IP) and transport protocols (TCP, UDP) allows for the implementation of large-scale distributed applications by connecting hosts and services all over the world. Al- though these protocols have proven to be highly versatile,“oftware” on the application layer does not u

14、tilize theforwarding or low-latency forwarding have been very chal- lenging to achieve so far.At this point, software-dened networking (SDN) is an im- portant development with high potential to overcome many of these limitations. SDN is currently a big trend in network- ing with strong support from

15、both academia and industry giving applications and middleware systems more control over the communication network, e.g., allowing application designers to build their own network topologies by program- ming ows in the underlay network rather than in the over- lay network.Permission to make digital o

16、r hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. To copy otherwise, to republish, to post on servers

17、 or to redistribute to lists, requires prior specic permission and/or a fee.DEBS13, June 29July 3, 2013, Arlington, Texas, USA. Copyright 2013 ACM 978-1-4503-1758-0/13/06 .$15.00.271The basic concept of SDN is the separation of network management (control plane) and forwarding functionality (forward

18、ing plane).The control plane is implemented by a logically centralized controller, which congures the for- warding tables (also called ow tables) of switches to dene2. illustrating a general approach for writing event-basedapplicationsDN and showing its concrete applica-tion to content-based publish

19、/subscribe (Section 3),3. proposing an evaluation methodology (Section 4),4. and highlighting research challenges (Section 5).routes of communication ows in the network. Bytallingits application-specic control logic in the SDN controller, the communication middleware can control the forwarding of th

20、eir ows directly on the network layer. In order to fa-2.PRINCIPLES AND DESIGN DECISIONSIn this section, we rst introduce the underlying principles of SDN, and then propose basic design decisions for im- plementing SDN-supported communication middleware sys- tems. We conclude with a discussion in gen

21、eralizing SDN by utilizing the concept of virtual networks to also leverage high performance of distributed applications at Internet-scale.cilitate the calculation and optimization of routes, the con- troller exposes topology information and trac statistics to the control logic as a global view onto

22、 the network.Packet forwarding is implemented by the switches. Typi- cally, multi-layer switches are used which can make forward- ing decisions for communication ows based on layer 2-4 header elds such as source and destination MAC addresses, IP addresses, port numbers, or VLAN ids. This congura- ti

23、on can either be performed proactively before packets of a ow are to be forwarded, or reactively whenever a switch receives packets without matching ow table entry.There are several advantages oered by SDN:2.1Basic Principles of SDNSDN clearly separates two concerns: Network control imple- mented by

24、 the logically centralized network controller and packet forwarding performed by the switches. Although the controller is logically centralized, it can be physically dis-tributed by running severaltances of controllers to in-crease the availabilitye.g., using redundant controllersorGreat exibility:

25、Rather than relying on “hard-coded” protocols and control logic implemented by the swit- ches, the control logic can be easily changed through the controller. This concept also enables applications or middleware systems to “program” the network ac- cording to their specic needs like quality of servi

26、ce or security requirements.Ease of implementation and testing: Network control is greatly simplied by the concept of logical central- ization and the global view onto the network. Control logic can be implemented using modern programming languages such as C+, Java, or Python, and utiliz- ing powerf

27、ul integrated developing environments likescalabilitye.g., by scaling out control logic to several phys- ical machines. The notion of logical centralization implies that for the control logic performing ow programming, this distribution should be transparent.SDN enables the controller to modify the

28、ow tables of switches. A ow table entry denes actions that the switch should perform on packets of a certain ow, where the ow is dened by the matching criteria of the entry using layer 2 to 4 header elds. Examples of ows are a TCP connection (de- ned by source/destination IP addresses and source/des

29、tina- tion port numbers), packets from a specic MAC address, or packets labeled with a certain VLAN tag. Actions in- clude the forwarding of the ows packets on certain ports or packet header manipulations like IP or MAC address re- writing.The denition of ow table entries can either be done proactiv

30、ely a priori to receiving packets of a certain ow, or reactively when the switch receives a packet of an un- known ow without a matching ow table entry for the rst time. Using the reactive strategy, a switch forwards packets without matching ow table entry to the controller, which decides on suitabl

31、e actions and can set suitable ow table entries for future packets of this ow (e.g., to dene a route for the ow through the network). After the ow table entry has been congured, forwarding is performed by the switches without contacting the controller again. Typically, hardware switches can perform

32、forwarding at line-rate using dedicated hardware like ternary content-addressable memory (TCAM) for matching ow table entries and incoming packets.Moreover, the controller can also query the switches for trac statistics like the number of forwarded packets or bytes over a certain port (link). By imp

33、lementing standard protocols like the Link Layer Discovery Protocol (LLDP) or Address Resolution Protocol (ARP), the controller can discover the network topology (links between switches and between hosts and switches). Based on this information, the control logic implemented by the switch can dynami

34、- cally calculate routes for ows.OpenFlow denes a standard protocol between controller and switch for ow programming and additional basic func- tions like the mentioned gathering of trac statistics.Eclipse.tead of falling back to network simulation,the real control logic implementation can be tested

35、 anddebugged more easily using network emulation. More- over, centralized control simplies the verication of control logic compared to distributed protocols, and enables stricter notions of consistency during network updates (strict vs. eventual consistency).High performance: Although control functi

36、onality isimplementedoftware, packet forwarding can utilizethe hardware support of switches enabling low-latency forwarding and line-rate throughput. Moreover, net-work resources can be optimized based on a global view onto network resources, and the time to react to link and switch failures can be

37、reduced.With OpenFlow 21, a standard protocol for SDN is avail- able that is already implemented by hardware switches from major vendors and software switches like Open vSwitch 23 which is highly popular to connect virtual machines in data centers. Moreover, several open source controller implemen-

38、tations are available, e.g., NOX (C/Python) 18, or the Java- based controllers Floodlight 7, Beacon 6, and Open- Daylight 22.In this paper, we approach SDN from the perspective of event-based systems by1. giving an introduction to the general principle of SDN (Section 2),272of groups that can be est

39、ablished for a group communica- tion middleware. Note, that these limitations are likely to persist also in the future as the size of the TCAM memory dictates the cost of a switch and is therefore considered as a precious resource. Nevertheless, the availability of distinct ows also depends on the c

40、oncrete standard supported. Fortance, the OpenFlow standards 1.0 and 1.1 only support IPv4 (32 bit IP addresses) while later versions support IPv6 addresses (128 bit). Moreover, a group forwarding feature which facilitates the forwarding to multiple ports was only introduced in OpenFlow 1.1.A critic

41、al issue is to ensure the interoperability with other applications sharing the same network. For example, adding a ow by overwriting the MAC or IP destination address elds may restrict the hosts which are reachable in the net- work. Applications may not even be aware of these restric- tions, and, th

42、erefore, this might result in faulty and unex- pected behavior. A solution is to utilize only specic address ranges that avoid the collision with other applications. For tance, a content routing application may utilize a dedi- cated range of the address space for IP multicast as it canbe seen as an

43、advanced group communication service.Moreover, certain matching operations like longest prex matches might only be available for certain addresses (in particular, IP addresses). As we will see later, such a fea- ture is benecial for mapping content-based lters to the matching operations supported by

44、 switches.Another important restriction to keep in mind is the fact that some switches might not support fast matching on ar- bitrary combinations of header elds. Therefore, one has to carefully select those elds that are supported in hardware by the switch.Note, that in many cases it will be inevit

45、able to utilize special header elds in order to capture the dynamics like a new process is joining or leaving the middleware. Those packets will always be forwarded to one of the controllers of the communication middleware to determine changes to the group communication topology. The controllers in

46、order to adapt the network topology may rely on additional infor- mation by encoding the topic or the content as part of the address eld.DA 2001:2428:2312SA = 2001:1428 57abinPSwitch 1Switch 2Flow TableFlow TableSout(in,DA,SA)out(SA,DA)unknownControllerFigure 1: Programming a ow between a publishera

47、nd a subscriberUsing the example of a publish/subscribe systems, Fig- ure 1 illustrates the basic principle in establishing a ow be- tween a publisher p and a subscriber s. In this example, ow tables do not contain any ow entries initially. When p for- wards the rst packet of the ow, Switch 1 receiv

48、ing the rst packet will not be able to make a forwarding decision as its table does not contain an entry matching the source addressand destination address elds of the IP-header.tead thepacket will be forwarded to the controller. The controller once receiving the packets of smay identify Switch 2 as

49、a suitable target to forward these packets and establish a new ow from port in to port out for all packets comprising the source IP address (2001:1428:57ab) and destination IP address of s (2001:2428:2312). In addition, the controllermaytall a ow entry also at Switch 2 to establish thepath from p to

50、 s. Once the ows are programmed, the pack-ets will be forwarded along the path without involving the controller anymore.2.2Designing SDN-supported Communication MiddlewareFor a communication middleware to benet from SDN and the high forwarding performance of (hardware) switches, the goal is to push

51、the forwarding functionality of the communi- cation middleware onto the switches and let the communi- cation middleware implement the control logic of the phys- ical network to program suitable ow table entries at the switches. Since the the communication middleware usually supports more expressive

52、addressing and message ltering concepts like content-based lters, it is not straight forward to nd a mapping to the basic addressing and matching concepts supported by the network such as MAC or IP ad- dresses, and exact or longest prex matching on bit strings. In fact, a lot of research in publish/

53、subscribe (e.g., 25, 4, 16, 9, 3, 30, 31) has addressed the problem of eciently matching events and lters, and identied this process to be one of the potential performance bottlenecks. Therefore, leveraging the line-rate and low-latency forwarding perfor-mance of switches by nding suitable mappings

54、from content- lters to ow table entries is a promising but challenging eort.A key decision in nding the mapping is the use of suit- able header information of packets. As we have already in- troduced, OpenFlow supports dierent layer 2 to 4 header elds. The choice of those elds has a number of implic

55、a- tions for the design of a middleware such as the number of ow entries that can be used (since the physical network is usually shared between the communication middleware and other applications, we can only reserve a certain amount of address space for the middleware). A limited number of ow entri

56、es, for example, may limit the maximum number2.3Internet-scale SDN-based MiddlewareWhile it seems unlikely that an Internet service provider (ISP) will provide applications or the middleware direct ac- cess to its switches and routers, the advent of virtual net- works will allow applications to cong

57、ure and access a net- work of virtual switches that can even spread across multiple ISPs. SDN will also here be the paradigm to exibly con- gure the behavior of virtual switches, which then can be mapped to their physical counterparts without loss of per- formance.Figure 2 illustrates the reference

58、architecture we envisionization serves as a basic abstraction to allocate a network of virtual switches and links. While state of the art approaches already allow for the allocation of virtual networks of a sin- gle ISP 29, we will assume in line with current research initiatives such as 1, 27 that an application can allocate avirtual network over multiple ISPs. Fortance, in Figure 2the virtual net